Before deploymentgit-secrets-review

Secrets Review Checklist

15 items ·10 critical ·4 warn ·1 info

How to use this checklist

This is the gate before any pipeline, repository, controller, or runtime is allowed to handle secrets at all. It is deliberately unforgiving: there is no “we”ll rotate it later” for a credential that has been on a paste site for ten minutes.

Run it during onboarding of every new repository, every new pipeline, and every new environment, and again quarterly as part of the secrets audit. A secrets review that has not been re-run in 90 days should be treated as having never been run.

Sign-off

Every critical item must pass. A failing critical item blocks the secret-handling path from being trusted by the rest of the pipeline; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical10 items

No plaintext secret appears in any tracked file, in any branch, in any tag, or in any PR comment across all production repositories. A secret scanner has been run against the full history, not just HEAD.
```
gitleaks detect --source . --no-banner --redact --log-opts="--all"
```
CI logs do not contain plaintext credentials. CI steps that touch secrets use `set +x`, explicit redaction, or short-lived credentials fetched at job start. Pipeline logs are themselves scanned post-run.

No Kubernetes Secret, Helm value, Ansible variable, or Terraform variable contains a plaintext credential. All secrets are sourced from a secret manager at runtime.

git ls-files | grep -E "(secret\.ya?ml|credentials|service-account\.json|\.env$)" | head; grep -RIn -E "(api_key|password|token|secret)\s*[:=]" apps/ overlays/ 2>/dev/null | head

Every credential type (cloud access keys, deploy keys, registry tokens, CI tokens, database passwords, SSH keys) has a documented rotation period, and rotation has happened within that period for the past three cycles.
A runbook exists for the moment a secret is reported as leaked: revoke immediately, audit access since exposure, replace with a fresh credential, scrub from history, and notify affected parties. The runbook has been read by someone other than its author.
There is one secret manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) that is the source of truth. Generated manifests and CI variables fetch from it; nothing is written into it from untrusted pipelines.
Secret-manager policies are least-privilege: a CI pipeline reads only the secrets for the environment it deploys to. A staging deploy cannot read production secrets, even by accident.
Production-bound credentials are short-lived by default: OIDC tokens, STS-issued session tokens, Vault dynamic secrets, database short-lived tokens. Long-lived static credentials exist only where the system does not support short-lived.
Secrets committed to history are rotated and removed via `git filter-repo` (not just `git rm`), with a rebase + force-push or a repository archive + recreate. The scrub is verified with a fresh clone.
Runbooks, READMEs, and incident notes do not contain real credentials. They contain placeholder names (`$PROD_API_KEY`) and a link to the secret-manager entry. A runbook that copies a real secret into a wiki page has already leaked it.

Warning4 items

Secret reads and writes are logged at the secret manager level and shipped to a SIEM. Anomalous access (a CI job reading a production secret it never read before) is alertable.
The secret manager encrypts at rest with a managed KMS key, the key has rotation enabled, and the key policy does not allow the secret-manager service identity to disable it. CMEK is configured where the cloud supports it.
Issue trackers and PR comments are scanned for credentials, since contributors sometimes paste secrets there. The scanner covers the issue tracker, not just the repository.
The list of contributors who can merge to a production branch is reviewed; secrets in PRs from unknown or untrusted contributors are blocked at the secret scanner rather than at the reviewer.

Info1 item

KMS keys used by the secret manager have a documented rotation procedure and have been rotated within the last 12 months. Key rotation does not invalidate existing secrets mid-rotation.