Software Delivery Pipeline

A software delivery pipeline is the chain of systems used to build, test, and deploy code into production. It includes repositories, automation workflows, build tools, and deployment services. Because these systems hold high trust, they become attractive targets when access controls are weak or poorly inventoried.

Expanded Definition

A software delivery pipeline is the trusted automation path that moves source code from commit to release, typically across repositories, build runners, test systems, artifact stores, and deployment controllers. In NHI security, the pipeline matters because it is not just an engineering workflow; it is a high-privilege identity environment where secrets, tokens, and service accounts often have broad reach.

Definitions vary across vendors on where the pipeline begins and ends. Some teams treat only CI/CD tooling as the pipeline, while others include source control, package registries, infrastructure provisioning, and release orchestration. For NHI governance, the broader interpretation is usually more useful because compromise can occur at any trust boundary where an automated identity can authenticate, fetch secrets, or push code. NIST Cybersecurity Framework 2.0 frames the need to manage these trust relationships as part of risk governance and access control, which is directly relevant to pipeline design NIST Cybersecurity Framework 2.0.

The most common misapplication is treating the pipeline as a purely technical build path, which occurs when teams ignore the identities, credentials, and permissions that make every automated step possible.

Examples and Use Cases

Implementing software delivery pipeline controls rigorously often introduces friction, because every added approval, secret check, or deployment gate can slow release speed and require more coordination across engineering and security.

• A GitHub Actions workflow uses a short-lived token to fetch package dependencies and deploy a container image, so the pipeline identity must be scoped tightly and rotated quickly. The Reviewdog GitHub Action supply chain attack shows how a single trusted action can expose secrets at scale.
• A build server signs artifacts before release, making the signing key and its access path part of the pipeline’s trust boundary. If that key is embedded in a runner or shared across projects, the pipeline becomes a high-value target rather than a delivery tool.
• A Kubernetes deployment stage pulls manifests from a private repo and applies them to production, which means repository access and cluster credentials must be governed together. The CI/CD pipeline exploitation case study illustrates how attackers chain pipeline access into production impact.
• A dependency update job runs automatically on a schedule, but the job token also has write access to release branches. That overreach turns routine maintenance into a potential code injection path, which is why least privilege matters across every automation identity.
• A package publish step uses a secret stored in the CI platform rather than a dedicated secrets manager, increasing exposure if logs, plugins, or third-party actions are compromised. This pattern overlaps with the broader secret sprawl problem described in the Guide to the Secret Sprawl Challenge.

Why It Matters in NHI Security

Software delivery pipelines are where NHI risk becomes operational, because they concentrate machine identities that can create, modify, and release production assets. When access is weak, the pipeline becomes a convenient path for attackers to steal credentials, alter build artifacts, or implant malicious code. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools, which makes delivery systems one of the most common places where NHI exposure is discovered Ultimate Guide to NHIs.

This matters because a compromise in the pipeline is not limited to one application. It can affect every downstream release, every environment that trusts the artifact, and every identity that inherits its credentials. NIST guidance on access governance reinforces the need to control who and what can make security-sensitive changes in automated systems NIST Cybersecurity Framework 2.0. In practice, pipeline security also depends on visibility into service accounts, short-lived credentials, and revocation paths. Organisations typically encounter this consequence only after a build token, signing key, or deployment secret has already been abused, at which point software delivery pipeline governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams implement Kubernetes dependency scanning across the software delivery pipeline?
• How can teams reduce software supply chain risk without slowing delivery?
• How can organisations reduce trust sprawl in software delivery?
• How should security teams reduce risk in software delivery pipelines with NHI controls?