An attack that targets the software delivery pipeline rather than only the final application. The goal is to compromise builds, dependencies, signing, publishing, or deployment steps so malicious code, stolen secrets, or tampered artifacts reach downstream environments through trusted automation.
Expanded Definition
A CI/CD supply chain attack targets the delivery machinery that moves code from commit to production, not just the application itself. It focuses on trusted build and release steps such as source repositories, dependency managers, build runners, signing keys, artifact registries, and deployment automation. Because these systems are designed to speed delivery and inherit trust across stages, compromise in one place can quietly affect many downstream environments.
In security terms, this attack class sits at the intersection of software assurance, secrets protection, and privileged automation. The most dangerous variants do not break the product directly; they abuse the pipeline’s own authority to insert malicious dependencies, alter build outputs, steal tokens, or publish tampered packages. Guidance is still evolving across vendors, but the core idea is consistent: if the delivery chain can be trusted blindly, it can also be weaponised. NIST control families and industry reporting on build integrity make the risk explicit, while CISA cyber threat advisories regularly highlight supply chain tradecraft affecting software delivery. The most common misapplication is treating this as only a source-code problem, which occurs when teams ignore build systems, signing material, and automation credentials.
Examples and Use Cases
Implementing CI/CD security rigorously often introduces friction in developer velocity, requiring organisations to weigh release speed against stronger verification, isolation, and approval steps.
- A malicious package is introduced through a dependency update and is fetched automatically during the build, causing a backdoored artifact to be signed and deployed.
- An attacker steals a pipeline token from an over-permissioned runner and uses it to publish altered images or binaries into a trusted registry.
- A compromised self-hosted build agent changes test or packaging outputs so the final release appears legitimate while carrying embedded malware.
- Build provenance and signing gaps allow an attacker to replace an artifact after compilation but before deployment, defeating downstream trust assumptions. This is a common concern in guidance that references NIST control frameworks and software integrity practices.
- In agentic AI environments, an autonomous agent with tool access can become part of the supply chain if it can approve, generate, or publish code, making identity and workload trust boundaries critical. The OWASP perspective on machine identities in OWASP Non-Human Identity Top 10 is especially relevant here.
Why It Matters for Security Teams
CI/CD supply chain attacks matter because they turn trusted automation into a blast-radius multiplier. A single compromised pipeline credential, signing key, or build runner can undermine release integrity across multiple products, tenants, or environments. For security teams, this means conventional perimeter thinking is not enough. Controls need to cover source integrity, dependency governance, build isolation, provenance, least privilege, and short-lived credentials for non-human identities that operate the pipeline. The identity angle is now unavoidable: pipeline workers, service accounts, and agentic systems all act with delegated authority, so weak NHI governance can become a delivery-path compromise.
Teams also need visibility into indicators that resemble post-compromise behaviour rather than normal developer activity. Threat reports from Anthropic — first AI-orchestrated cyber espionage campaign report and MITRE ATT&CK Enterprise Matrix reinforce how attackers blend into legitimate tooling and automation. Organisations typically encounter build tampering, unauthorised publishing, or secret exposure only after a release has propagated, at which point CI/CD supply chain attack response becomes operationally unavoidable.
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-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Protects integrity of data and software transmitted through the pipeline. |
| NIST SP 800-53 Rev 5 | SA-12 | Defines supply chain protection controls for system components and software. |
| OWASP Non-Human Identity Top 10 | NHI-2 | Covers machine identities and secrets used by CI/CD automation. |
| NIST Zero Trust (SP 800-207) | AC-4 | Supports segmentation and policy enforcement for high-trust build paths. |
| NIST AI RMF | Relevant where AI agents participate in code generation or release workflows. |
Inventory pipeline identities and rotate their secrets with least privilege and short-lived access.
Related resources from NHI Mgmt Group
- Why do CI/CD secrets create such a large blast radius in supply chain attacks?
- How should security teams reduce the impact of CI/CD supply chain compromise?
- Who is accountable when a package token is abused in a supply-chain attack?
- How should security teams handle exposed developer secrets after a supply chain attack?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
