Stop Putting Secrets in Your Code: A Guide to Secrets Management

Open your codebase right now and search for strings that look like API keys, database passwords, or tokens. If you find any, you have a secrets management problem. You are not alone. GitHub reported that it detected over 10 million leaked secrets in public repositories in 2024. Many of those were from startups that did not realize their credentials were exposed.

The problem with hardcoded secrets

Hardcoded secrets create three risks:

Exposure in version control. Even if your repository is private, every developer, contractor, and CI/CD system with access to the repo has access to your production database password, your Stripe API key, and your AWS credentials. Former employees who cloned the repo still have those secrets on their laptops.

Rotation becomes impossible. When a credential is hardcoded in 47 places across 12 services, rotating it means finding and updating every instance. This is so painful that most teams never rotate credentials, which means a leaked credential stays valid indefinitely.

Environment leakage. The same codebase runs in development, staging, and production. If production secrets are in the code, developers are using production credentials in their local environment. One accidental API call in development hits production.

The solution in three steps

Step 1: Choose a secrets manager (30 minutes).

Options ranked by complexity:

• Environment variables with .env files: The simplest option. Store secrets in .env files that are never committed to version control (add .env to .gitignore). Works for small teams but has no access control, no audit logging, and no rotation capability.
• AWS Secrets Manager or GCP Secret Manager: Cloud-native secrets management with IAM-based access control, encryption, audit logging, and automatic rotation for supported services. $0.40 per secret per month on AWS. This is the right choice for most startups on AWS or GCP.
• HashiCorp Vault: The most powerful option with dynamic secrets (generates short-lived credentials on demand), fine-grained access policies, and extensive audit logging. Higher operational overhead. Use Vault if you have compliance requirements that demand it or if you are multi-cloud.
• Doppler or 1Password Secrets Automation: SaaS secrets management platforms that are easier to operate than Vault. Good for teams that want managed infrastructure. $5-$18/user/month.

Step 2: Move secrets out of code (1-2 days).

1. Audit your codebase for hardcoded secrets. Use tools like TruffleHog, GitLeaks, or detect-secrets to scan your repository history.
2. For each secret found, create an entry in your secrets manager.
3. Update your application code to read secrets from the secrets manager (or from environment variables populated by the secrets manager) instead of from hardcoded values.
4. Update your CI/CD pipeline to inject secrets from the secrets manager at build or deploy time.
5. Rotate every secret that was ever committed to version control. This is critical. If a secret was in your Git history, consider it compromised, even if you deleted it. Git history is permanent.

Step 3: Establish ongoing practices (ongoing).

• Pre-commit hooks: Install a pre-commit hook that scans for secrets before code is committed. detect-secrets and GitLeaks both offer pre-commit integration.
• CI/CD scanning: Add a secrets scanning step to your CI pipeline. If a secret is detected, fail the build.
• Regular rotation: Rotate database passwords quarterly. Rotate API keys when employees leave. Use short-lived credentials (AWS STS, GCP workload identity) where possible.
• Access control: Not every developer needs access to every secret. Use your secrets manager is access controls to limit who can read production database credentials, payment processing keys, and other high-sensitivity secrets.

The 1-hour setup

If you are on AWS, here is the fastest path to proper secrets management:

1. Create secrets in AWS Secrets Manager for each credential your application uses (15 minutes)
2. Update your application to use the AWS SDK to fetch secrets at startup (30 minutes)
3. Update your ECS task definition or EC2 instance role to grant access to the secrets (10 minutes)
4. Remove hardcoded secrets from your codebase and commit (5 minutes)
5. Rotate every credential that was previously in version control (varies)