Secrets in Code: Keys, Tokens and Passwords

Modern software runs on secrets: API keys, cloud access keys, database passwords, signing keys and service tokens. Each one is a credential that lets software, or anyone holding it, act with real privileges. Unlike user passwords, these secrets are often copied into configuration files, scripts and pipelines, and they rarely have MFA in front of them.

Attackers know this. Searching public and stolen code repositories for credentials is a routine technique, and a single exposed cloud key can be enough to reach sensitive data.

Where secrets leak

• Source code and configuration files committed to version control, including test files and sample configurations.
• Repository history, where a secret removed in a later commit is still present in earlier ones.
• CI/CD logs that print environment variables, command lines or error messages containing tokens.
• Container images built with credentials copied into a layer.
• Chat messages, tickets and wiki pages where a credential was shared to unblock someone quickly.
• Developer laptops holding long-lived keys in plain text files.

Deleting the line is not enough

Once a secret has been committed and pushed, assume it is compromised. Repositories are cloned, forked, cached and backed up, and history rewriting cannot reach every copy. The only reliable fix is to revoke the secret and issue a new one. Cleaning the history is still worthwhile to prevent repeat discovery, but it comes after revocation, not instead of it.

Use a secrets manager

A secrets manager, sometimes called a vault, stores credentials centrally, encrypts them, controls who can read each one and logs every access. Applications and pipelines retrieve secrets at runtime instead of storing them in code or configuration.

• Grant access per application and environment, so a development service cannot read production credentials.
• Use the platform's workload identity where available, so applications authenticate to the vault without a stored bootstrap password.
• Protect the vault itself with strong administrative controls, phishing-resistant MFA for administrators and alerting on unusual access.
• Keep secrets out of logs by using CI features that mask secret values and by reviewing what build scripts print.

Prefer short-lived credentials

The less time a credential is valid, the less useful it is to anyone who steals it. Many cloud platforms and secrets managers can issue temporary credentials on demand, valid for minutes or hours. CI/CD pipelines can often use identity federation to obtain temporary cloud access for each job rather than storing a long-lived key in pipeline settings. Where long-lived secrets remain, scope them to the minimum permissions they need.

Rotate on a schedule and on events

Rotation limits how long a quietly leaked secret stays useful. Rotate long-lived secrets on a defined schedule, and immediately when someone with access leaves, when a system is compromised or when a secret may have been exposed. Rotation is only practical if it is automated and applications reload credentials without manual work, so test the process before you need it in a hurry.

Scan early and often

• Before commit or push, using pre-commit hooks or repository push protection that blocks known secret formats.
• In pipelines, so secrets that slip past developer tools are caught before merge.
• Across existing repositories and history, including archived projects that may still hold valid credentials.
• In container images, build logs and shared documents, where secrets often hide.

Tune scanners to reduce false positives so developers trust the alerts, and give them a simple, approved way to store secrets correctly.

When a secret leaks

• Revoke or rotate it immediately, before investigating, and update the systems that depend on it.
• Review its use in access logs from the time it was exposed, looking for unfamiliar locations or actions.
• Assess what it could reach and treat any suspicious activity as a potential incident.
• Find the root cause, such as a missing ignore rule or a verbose build step, and fix it so the same leak does not repeat.

How CDT can help

CDT helps development teams keep credentials out of their code. Our DevSecOps engineers build secrets management and scanning into pipelines, our code review specialists look for exposed and misused credentials, and our incident response team can investigate when a leaked secret may have been used.