Misuse of pipeline identities, workflow permissions, or build artifacts to execute attacker-controlled actions. This usually looks like legitimate automation, but the goal is to steal secrets, alter code, or extend access through trusted build infrastructure.
Expanded Definition
CI/CD Identity Abuse is the misuse of build, deployment, and automation identities to carry out actions that appear legitimate inside a pipeline. It includes attacker use of workflow tokens, runner permissions, service accounts, signing credentials, and artifact access to move laterally, exfiltrate secrets, or alter delivered code. In NHI governance, the identity is the control point, not just the pipeline system.
Usage in the industry is still evolving, and definitions vary across vendors, but the core risk is consistent: a trusted automation path is turned into an execution channel. That makes this term adjacent to both NHI security and software supply chain security, especially when pipeline identities have broad secret read access or can trigger privileged jobs. NIST’s NIST Cybersecurity Framework 2.0 helps frame the governance need: identify, protect, detect, respond, and recover around automation trust boundaries.
The most common misapplication is treating CI/CD access as a generic engineering permission set, which occurs when pipeline tokens, runners, and deploy keys are not governed as non-human identities.
Examples and Use Cases
Implementing CI/CD identity controls rigorously often introduces delivery friction, requiring organisations to weigh release speed against tighter approval, rotation, and isolation requirements.
- A GitHub Actions workflow token can read repository secrets and push a modified artifact, which is why Reviewdog GitHub Action supply chain attack matters for pipeline identity governance.
- A self-hosted runner inherits broad network access, letting an attacker use the runner identity to reach internal services after a compromised job starts.
- A build service account with overbroad permissions signs a malicious release, turning trusted automation into a code integrity problem, as seen in CI/CD pipeline exploitation case study.
- An npm or package publishing workflow leaks tokens into logs or artifacts, echoing patterns discussed in Shai Hulud npm malware campaign and the NIST Cybersecurity Framework 2.0 focus on protecting critical assets.
- Temporary deployment credentials are reused across environments, making one compromised job enough to access production.
These cases are often visible only after 52 NHI Breaches Analysis shows how frequently trusted identities are abused once attackers gain a foothold.
Why It Matters in NHI Security
CI/CD Identity Abuse is dangerous because pipeline identities are built to be trusted, automated, and fast. When that trust is not constrained, a single workflow compromise can expose secrets, corrupt artifacts, and create a durable foothold inside delivery systems. This is especially serious in NHI programs because pipeline identities often outnumber human-admin touchpoints and are rarely reviewed with the same rigor as privileged user accounts.
NHI Mgmt Group notes that Ultimate Guide to NHIs reports 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That statistic is directly relevant here because pipeline abuse often succeeds by reaching the very places where secrets are left exposed. The same risk pattern is reinforced by the Guide to the Secret Sprawl Challenge, where dispersed credentials make automation compromise much easier to monetise.
Organisations typically encounter CI/CD Identity Abuse only after an unexpected release, secret leak, or downstream compromise, at which point pipeline identity scoping becomes operationally unavoidable to address.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers identity sprawl, pipeline credentials, and overprivileged non-human accounts. |
| NIST CSF 2.0 | PR.AA-01 | Requires identities and credentials to be managed, authenticated, and authorized appropriately. |
| NIST Zero Trust (SP 800-207) | Zero Trust limits implicit trust in build systems and verifies every automation action. |
Segment pipelines, verify each job request, and eliminate standing trust for runners and deploy keys.
Related resources from NHI Mgmt Group
- What is workload identity federation and why is it important for CI/CD security?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- How should teams secure CI/CD pipelines against identity-based attacks?
- What is the difference between workflow hardening and CI/CD identity governance?
