A CI/CD system is one of the most privileged things in your company. It can read your source, build artifacts, push images and deploy to production. Whoever controls the pipeline effectively controls the product. Yet secrets in pipelines are often handled with less care than a password manager entry.

The good news is that a handful of habits remove most of the risk. None of them require exotic tooling.

Where Secrets Actually Leak

Before fixing anything, know the usual routes:

• Committed to the repository. An API key in a config file, an environment file added by accident, a test fixture with real credentials. Deleting it in a later commit does not remove it from history.
• Printed in build logs. A debug flag, a failed command echoing its arguments, or a script run with verbose output. Logs are widely readable and long-lived.
• Baked into artifacts. Secrets copied into container image layers or build outputs travel wherever the artifact goes.
• Exposed to untrusted code. Pull requests from forks or external contributors that run in a context with access to secrets.
• Shared and never rotated. One long-lived key used by many jobs and many people, unchanged for years.

Most real incidents are some combination of these, not a sophisticated attack.

Principle One: Prefer Short-Lived Credentials

The strongest improvement is replacing stored static keys with credentials that are issued on demand and expire quickly. Many CI platforms and cloud providers support federated identity, where the pipeline proves who it is using a signed token and receives temporary access. There is then no long-lived key to steal.

Where that is not available, aim for the next best thing: narrow scope, one credential per purpose, and a rotation schedule. Check your CI provider’s and cloud provider’s current documentation for the supported mechanism, since options evolve.

Principle Two: Least Privilege, Per Pipeline

A deploy job for a staging service should not hold credentials that can modify production. A job that only runs tests should hold almost nothing.

Split credentials by environment and by action. A build job that pushes an image needs push access to one registry path, not administrator rights. A deploy job needs permission to update one service, not to create arbitrary infrastructure. When a secret leaks, scope determines whether you have an inconvenient afternoon or a serious incident.

Principle Three: Keep Secrets Out of Places That Persist

Use the CI platform’s secret store or an external secret manager and inject values at runtime as environment variables or files that exist only for the job. Mask them in logs, but do not rely on masking alone, because transformations such as encoding can slip past it.

For container builds, use the build tool’s dedicated secret mounting rather than passing secrets as build arguments or copying files in. Anything written to an image layer may be recoverable from the image, even if a later step deletes it.

A Practical Control Checklist

Control	What it protects against	Effort
Secret scanning on commits and pull requests	Credentials committed to the repo	Low
Federated, short-lived credentials	Stolen long-lived keys	Moderate
Separate credentials per environment	Staging compromise reaching production	Low to moderate
No secrets for fork or untrusted pull request builds	Malicious code reading secrets	Low
Secrets injected at runtime, not in images	Leaks through artifacts	Moderate
Scheduled rotation and an owner per secret	Forgotten, stale credentials	Moderate
Audit logs reviewed for secret access	Undetected misuse	Moderate

Work down the list in rough order of effort against payoff. The first and fourth rows alone close a surprising amount of exposure.

Untrusted Code Deserves Special Attention

A pipeline that runs code from a pull request is running code written by someone, and you may not have vetted them. If that run has access to deployment secrets, a malicious change to a test script can simply read them out.

The usual rule: builds triggered by external or unreviewed contributions get no secrets. Run privileged steps only after code has been reviewed and merged, or require a maintainer to approve the run. Also protect the pipeline definition itself. If anyone can change the workflow file in the same change that uses the secret, review that file with the same seriousness as production code.

What To Do When a Secret Leaks

Assume it will eventually happen and rehearse the response:

1. Revoke or rotate immediately. Removing the commit is not enough. Treat the value as public the moment it was exposed.
2. Check for use. Review provider audit logs for activity with that credential during the exposure window.
3. Find the cause. Was it a log line, a committed file, an overly broad scope? Fix the route, not just the key.
4. Add a guardrail. A scanning rule or a scoped replacement so the same mistake is caught next time.

Speed matters more than blame. A team that can rotate a credential in minutes recovers calmly. A team where rotation requires hunting down every consumer by hand does not.

A Realistic Example

Picture a team with a single cloud access key stored in their CI settings, used by every job, created years ago by someone who has since left. Nobody is sure what else uses it.

They start by adding secret scanning, which immediately flags an old test file. They then create separate roles for build, staging deploy and production deploy, and switch the pipeline to federated tokens for the cloud. Production deploys additionally require manual approval. Finally they delete the old key, after watching its usage logs for a period to confirm nothing important still depends on it.

None of these steps were large. Together they turned one all-powerful long-lived key into several narrow, short-lived ones.

Frequently Asked Questions

Are CI platform secret stores secure enough? They are a reasonable baseline and far better than files in the repository. For stricter needs, an external secret manager adds central rotation, access control and auditing. Evaluate against your own risk and compliance requirements.

Does masking in logs make it safe to print secrets? No. Masking is a safety net, not a licence. Encoded or partially transformed values may not match the mask, so avoid printing secrets at all.

How often should secrets be rotated? Often enough that a leaked one has limited lifetime, and always after any suspected exposure or when someone with access leaves. Short-lived credentials make the question mostly disappear.

Should developers have the same secrets as the pipeline? Generally no. Give humans their own identities with appropriate access and keep pipeline credentials separate, so you can tell who did what and revoke one without breaking the other.

What about secrets in infrastructure as code? Reference them from a secret manager rather than writing values in code or state files. State files can contain sensitive values, so protect and restrict access to them as well.

Next Step

Run a secret scanner over your repositories and recent build logs this week, then list every credential your pipeline currently holds, who owns it, and when it was last rotated. Pick the broadest one and replace it with a narrower or short-lived alternative.