They combine execution, secrets access, and often write permission in a single runtime. If an attacker can influence the trigger or the command path, the runner may expose tokens that were meant for automation, not adversarial use. Once those credentials are stolen, the attacker can persist changes, widen access, or pivot into the broader supply chain.
Why This Matters for Security Teams
Misconfigured CI/CD workflows turn build infrastructure into a credential concentration point. The risk is not just that secrets are stored in the pipeline, but that workflow logic, runner permissions, and trigger handling often determine who can reach those secrets at runtime. That makes CI/CD a high-value target for supply chain attackers, especially where automation identities can write to repositories, publish artifacts, or deploy to production.
From a control perspective, this is where identity, privilege, and software delivery overlap. The OWASP Non-Human Identity Top 10 is useful here because build agents, tokens, and deployment bots are all non-human identities that need lifecycle, scope, and revocation discipline. NIST’s NIST Cybersecurity Framework 2.0 frames the same issue as a governance and protection problem: know what identities exist, protect their secrets, and detect misuse quickly.
In practice, many security teams encounter this only after a poisoned workflow or exposed token has already been used to modify a release path, rather than through intentional control design.
How It Works in Practice
CI/CD pipelines often need to authenticate to source control, package registries, cloud platforms, and deployment targets. When those credentials are injected too broadly, available for too long, or readable by untrusted jobs, an attacker only needs a small foothold to turn workflow execution into credential theft. The problem is not limited to hardcoded secrets. It also includes ephemeral tokens, inherited permissions, and environment variables exposed to every step in a job.
The practical attack path usually starts with workflow manipulation: a pull request, compromised dependency, injected build script, or malicious step that prints environment data. If the runner has access to secrets and network reach, the attacker can copy tokens, reuse them elsewhere, or pivot into artifact signing, infrastructure deployment, or source control changes. That is why security guidance increasingly treats pipeline identities as first-class assets, not just implementation details.
- Limit secret exposure to the smallest possible job or step.
- Use short-lived credentials and rotation rather than long-lived tokens.
- Separate build, test, and deploy privileges instead of reusing one broad automation identity.
- Lock down trigger sources, branch protections, and approval gates for sensitive workflows.
- Log secret access, runner activity, and unusual token use for detection.
NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with this approach through access control, auditing, and system integrity requirements, while identity assurance concepts from NIST SP 800-63 Digital Identity Guidelines help teams think clearly about credential strength and lifecycle management. These controls tend to break down when self-hosted runners can reach production secrets and untrusted code can influence the job path because the runtime itself becomes the trust boundary.
Common Variations and Edge Cases
Tighter pipeline controls often increase engineering overhead, requiring organisations to balance deployment speed against secret exposure and approval friction.
Best practice is evolving for complex environments such as monorepos, ephemeral runners, and federated build systems. In those cases, a simple rule like “never expose secrets to pull requests” may be too blunt, because some workflows legitimately need controlled access for testing or integration. The safer pattern is conditional access with strong provenance checks, explicit environment separation, and step-level scoping rather than blanket permission grants.
There is also a practical distinction between credential theft and credential abuse. A token may never be exfiltrated if an attacker can use it in place, within the same runtime, to publish artifacts or alter deployment logic. That means detection needs to cover both secret leakage and anomalous privileged actions. For identity-heavy pipelines, the non-human identity view from OWASP is especially helpful, while security programs that map pipeline controls to the assurance and identity lifecycle expectations in NIST guidance are better positioned to spot drift before a release process becomes an attack path.
For teams with regulated software delivery or high-impact release pipelines, the most robust answer is a layered one: minimize secret scope, verify workflow provenance, and treat automation identities as production assets with the same discipline applied to privileged human access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-1 | CI/CD tokens and runners are non-human identities with lifecycle and scope risk. |
| NIST CSF 2.0 | PR.AC | Pipeline secrets exposure is an access control and protection problem. |
| NIST SP 800-63 | Credential strength and lifecycle management affect automation token trust. | |
| NIST AI RMF | Workflow decisions should be governed through risk management and accountability. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central to preventing broad secret exposure in CI/CD. |
Inventory pipeline identities and restrict each automation credential to the minimum job scope.
