Key CI/CD pipeline attack best practices are to protect credentials, isolate build runners, restrict who can change pipeline definitions, and verify artefacts before release. Teams should monitor for unauthorised code changes, secret exposure and unexpected build behaviour. Store signing keys separately, and review pipeline permissions and logs regularly.
How CI/CD pipeline attacks usually succeed
CI/CD attacks are rarely one-step compromises. They usually abuse trusted pipeline components such as source control events, build runners, secrets stores, package dependencies, release steps or signing workflows, then turn that trust into code execution or secret theft. The most important defensive idea is to treat pipeline trust as something to constrain, not something to assume.
Good defences start by recognising the pipeline as a high-value control plane, not just a delivery utility. If attackers can change pipeline definitions, poison a dependency, or capture a runner credential, they often gain a path to source code, build artefacts, release credentials or downstream production access.
That is why supply-chain integrity measures matter here. Practices such as pinned dependencies, artefact verification, and provenance checks reduce the chance that a compromised build step can silently produce trusted output, which is also why the SLSA model is a useful reference point for release integrity.
Which controls matter most in the pipeline itself?
The strongest controls are the ones that narrow what a compromised workflow can touch. Protecting credentials means reducing long-lived secrets in runners and logs, using short-lived tokens where possible, and separating signing material from ordinary build access. Isolating runners means avoiding shared, persistent execution environments that let one job inspect another job’s state or secrets.
Restricting who can change pipeline definitions is equally important because a malicious or mistaken workflow edit can be enough to steal credentials or alter release logic. That includes branch protections, required reviews, locked-down workflow file paths, and permission boundaries around who may approve build or release changes.
Verification before release should focus on whether the artefact was built from the expected source, in the expected environment, with the expected signing path. If the artefact cannot be traced back to a trusted build process, release confidence drops quickly even when the code looks legitimate.
For teams that want a practical identity-and-release lens, the CI/CD Pipeline Identity Security Guide is directly aligned with keyless federation, token permissions, pinned actions and trusted publishing. When the identity layer is weak, pipeline hardening usually fails at the exact point where automation is supposed to be safest.
What to watch for after hardening the pipeline
Even a well-designed pipeline can be undermined by earlier compromise. Unauthorised code changes, unexpected workflow edits, unusual token use, silent secret exposure, and build steps that suddenly behave differently are all signs that the delivery chain may already be under pressure.
Logs and permissions deserve regular review because many attacks leave operational traces before they become a public incident. A build that starts reaching unusual external destinations, printing unexpected environment values, or requesting wider permissions than normal should be treated as a security event, not just a flaky deployment.
Signing keys need special handling because they sit at the boundary between internal build trust and external release trust. Store them separately from routine build credentials, keep access limited, and rotate them when there is any reason to think the pipeline environment has been exposed.
Risk and Threat Considerations
CI/CD pipelines concentrate trust, so a single weak link can expose source code, artefacts, release channels, or the credentials used to publish software. That makes the attack surface unusually valuable to adversaries who want persistence, stealth, or downstream supply-chain reach.
Failure mechanism: An attacker compromises a runner, workflow definition, build token, dependency, or signing path, then uses that trusted position to exfiltrate secrets, alter output, or publish malicious artefacts that appear legitimate.
Impact: The result can be credential theft, tampered releases, lateral movement into adjacent systems, and a loss of trust in every artefact produced by the pipeline until the environment is revalidated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artefact integrity are central to CI/CD pipeline attack resistance. |
| Recommendation — Adopt SLSA provenance checks to verify release artefacts before promotion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipeline attacks often hinge on stolen or long-lived credentials and tokens. |
| AC-6 — Least Privilege | Pipeline jobs and runners should only have the access required for each stage. | |
| AU-6 — Audit Review, Analysis, and Reporting | Pipeline compromise signs often surface first in logs and permission anomalies. | |
| Recommendation — Rotate and tightly manage pipeline credentials, tokens and signing secrets. Restrict runner, workflow and release privileges to the minimum needed. Review build logs and access records for anomalous workflow or secret use. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Pipeline security depends on hardened delivery architecture and controlled release paths. |
| Recommendation — Design CI/CD flows so untrusted inputs cannot alter release-critical behaviour. | ||
Practitioner Guidance
What to prioritise: Start with the highest-blast-radius paths first, especially release credentials, signing keys, workflow-change permissions, and runner isolation. If a control protects both build execution and publication, it usually deserves earlier attention than cosmetic pipeline hygiene.
What to verify: Confirm that pipeline permissions are narrow enough for each job, that secrets are not reusable outside the intended stage, and that build outputs can be tied to a known source and build identity. If you cannot explain who or what was allowed to publish an artefact, the control set is not mature enough.
Practitioner takeaway: Treat CI/CD security as a trust-management problem, not just a tooling problem, because the most damaging failures happen when build automation is allowed to act with more privilege, persistence, or release authority than it truly needs.