Why do CI/CD secrets create more risk than many teams expect?

Why This Matters for Security Teams

CI/CD pipelines are not just build machinery. They are privileged execution environments that often sit upstream of source control, cloud control planes, package registries, and production deployment paths. That is why a single leaked secret can become a multi-system compromise rather than a single bad login. GitGuardian’s The State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which reflects how attractive these environments are to attackers. The common mistake is treating pipeline secrets as temporary convenience tokens instead of high-value non-human identities with broad authority. Once a secret is embedded in workflow context, it can be copied into logs, inherited by jobs, exposed to untrusted actions, or reused across repositories. That creates a blast radius that is larger than most teams model in access reviews. Guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both point toward tighter identity scoping, asset visibility, and continuous protection rather than static trust assumptions. In practice, many security teams discover pipeline secret exposure only after a deployment credential has already been reused outside the intended job boundary.

How It Works in Practice

The risk rises because CI/CD secrets are often used as standing credentials in environments that execute code from many sources. A secret stored for convenience may authenticate a build runner to GitHub, a container registry, a cloud account, and a deployment API. If one workflow step is compromised, the attacker may not need to break anything else. They can simply reuse the same credential against adjacent systems and chain the access together. A safer model is to reduce standing privilege and move toward workload identity plus short-lived issuance. For CI/CD, that means the runner proves what it is through a cryptographic workload identity, then receives a just-in-time secret or token scoped to a single task. Current guidance suggests this should be combined with runtime policy checks so the pipeline can only request the access it actually needs at that moment. That approach aligns with the Guide to the Secret Sprawl Challenge and the broader NHI control model described in the Shai Hulud npm malware campaign, where exposed secrets became an accelerant for downstream abuse. Common implementation patterns include:

• Using OIDC federation instead of long-lived cloud keys for runners.
• Issuing ephemeral secrets with tight TTLs and automatic revocation after job completion.
• Limiting secrets to a repository, environment, or deployment stage instead of sharing them globally.
• Blocking third-party actions from reading workflow secrets unless their trust is explicitly approved.

These controls tend to break down when self-hosted runners persist across jobs because reuse and local state make secret containment much harder.

Common Variations and Edge Cases

Tighter secret controls often increase pipeline setup effort, so organisations have to balance delivery speed against exposure reduction. That tradeoff is especially visible in monorepos, shared build farms, and multi-tenant runners where one team’s convenience can become another team’s risk. There is no universal standard for this yet, but current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 supports the direction of travel: reduce standing privilege, rotate aggressively, and make access conditional on runtime context. In CI/CD, that often means one secret per environment, one identity per runner class, and no cross-repository reuse unless there is a clear operational need. For teams modernising pipeline controls, Reviewdog GitHub Action supply chain attack is a useful reminder that third-party workflow components can expose secrets even when the original repository is well managed. The biggest edge case is developer and automation sprawl across SaaS tools, where secrets escape the repository entirely into issue trackers, chat tools, and deployment notes. That is where detection without revocation fails, because a leaked credential can remain valid long after the original pipeline event has passed.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• How should teams reduce the risk from exposed NHI secrets?
• Why do synced passkeys create more risk than many teams expect?
• Why do service accounts create more risk than many teams expect?