Why do CI/CD pipelines create secret governance risk?

Why This Matters for Security Teams

CI/CD pipelines turn credentials into execution, which means a secret is no longer just stored data. It becomes an operational capability that can deploy code, touch production systems, or call privileged APIs. That is why pipeline compromise is so damaging: a single exposed token can outlive the job that used it and keep working elsewhere. The risk is magnified in supply chain incidents and secret sprawl events such as the CI/CD pipeline exploitation case study, where the environment itself becomes the attacker’s foothold.

Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but CI/CD needs sharper treatment because the pipeline is both identity provider and privilege consumer. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they enter build systems, logs, artifacts, and runner environments. In practice, many security teams discover this only after a build agent has already used the credential in a place no one intended.

How It Works in Practice

A pipeline creates secret governance risk when it collapses several security functions into one automated flow. The same job that checks out code may also decrypt a token, inject it into an environment variable, and use it to deploy infrastructure. If the pipeline is not tightly scoped, the credential becomes a standing access path rather than a short-lived work factor.

The practical controls are straightforward, but they must be implemented as engineering guardrails rather than policy statements. Best practice is evolving toward:

• JIT secrets that are issued per job or per deployment and revoked at completion.
• Workload identity for the runner or job, so the platform proves what it is before a secret is released.
• Least-privilege scopes that limit a credential to one service, environment, or action.
• Secret redaction in logs, artifacts, and test output so pipeline telemetry does not become a leak path.
• Policy-as-code checks that block unsafe use before a privileged step executes.

This is the core lesson behind the Reviewdog GitHub Action supply chain attack and the OWASP Non-Human Identity Top 10: pipelines are not just code movers, they are identity brokers with automation privileges. The NHI control point is not only storage of the secret, but also who can request it, when it is released, where it can be used, and how quickly it is revoked. These controls tend to break down when build runners are shared across teams because token reuse and cross-job residue become difficult to prevent.

Common Variations and Edge Cases

Tighter secret control often increases delivery friction, requiring organisations to balance release speed against the overhead of short-lived credentials and policy checks. That tradeoff is real, especially for teams with frequent deploys or complex multi-account environments.

There is no universal standard for every pipeline pattern yet. Some environments can move quickly to ephemeral credentials and workload identity, while others still depend on static secrets for legacy systems, external SaaS tools, or manual release gates. In those cases, risk reduction comes from narrowing scope, isolating runners, and removing secrets from logs and artifacts wherever possible. The right answer is usually not more vault access, but less need for any long-lived credential at all.

NHIMG’s 2024 ESG Report: Managing Non-Human Identities underscores the governance gap: compromised NHIs are common, and repeated incidents are not rare. The strongest operational pattern is to treat each pipeline as a trust boundary, not a convenience layer. That matters most in federated build systems, self-hosted runners, and hybrid release pipelines where a single compromise can cross multiple environments before detection.

Related resources from NHI Mgmt Group

• Why do parallel build jobs create governance risk in identity tooling pipelines?
• Why do CI/CD pipelines create special NHI governance problems?
• Why do CI/CD pipelines create non-human identity risk?
• Why do self-service portals create governance risk when access is involved?