Secrets & Credentials rules

Use envelope encryption (AES-256-GCM) with cloud KMS-managed CMKs for databases, object storage, and backups. Rotate CMKs at least annually and rotate DEKs per object/file.

In Pulumi TypeScript programs, load sensitive values with new Config().requireSecret and pass as Secret<T>, never plain strings.

All credentials (API keys, DB passwords, tokens) must be stored in a secrets manager with automatic rotation ≤ 90 days; forbid hardcoded or .env-committed secrets via CI checks.

Add a CI step that fails builds if secret patterns (JWT, AWS keys) or high-entropy strings are detected in diffs.

Add a 'Security & Privacy' section in ADRs addressing threat model impacts, secrets handling, data retention, and PII processing; link to relevant runbooks and DPA if applicable.

Avoid hard‐coding credentials or sensitive information (like DB passwords, API tokens or secret keys) directly in your code. Use separate configuration files or environment variables to manage these values securely.

Use AES-GCM with keys from KMS to encrypt sensitive columns (e.g., SSN) before saving; store nonce and auth tag; never rely solely on disk encryption.

Use a KMS client to derive DEKs and encrypt sensitive blobs; rotate CMKs annually and re-encrypt on rotation.

If PAN must be handled transiently, encrypt in memory with AES-256-GCM using a KMS/HSM-provided key, store only ciphertext or tokens, and zeroize plaintext buffers immediately. Rotate keys per policy. (PCI DSS 4.0 Req. 3)

Read API URLs/keys from ENV/credentials and inject where needed; do not hardcode.

Access tokens, HMAC salts, and KMS keys for PHI flows must come from a secret manager or encrypted credentials store; forbid committing secrets or .env files to the repo.

Read secrets (process.env.*) only in Server Components, Route Handlers, or server actions. Client Components must use ONLY NEXT_PUBLIC_* variables.

CI logs must redact secrets and CHD; disable shell xtrace, and add a job that fails if PAN regex (e.g., [0-9]{13,19} with Luhn) appears in logs/artifacts. (PCI DSS 4.0 Req. 10 & CI hygiene)

Use app.UseHsts(); app.UseHttpsRedirection(); store DataProtection keys in Azure Key Vault or KMS with rotation.

Never hardcode credentials (API keys, tokens, private keys) in source code, configs, or tests. If a string looks like a credential based on context (variable name, header usage, auth flows), treat it as a secret even if it is not high-entropy. Move it to env/secret manager, rotate the credential if it may have leaked, and remove it from git history if necessary.

For security tokens (session IDs, CSRF tokens, password‐reset links), use cryptographically secure random functions like random_bytes() or openssl_random_pseudo_bytes(), instead of predictable functions like rand() or mt_rand().

Do not use weak or generic hash algorithms (like MD5 or SHA1) for storing passwords. Use built‐in functions like password_hash() (with BCRYPT or Argon2) and password_verify(), which handle salting and secure algorithms automatically.

All variables must declare a type, default (when sensible), and validation blocks; mark sensitive inputs with sensitive=true.