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. Finding the ones you have already leaked is usually among the first things a security review turns up.

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)

Code Is Not Where Most Secrets Leak

Scanning the repository is the obvious first move and it catches the easy cases. The credentials that cause real incidents tend to live in the places nobody scans, because they were pasted there by a human solving a problem quickly.

CI logs. A build step that prints its environment, or a curl command run with -v, writes the token into a log that is retained for months and readable by anyone with repository access. Check what your pipeline echoes on failure, since the debug output added during a bad week is usually still there a year later.

Terraform state. State files record resource attributes in plaintext, including generated database passwords and access keys. If your state lives in a bucket with loose permissions, or worse in the repository, every secret Terraform created is sitting there in readable form. Remote state with encryption, restricted access, and versioning is table stakes.

Container images. A secret copied in during a build and deleted in a later layer is still present in the earlier layer, and anyone who can pull the image can extract it. The same applies to files removed in a later commit but present in Git history, which is why rotation rather than deletion is the only real remedy.

Client-side bundles. Any value compiled into a web or mobile app is public, whatever the variable is called. Assume anything shipped to a browser is disclosed.

Chat, tickets, and documents. Search your Slack workspace for "key" and "password" and read the results honestly. Support tickets, onboarding docs, and shared password notes hold a surprising share of production credentials, and unlike the repository, nobody ever audits them.

What Rotation Actually Involves

Rotation reads as one step in a checklist and is where most efforts stall, because rotating naively causes an outage. The workable pattern is dual credentials: issue a second, deploy it, confirm every consumer is using it, then revoke the first. That requires the provider to support two active credentials at once, which most cloud and payment providers do and smaller vendors often do not.

The order differs by credential type. For a database password, add a user with identical grants, migrate the connection strings, confirm zero connections remain under the old user, then drop it. For a cloud access key, create the second key, deploy, then check the last-used timestamp on the old key before deleting it, since that timestamp is the evidence that nothing forgotten is still calling. For a signing key or webhook secret, accept both old and new for an overlap window, because senders you do not control keep using the old one until you tell them.

The credentials people avoid rotating are the ones without a clean second-copy path: an OAuth refresh token for a partner integration, a certificate embedded in shipped devices, a shared vendor account with no API for key management. Keep those as a list of known-hard rotations with an owner, so a leak does not become the moment you discover them.

The better long-term answer is to stop having long-lived credentials where the platform allows it. Workload identity federation lets a container or a CI job assume a cloud role using a short-lived token, with no static key anywhere. Moving CI and production workloads to that model removes the largest category of leakable secrets and is usually a day of work per environment.

The First Hour After a Key Goes Public

Automated scanners find keys pushed to public repositories within minutes, and cryptomining infrastructure spins up on stolen cloud credentials faster than most teams notice the push. Treat a public leak as an incident, not as a cleanup task.

Revoke first and investigate second. The instinct to check whether it was actually used before disrupting anything gets the order backwards, because revocation is reversible in minutes and unauthorized use is not. Then check what the credential could do: pull the IAM policy attached to it, and if the answer is broader than you remember, that scope is your blast radius. Then check whether it was used: CloudTrail or the equivalent audit log, filtered to that principal, across the whole period the key existed rather than the period since it leaked.

Look for the specific things attackers do with cloud keys: new IAM users or access keys, roles with trust policies pointing outside your account, expensive instances in regions you never use, and calls to snapshot or share your storage. Billing is often the fastest signal available.

Then decide whether this is a reportable breach. If the key reached personal information, that determination belongs to whoever owns privacy rather than to the engineer who found it, and under PIPEDA you must keep a record of the breach whether or not it met the notification bar. Rotating and moving on without making that call is what turns a manageable event into a disclosure problem later.

What Auditors and Buyers Ask About Secrets

Secrets management shows up under access control and change management in every framework, and the questions are consistent. Who can read production secrets, and how do you know. When was each secret last rotated. What prevents a secret being committed. How are secrets provisioned to CI without a human seeing them. What happens to secret access when someone leaves.

The evidence that satisfies these is not a screenshot of your secrets manager. It is the access policy showing which roles can read which secret paths, an export of the audit log showing reads over the period, the pipeline configuration that fails a build on detection, and a leaver checklist with completed instances for the people who actually left. If your secrets manager offers audit logging and you have not turned it on, turn it on before your observation window starts, since retroactive evidence does not exist. This is the same discipline that governs the rest of a compliance program: a control is only real if it leaves a trace somebody outside the company can read.

One question catches teams out repeatedly. Auditors ask whether developers can read production secrets, and the honest answer at most startups is yes, because everyone has admin. That is not automatically a finding if you can show the access is deliberate, reviewed, and logged. It becomes a finding when the access is unbounded, unreviewed, and invisible.

When Not to Buy Help With This

Secrets management is at the top of the list of things you should not pay a consultancy to do for you. The work is well documented, the tools are designed to be self-serve, and a team of any competence can complete the migration in under a week. Paying someone to run TruffleHog and click through AWS Secrets Manager is buying a service that costs more than the outcome.

Specifically, do not hire anyone if your stack is one cloud provider and under a dozen services. Do it yourself, take the rotation seriously, add the pre-commit hook, and spend the saved money on log retention.

Do not buy a secrets platform subscription before you have removed the secrets from code. A managed platform on top of a codebase that still has keys in it is a second place to look rather than a solution, and the cloud-native managers are enough for a long time.

Narrower cases justify outside help. When a credential has already leaked and you need someone who has run that investigation before, an incident response retainer is the right shape rather than a project. When an auditor has asked for evidence, the useful engagement is a review of what you have rather than a rebuild. And when the environment genuinely is complicated, meaning multiple clouds, regulated data, or an on-premise footprint, a few hours of senior review saves weeks. If you would rather see what a review would cover before spending anything, tell us what your buyer is asking for and we will tell you what is worth doing in house.