CI/CD Pipeline

Expanded Definition

A CI/CD pipeline is the automated delivery system that compiles code, runs tests, packages artifacts, and promotes releases. In NHI security, the critical issue is not the build step itself but the privileged secrets, tokens, and service credentials the pipeline uses to reach source control, registries, cloud platforms, and deployment targets.

Definitions vary across vendors on where the pipeline ends and where adjacent automation begins, especially when build runners, Git hooks, artifact signing, and GitOps controllers are involved. For governance purposes, NHI Management Group treats the pipeline as the full execution path that can authenticate on behalf of software, people, or agents. That makes it a high-value identity boundary, not just an engineering workflow. The closest standards lens is NIST Cybersecurity Framework 2.0, which frames pipeline protection through asset visibility, access control, and recovery readiness.

The most common misapplication is assuming a trusted pipeline cannot be a compromise path, which occurs when long-lived credentials are embedded in build jobs, runner images, or shared variables.

Examples and Use Cases

Implementing CI/CD pipeline security rigorously often introduces friction in developer velocity, requiring organisations to weigh fast release automation against tighter credential handling, approval gates, and runner isolation.

• A release job authenticates to cloud infrastructure with a short-lived token rather than a static API key, reducing the blast radius if the job log or artifact store is exposed.
• A build runner is treated as a sensitive NHI endpoint, with ephemeral provisioning and no standing access to production secrets. The operational lesson is reinforced by the CI/CD pipeline exploitation case study.
• Secrets are pulled from a dedicated vault at execution time instead of being stored in environment variables or repository settings, which lowers exposure during forked builds and debug sessions.
• Pipeline permissions are split by function, so code checkout, artifact signing, and deployment each use separate identities aligned to NIST Cybersecurity Framework 2.0 access-control intent.
• After a supply chain incident, teams often review patterns documented in Reviewdog GitHub Action supply chain attack to identify where third-party actions expanded trust unexpectedly.

These use cases show that secure pipelines are less about one control and more about repeated identity decisions at every stage of automation.

Why It Matters in NHI Security

CI/CD pipelines matter because they concentrate privileged access in systems that are often broadly trusted, heavily automated, and insufficiently monitored. When a pipeline is compromised, attackers do not need to break into production directly; they can inherit the pipeline’s permissions and move laterally through source control, artifact stores, cloud APIs, and deployment targets. That is why pipeline security is inseparable from NHI governance.

NHIMG research shows the scale of the problem: in The State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. This is the practical proof that build infrastructure can become the attack surface. It also explains why secret sprawl in pipelines is so dangerous when paired with agentic automation, where an Guide to the Secret Sprawl Challenge mindset is needed to stop credentials from being copied into logs, job outputs, and ephemeral workspaces.

Organisations typically encounter CI/CD risk only after a release compromise, exposed token, or malicious action has already altered the delivery chain, at which point pipeline identity governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do I implement secrets scanning in a CI/CD pipeline?
• CI/CD Pipeline Identity
• What is workload identity federation and why is it important for CI/CD security?
• How should teams respond when CI or developer secrets are exposed?