Secrets Management Code Audit

Common Secrets Audit Findings

The most alarming finding: secrets in git history. A developer committed a .env file two years ago. It was deleted in the next commit. The secrets are still in the repository history, accessible to anyone who clones the repo. This happens in nearly every codebase we audit - especially AI-built ones where the AI included configuration files in early commits.

Secret sprawl is the second finding. The same database password exists in twelve places: environment variables, CI pipeline configs, deployment scripts, documentation, and developer .env files. Nobody tracks where secrets are used. When a rotation is needed, nobody knows which services will break.

Over-privileged credentials are the third pattern. An AWS IAM key with admin access used only for S3 uploads. A database user with superuser privileges used by the application for simple queries. Each over-privileged credential amplifies the damage of a compromise from “they can read our S3 bucket” to “they own our entire AWS account.”

Our Secrets Audit Approach

We scan repositories with tools like truffleHog and gitleaks, checking current code and entire git history. Every detected secret is classified: is it still active? What does it access? Has it been rotated since exposure? Active secrets in git history require immediate rotation.

Secrets inventory catalogs every credential the application uses. Database passwords, API keys, OAuth tokens, webhook secrets, encryption keys. For each: where is it stored, who has access, when was it last rotated, and what scope of access does it grant. This inventory often surprises teams - they have more secrets than they realized, and fewer controls than they assumed.

CI/CD pipeline review checks secrets handling during builds and deployments. We look for secrets in build logs, environment variables in pipeline configs, and over-privileged service accounts. Pipeline secrets are particularly risky because build logs are often accessible to anyone with repository access.

What Changes After the Audit

Exposed secrets are rotated immediately. Every secret found in git history, CI logs, or other insecure locations gets a new value. Old values are invalidated. The blast radius of historical exposure is eliminated.

A secrets inventory provides ongoing management capability. The team knows what secrets exist, where they’re stored, and when they need rotation. Pre-commit hooks prevent future secret commits. Monitoring detects secrets that appear in logs or unexpected locations. Secrets management transitions from accidental to intentional.

We also evaluate your readiness for centralized secrets management. Teams relying on scattered .env files and manually-copied credentials benefit from migrating to HashiCorp Vault, AWS Secrets Manager, or Doppler depending on infrastructure and team size. These platforms provide audit trails showing who accessed which secret and when, automatic rotation for supported services like RDS and IAM keys, and versioned secret history so rollbacks are straightforward. The audit report includes a concrete migration path if centralized management is warranted.