A CI/CD pipeline, by design, needs credentials — to pull private dependencies, push container images, deploy to cloud infrastructure, and more. That same necessity makes pipelines a recurring, high-value target, and secrets mismanagement inside them is one of the most common real-world causes of credential leaks.

How secrets actually leak

A handful of patterns account for most real incidents:

  • Hardcoded credentials committed to source control. A credential typed directly into a config file or script, then committed — often “temporarily,” to get something working — and left there. Even if removed in a later commit, it typically remains recoverable in the repository’s history indefinitely, unless that history is explicitly rewritten.
  • Secrets printed to build logs. A debugging print statement, or a tool that echoes its full configuration including credentials, writes a secret straight into a build log — which is often more widely accessible, and retained for longer, than the credential’s owner realizes.
  • Overly broad pipeline permissions. A pipeline granted broad cloud access “to be safe” means that if the pipeline itself, or anything it depends on, is compromised, the attacker inherits that same broad access — the same over-permissioning problem discussed generally in Cloud IAM and the Principle of Least Privilege, applied specifically to automated pipeline identities rather than human ones.
  • Long-lived static credentials baked into images or artifacts. A credential embedded directly into a build artifact, discussed in Build Once, Deploy Everywhere, travels with every copy of that artifact indefinitely, well beyond the original context it was meant for.

What a dedicated secrets manager actually buys you

A secrets manager — a dedicated system for storing, accessing, and auditing credentials, separate from application code and infrastructure configuration — addresses several of these problems structurally rather than relying on individual discipline. OWASP’s Secrets Management Cheat Sheet lays out the core practices in detail: secrets should never be stored in source control at all, should be injected into an application or pipeline at runtime rather than baked in beforehand, and access to them should be logged and auditable, so it’s possible to know exactly when and by what a given secret was actually accessed.

Short-lived credentials over long-lived ones

Where a provider supports it, short-lived, dynamically generated credentials — issued for a specific task and automatically expiring shortly afterward — are a meaningfully stronger defense than long-lived static credentials that, once leaked, remain valid indefinitely until someone notices and manually revokes them. A leaked short-lived credential has a naturally bounded window of exposure; a leaked long-lived one doesn’t, unless active monitoring catches it.

Least privilege, applied to pipeline identities specifically

The same least-privilege standard that applies to human identities applies with at least as much force to CI/CD pipeline identities, which are automated, often numerous, and frequently granted access well beyond what any single pipeline run actually needs. A pipeline that only deploys to a specific service shouldn’t hold standing credentials with broad account-wide access, even if that’s more convenient to set up initially — the convenience cost of scoping permissions precisely is paid once, while the exposure cost of not doing so is paid every time that pipeline, or anything that can influence what it runs, is compromised.

Why this matters more as automation increases

As more of the deployment pipeline becomes automated — more of it running unattended, described in What Is CI/CD? and taken further by GitOps — the number of places holding meaningful credentials, and the consequence of any one of them being compromised, both increase. Secrets management isn’t a one-time setup task to complete and move past; it’s an ongoing discipline that has to scale alongside how much of the pipeline is automated.

Key takeaway

Most CI/CD secrets leaks trace back to a small number of recurring, well-understood patterns: credentials committed to source control, secrets printed to logs, and pipeline identities holding far more access than any given run actually needs. A dedicated secrets manager, a preference for short-lived over long-lived credentials, and applying least privilege specifically to automated pipeline identities together address the root causes, rather than relying on individual engineers remembering not to make the mistake.

This article explains general secrets management concepts; specific tools and implementation details vary by platform. See our disclaimer.