secret-handling

# secret-handling The secret-source gate. Routed to when changed code reads, writes, generates, stores, or passes a secret. If a value's secret status is uncertain, treat it as a secret. ## Pre-flight Read these, or STOP and surface the gap — never guess the policy: - `<project-root>/.codearbiter/security-controls.md` — the approved secret store, the access method (IAM role, workload identity, service-account token — never long-lived static keys), and any required reference format. If this file is unreadable, BLOCK; do not infer the store. ## Phase 1 — Identify · gate: BLOCK Scan the changed code for secret-bearing names: `password`, `secret`, `token`, `key`, `credential`, `api_key`, `apikey`, `private`, `cert`, `passphrase`. For each match, record its source (where the value originates) and every sink (where it flows). No candidate may remain unclassified. Gate: every candidate secret is listed with its source and sinks. ## Phase 2 — Source · gate: BLOCK Each secret MUST originate from the approved store in `security-controls.md`, accessed via the approved method. The following sources BLOCK unconditionally: - Hardcoded string literal. - `process.env` or `.env` for a secret value — these are for non-sensitive config only (ports, log levels). `.env` files MUST be gitignored and secrets-scanned on every PR. - A database column holding the raw value (a stored *reference* is allowed — see Phase 3). - Any store endpoint not named in `security-controls.md`. **Stakes:** ...