Skip to main content
Application Security Standards
Category: Software Supply Chain

Pipeline Security

Also known as: Build Pipeline Security, Software Pipeline Security, CI/CD Pipeline Security
Simply put

Pipeline security is the practice of protecting the systems, tools, and processes used to build, test, and deploy software from cyber threats and vulnerabilities. It focuses on ensuring that each stage of the software development and delivery lifecycle cannot be compromised or tampered with. This helps prevent attackers from injecting malicious code or gaining unauthorized access through the build and deployment process.

Formal definition

Pipeline security refers to the protection of software development and deployment pipelines, encompassing the systems, tools, processes, and integrations involved in building, testing, and releasing software. In the application security and software supply chain context, it typically covers controls applied across CI/CD stages, including source code integrity, dependency validation, build environment isolation, artifact signing and verification, and deployment gate enforcement. Practitioners distinguish pipeline security from broader infrastructure security in that its scope is bounded to the software delivery workflow rather than general network or endpoint protection. Note: the term 'pipeline security' may also refer, in critical infrastructure contexts, to the physical and cyber protection of oil, gas, or other material transport pipelines as addressed by TSA and CISA programs; the two usages are distinct and should not be conflated.

Why it matters

The software build and deployment pipeline has become one of the most targeted attack surfaces in modern software development. Because pipelines have privileged access to source code, secrets, build infrastructure, and production deployment mechanisms, a compromise at any stage can propagate malicious changes across every downstream artifact and environment. Attackers who gain a foothold in a CI/CD pipeline can inject backdoors into software before it is signed and shipped, bypassing many traditional endpoint and network controls that would otherwise detect tampering.

Real-world incidents have demonstrated the severity of pipeline compromises. The SolarWinds attack, for example, involved adversaries inserting malicious code into the software build process, resulting in trojanized updates distributed to thousands of customers. This class of attack is particularly difficult to detect because the malicious code is introduced during the legitimate build process, causing signed and verified artifacts to carry the compromise. Pipeline security controls aim to reduce this risk by establishing integrity checks, access restrictions, and auditability at each stage of the delivery workflow.

As organizations increasingly rely on automation, third-party integrations, and shared build infrastructure, the attack surface of a typical pipeline grows correspondingly. Compromised dependencies, misconfigured secrets management, and overly permissive pipeline credentials are among the most common vectors practitioners encounter. Addressing pipeline security is therefore not only a technical concern but also an organizational one, requiring clear ownership, policy enforcement, and continuous monitoring across the full software delivery lifecycle.

Who it's relevant to

DevOps and Platform Engineers
Platform and DevOps engineers are typically responsible for designing, maintaining, and securing the CI/CD infrastructure. They configure access controls, secrets management, build environment isolation, and artifact signing mechanisms, making them primary implementers of pipeline security controls.
Application Security Engineers
AppSec practitioners are responsible for defining and enforcing security gates within pipelines, such as integrating static analysis, dependency scanning, and policy checks into the build process. They help establish what constitutes a passing security posture before artifacts are promoted or deployed.
Software Supply Chain Security Teams
Teams focused on software supply chain risk evaluate pipeline security as a core component of ensuring that software delivered to customers has not been tampered with during the build or distribution process. They may govern artifact provenance, signing requirements, and third-party dependency validation policies.
Security Architects
Security architects designing software delivery systems need to account for pipeline security as a distinct threat domain, separate from general infrastructure or network security. They define trust boundaries between pipeline stages, specify isolation requirements, and ensure that deployment credentials and signing keys are protected appropriately.
Compliance and Risk Professionals
Compliance teams operating in regulated industries may encounter pipeline security requirements through frameworks and guidance from bodies such as CISA and TSA, as well as through software supply chain-focused standards. They are responsible for mapping organizational pipeline controls to applicable regulatory expectations and demonstrating auditability of the software delivery process.
Engineering Leadership and CISOs
Senior leaders are increasingly accountable for the integrity of software their organizations produce or consume. Pipeline security failures can result in the distribution of compromised software to customers at scale, creating significant legal, reputational, and operational exposure. Understanding pipeline security as a strategic risk area is relevant to executive decision-making around tooling investment, vendor selection, and incident response planning.

Inside Pipeline Security

Source Code Repository Controls
Access controls, branch protection rules, and commit signing requirements that govern who can introduce changes into the codebase and under what conditions those changes are accepted.
Build Environment Integrity
Measures to ensure the build system itself has not been tampered with, including ephemeral build environments, verified toolchain provenance, and isolation between concurrent build jobs.
Dependency Management and Verification
Processes for validating the integrity and provenance of third-party packages and libraries consumed during the build, typically including checksum verification and lockfile enforcement.
Automated Security Testing Integration
The embedding of security scanning tools (such as SAST, SCA, and secret detection) as pipeline stages so that security checks run consistently on every change without requiring manual invocation.
Secrets Management
Controls that prevent credentials, API keys, and other sensitive values from being stored in source code or pipeline configuration files, and that govern how secrets are injected into pipeline jobs at runtime.
Artifact Signing and Provenance
Mechanisms for cryptographically signing build outputs and recording metadata about how and where an artifact was produced, enabling downstream consumers to verify authenticity and origin.
Access Control and Least Privilege for Pipeline Agents
Restrictions on the permissions held by the automated pipeline process itself, limiting what systems, credentials, and resources a pipeline job can access during execution.
Audit Logging and Change Traceability
Immutable records of pipeline activity, configuration changes, and job execution history that support incident investigation and compliance requirements.

Common questions

Answers to the questions practitioners most commonly ask about Pipeline Security.

Does securing the CI/CD pipeline mean the application itself is secure?
No. Pipeline security and application security are distinct concerns. A hardened pipeline ensures that the build and delivery process has not been tampered with and that artifacts are produced from verified sources, but it does not remediate vulnerabilities in the application code itself. Both must be addressed independently.
If secrets are stored in a secrets manager rather than hardcoded, is the pipeline fully protected from credential-related risk?
Not entirely. While using a secrets manager eliminates the most common form of credential exposure, risks remain. Overly permissive access policies, insecure injection of secrets into environment variables at runtime, insufficient secret rotation, and inadequate audit logging of secret access can all introduce residual credential-related risk even when hardcoded secrets are absent.
How should teams prioritize which pipeline stages to secure first?
Teams should typically begin with the stages that introduce the highest risk if compromised. Source code integrity controls and secrets management are commonly addressed first, as compromises at those points can affect all downstream stages. Artifact signing and dependency verification are also high-priority controls, since they protect against supply chain tampering that may otherwise go undetected.
What access control principles apply specifically to CI/CD pipeline infrastructure?
The principle of least privilege applies throughout. Pipeline service accounts and build agents should be granted only the permissions required for their specific tasks. Separation of duties between build, test, and deployment roles is advisable. Human access to pipeline configuration should be audited, and direct modification of pipeline definitions outside of version-controlled processes should typically be restricted.
How can organizations verify that pipeline configuration changes have not been tampered with?
Storing pipeline configuration as code in a version-controlled repository, enforcing protected branch policies, requiring code review for pipeline definition changes, and generating audit logs of configuration modifications are common controls. In some environments, cryptographic signing of pipeline definitions provides additional assurance that configurations have not been altered outside of approved processes.
What logging and monitoring practices are most relevant for pipeline security?
Effective pipeline security monitoring typically includes logging of all build triggers and their sources, recording of artifact provenance and signing events, alerting on unexpected changes to pipeline configuration, monitoring of secrets access events from the secrets manager, and retaining audit trails sufficient to support incident investigation. Logs should be stored in a location that pipeline processes themselves cannot modify.

Common misconceptions

Adding security scanning tools to a pipeline means the pipeline is secure.
Security scanning addresses the analysis of code and dependencies, but pipeline security also encompasses the integrity of the build infrastructure itself, access controls on pipeline configuration, secrets handling, and artifact provenance. A pipeline that runs SAST but allows any contributor to modify pipeline definitions without review remains materially insecure.
Pipeline security controls only need to protect against external attackers.
Many pipeline compromises originate from insider threats, compromised developer credentials, or malicious contributions through legitimate-looking pull requests. Controls such as branch protection, code review requirements, and least-privilege job permissions are relevant regardless of whether the threat actor is internal or external.
Once a pipeline security configuration is established, it requires little ongoing maintenance.
Pipeline security posture degrades over time as new integrations are added, permissions accumulate, toolchain components are updated, and threat patterns evolve. Periodic review of pipeline configurations, dependency pinning, and access grants is necessary to maintain an effective security posture.

Best practices

Enforce branch protection rules that require code review approvals and passing pipeline checks before any change is merged, including changes to pipeline configuration files themselves.
Use ephemeral, isolated build environments for each pipeline job to prevent state or credential leakage between runs and reduce the blast radius of a compromised build step.
Pin all dependencies, base images, and pipeline action references to specific verified versions or digests rather than mutable tags, and verify checksums or signatures before use.
Apply least-privilege principles to pipeline agent credentials by scoping permissions to only what each individual job requires, and rotate or invalidate those credentials after the job completes.
Store secrets exclusively in a dedicated secrets management system and inject them into pipeline jobs at runtime rather than embedding them in repository files or pipeline configuration.
Generate and store signed provenance attestations for build artifacts so that deployment systems and downstream consumers can verify the artifact's origin and the conditions under which it was produced.