A CI/CD pipeline is an automated sequence that builds, tests and deploys software changes. It links source control, code checks, packaging and release steps so code can move from commit to production through repeatable stages with defined gates, approvals and rollback points.
What a CI/CD pipeline is responsible for
A CI/CD pipeline is the delivery control plane for software change. It decides when code is built, tested, packaged and promoted, and it turns those steps into repeatable gates instead of ad hoc release work. That makes the pipeline a security boundary as well as a delivery mechanism, because it concentrates the trust placed in source control, automation, build runners and deployment approvals.
In practice, the pipeline is where engineering intent becomes an executable path to production. If its triggers, permissions or artefact handling are weak, the pipeline can move untrusted change just as efficiently as trusted change.
How CI/CD pipelines work across the delivery chain
Most pipelines follow the same basic sequence: detect a change, validate it, build an artefact, run tests, approve promotion and deploy. Each stage narrows the set of changes that can continue, so the pipeline becomes a series of controlled decisions rather than one monolithic release event.
That structure is valuable because it separates concerns. Source control records what changed, build steps create something deployable, test stages check behaviour, and release stages decide whether the output is ready for a target environment. The security value comes from making those transitions explicit and auditable.
Because the pipeline is automated, its integrity depends on the rules surrounding the automation: who can trigger it, what inputs it accepts, which secrets it can reach, and whether it treats third-party actions, plugins or dependencies as trusted by default.
Why CI/CD pipelines are security-sensitive
CI/CD systems often hold the exact assets attackers want: source code, signing keys, deployment credentials, cloud tokens, package-publishing permissions and artefacts that will later be trusted by customers or production systems. A compromise at any point in the pipeline can therefore become a software supply-chain event, not just a build failure.
Pipeline risk is amplified by inheritance. Once a workflow or runner is trusted, it may carry that trust into code execution, secrets access and release approval. That is why pipeline compromise can lead to poisoned builds, secret exposure, tampered releases or deployment of malicious code that appears legitimate.
Many of the most important controls map to supply-chain integrity and trusted release practices. For a broader control lens on build provenance and artefact integrity, see SLSA.
Common failure modes and what they change
The most important failure modes are not usually syntax errors, but trust errors: overly broad workflow permissions, unpinned third-party actions, insecure pull-request handling, exposed secrets in logs or artefacts, and weak separation between untrusted builds and privileged release paths. These issues can let an attacker inject code, steal tokens, alter artefacts or move from a compromised repository into downstream systems.
Pipeline compromise also changes the identity picture. The damage often comes from stolen or overprivileged automation credentials, not from the pipeline code itself. That means release tokens, OIDC federation, service credentials and signing material need explicit lifecycle and privilege control, because they are part of the pipeline’s security model, not merely implementation detail.
Detection matters too. Pipeline attacks can look like normal automation unless logs, build metadata and workflow changes are retained and monitored. If the organisation cannot reconstruct what ran, what secrets were exposed and what artefacts were published, post-incident review becomes guesswork.
For a practical view of pipeline exploitation patterns and secret exposure, see CI/CD pipeline exploitation case study and ArtiPACKED 2024.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD pipelines create and promote build artefacts, so SLSA directly governs provenance and integrity. |
| Recommendation — Adopt SLSA to harden build provenance, signing and artefact integrity across the delivery pipeline. | ||
| OWASP SAMM | Software Assurance Maturity Model | CI/CD pipelines are a core software delivery practice where assurance maturity must be embedded. |
| Recommendation — Use SAMM to assess and improve security practices across build, test and release activities. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Pipeline changes and release permissions need controlled approval and restriction. |
| AU-2 — Event Logging | Pipeline execution and workflow changes require auditability for incident review and accountability. | |
| IA-5 — Authenticator Management | CI/CD pipelines rely on secrets, tokens and keys that must be managed across their lifecycle. | |
| Recommendation — Enforce CM-5 to restrict and approve changes that affect pipeline behaviour and release paths. Implement AU-2 logging for pipeline runs, approvals and workflow changes. Apply IA-5 to rotate and protect pipeline credentials, tokens and signing material. | ||
Practitioner guidance
Why practitioners should care: A CI/CD pipeline is only as trustworthy as the permissions, inputs and artefacts that flow through it. Treat pipeline governance as release governance, because the pipeline often determines what code can reach production and which identities can publish it.
What to watch for: Look closely at third-party actions, secret exposure paths, build logs, self-hosted runners, and any workflow that mixes untrusted contributions with privileged triggers. Those are the places where delivery convenience most often turns into release risk.
Practitioner takeaway: The safest pipelines assume that code, dependencies and contributors are not inherently trusted, and they make that assumption visible in the workflow design.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org