Secrets in CI and How They Leak

The pipeline needs secrets to do its job — registry credentials, cloud keys, deploy tokens, signing keys. So CI becomes the place where an organisation's most powerful credentials congregate, injected into ephemeral jobs dozens of times a day. That concentration is useful and dangerous in equal measure. The secrets are necessary; the ways they escape are numerous, subtle, and mostly invisible until someone is already using the leaked key.

The first thing to understand is that a CI secret is high-value in a way an ordinary password is not. It typically has no MFA, it often grants broad access to registries or cloud accounts, and its use is expected — automation authenticating to a registry looks exactly like the pipeline doing its job, so a stolen CI credential can be used for a long time before anyone notices anything anomalous. When these leak, they are not a minor exposure; they are frequently a direct path to production.

The leak paths, from most to least obvious

Secrets escape CI through a handful of recurring channels. The most common is the build log: a script echoes a variable, or a verbose command prints its environment, and the secret lands in a log that may be world-readable or retained indefinitely. Next is the pull-request-from-fork problem — a workflow that exposes secrets to code an outside contributor can modify hands them to that contributor. Then there is the secret committed to the repository to make the pipeline work, and the secret passed to a compromised dependency that reads the environment during a build.

Making leaks rare and survivable

• Prefer short-lived credentials over stored secrets. OIDC-based federation lets a job mint a credential valid for minutes; a leaked minutes-long token is a far smaller problem than a leaked static key.
• Scope secrets to the job that needs them. Don't expose every secret to every workflow; a build job needs no deploy key, and limiting exposure limits what any single leak reveals.
• Never expose secrets to untrusted pull requests. Treat fork PRs as hostile — run them without access to real secrets, and require a trusted maintainer to authorise anything that needs them.
• Mask, but don't rely on masking. CI log masking catches the obvious cases and misses transformed or partial values; the real fix is not printing secrets at all.
• Scan repos, images and logs continuously. Secret detection catches what leaks anyway — and a detection means rotate the credential, because deleting the commit does not un-leak it.

Rotation is the assumption, not the exception

The single most important shift is to stop treating a leaked secret as a rare emergency and start treating rotation as routine. If your secrets are short-lived by design, most leaks expire before they can be abused. If they are long-lived static strings, every leak is a crisis and every copy is permanent until someone manually rotates it — which requires knowing every place it was used. The organisations that handle CI secrets well are not the ones that never leak; they are the ones for whom a leak is a shrug because the credential was already about to expire. Rehearse the rotation too: a rotation path that has never been exercised tends to fail at the exact moment you need it, turning a routine expiry into the outage everyone was trying to avoid.

You can only rotate and protect the secrets you know your pipelines hold — and the forgotten token wired into a workflow years ago is the one that leaks. Secret hygiene in CI starts with inventory: you can't rotate what you haven't discovered.