What should organisations do when CI/CD pipelines carry application risk forward?

Why This Matters for Security Teams

CI/CD pipelines are not just delivery plumbing. They decide which code is built, which secrets are exposed to builds, which artefacts are promoted, and which runtime configurations are trusted. When that path is weak, a small source control issue can become a production incident without ever touching a user-facing control. That is why current guidance treats pipelines as part of the security boundary, not as a neutral transport layer. NIST’s Cybersecurity Framework 2.0 is useful here because it emphasises governance, identity, and change control across the lifecycle, not only at deployment time. NHIMG research shows how often non-human paths are already the failure point: in The 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they have experienced or suspect a breach of non-human identities. For CI/CD, that matters because build systems, deploy keys, signing services, and automation tokens are all NHIs with broad reach. In practice, many security teams encounter pipeline abuse only after a compromised token has already been used to promote an insecure artefact into production.

How It Works in Practice

The practical goal is to reduce trust in the pipeline and make every privileged step explicit, short-lived, and attributable. That starts with separating source change approval from build execution, then binding each stage to a distinct workload identity rather than a shared credential set. Build jobs should authenticate as machines with scoped identity, not as reusable service accounts that outlive the job. Where possible, use ephemeral credentials issued just for the task, then revoke them automatically when the job ends. A sound operating model usually includes:

• Protected branches and signed commits for source integrity
• Isolated build runners with minimal network reach
• Short-lived secrets injected only at runtime, never stored in logs or artefacts
• Artifact signing and verification before promotion
• Policy checks that block deployment when code, dependency, or configuration risk exceeds threshold

This is where identity and governance overlap. The pipeline should be able to prove what it is, what it is allowed to do, and why a particular promotion was authorised. The Guide to the Secret Sprawl Challenge is directly relevant because secret exposure is often what turns a pipeline compromise into lateral movement. For implementation discipline, the CI/CD pipeline exploitation case study illustrates how attackers exploit implicit trust between build, package, and release stages. The right control set is not just about blocking merges. It is about ensuring that build-time credentials cannot be reused for deploy-time action, that release promotion requires fresh authorisation, and that tampered artefacts fail verification before production can consume them. These controls tend to break down in highly parallel build environments with shared runners and broad secret injection because the trust boundaries become too coarse to enforce stage-by-stage separation.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery friction, requiring organisations to balance deployment speed against blast-radius reduction. That tradeoff is real, especially for teams that release many times a day or rely on ephemeral preview environments. Best practice is evolving, but the current consensus is that speed should come from automation and policy, not from broad credential reuse. Edge cases usually appear in three places. First, legacy pipelines may depend on long-lived deploy keys that cannot be rotated quickly without downtime. Second, monorepos and multi-team build farms can make it hard to apply different trust levels to different artefacts. Third, external CI services can introduce hidden trust dependencies when artefact signing, secret storage, and runner isolation are managed outside the organisation’s own controls. A useful rule is to classify every pipeline credential by purpose and lifespan. If it can build, it should not automatically deploy. If it can deploy, it should not be able to rewrite source. If it can access secrets, it should only receive them for the exact job that needs them. That approach aligns with the Top 10 NHI Issues and the broader lesson from NHIMG: pipelines fail most often when organisations assume automation is trustworthy simply because it is internal.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• Why do CI/CD pipelines create non-human identity risk?
• Why do CI/CD pipelines increase lateral movement risk?
• How can organisations tell whether shadow AI is becoming a material risk?