crypto-data-protectionlisted

# Crypto data protection (`crypto.in-transit` / `crypto.at-rest`) — authoring-time guidance > Scope: this skill helps you *implement* the encryption controls in code. It does **not** certify > compliance. It makes the code satisfy the control and makes that **statically detectable** (these > are code properties, not runtime events — there is no marker to emit). > > **Framework-neutral by design.** The control keys `crypto.in-transit` / `crypto.at-rest` map to > SOC 2 (`CC6.7` / `CC6.1`), ISO 27001 (`A.8.24`), PCI-DSS v4 (`Req 4.2` / `3.5`), and > HIPAA (`164.312(e)(1)` / `164.312(a)(2)(iv)`) via the crosswalk. ## When this applies - **In transit**: any outbound request, network client, webhook, or service-to-service call; any TLS/SSL setup. - **At rest**: schema or writes for sensitive data (PII, financial, health, credentials, tokens); file/object/blob storage; backups; caches that hold the above. Ordinary in-process data with no network or persistence boundary does not need this skill. ## 1. Encrypt in transit — `crypto.in-transit` - **Always `https://` / `wss://`** for anything leaving the process. Never `http://` to a remote host (localhost during dev is fine). - **Never disable certificate verification.** No `verify=False` (Python requests), no `rejectUnauthorized: false` (Node), no `NODE_TLS_REJECT_UNAUTHORIZED=0`, no `_create_unverified_context`. If a cert is failing, fix the trust store — don't turn off TLS. - Prefer **TLS 1.2+**; let the platform nego