Category: Software Supply Chain
CI/CD Security
Also known as: CI/CD Security, Software Pipeline Security, Pipeline Security, Continuous Integration and Continuous Delivery Security
Simply put
CI/CD security refers to the security practices and safeguards built into the automated pipelines that build, test, and deploy software. It aims to protect each stage of the pipeline from code integration through to delivery, preventing attackers from using the pipeline as a path to introduce malicious code or compromise production systems. These practices typically include access controls, secret management, dependency scanning, and policy enforcement at multiple points in the pipeline.
Formal definition
CI/CD security is the distribution of security controls, compliance safeguards, and risk management practices across the continuous integration and continuous delivery pipeline. It addresses threats at the code, build, test, and deployment stages, encompassing concerns such as source code integrity, build environment isolation, artifact provenance, secrets management, access control for pipeline infrastructure, and the security of third-party dependencies and tooling integrated into the pipeline. Because the pipeline automates the path from developer commit to production, a compromise at any stage may allow an adversary to tamper with build artifacts, exfiltrate secrets, or deploy malicious code without direct access to production systems. Effective CI/CD security requires controls at both the static analysis layer (such as SAST and SCA tooling executed during build steps) and the runtime or deployment layer (such as image scanning, policy enforcement gates, and environment hardening), as neither layer alone provides sufficient coverage.
Why it matters
CI/CD pipelines occupy a uniquely privileged position in a software organization's infrastructure. Because the pipeline automates the path from a developer's commit to production, a successful compromise at any stage can allow an adversary to tamper with build artifacts, exfiltrate secrets, or deploy malicious code without ever gaining direct access to production systems. This makes the pipeline an attractive target: rather than attacking a hardened production environment, an attacker may find it easier to subvert the build process itself.
Who it's relevant to
Software Engineers and Developers
Developers interact directly with CI/CD pipelines when committing code, configuring pipeline steps, and managing dependencies. They are responsible for avoiding practices that introduce pipeline risk, such as hardcoding secrets, using unpinned third-party actions, or granting excessive permissions to pipeline service accounts. Understanding CI/CD security helps developers recognize that the pipeline itself is an attack surface requiring the same care as the application code it builds.
DevOps and Platform Engineers
Platform and DevOps engineers design, build, and maintain the pipeline infrastructure. They are typically responsible for decisions about build environment isolation, artifact storage and signing, secret management systems, and access control for pipeline tooling. This group has the highest direct influence over the security posture of the pipeline and must balance security controls against pipeline performance and developer experience.
Application Security Engineers
AppSec engineers are responsible for selecting, configuring, and tuning the security tools integrated into the pipeline, including SAST, SCA, secret scanning, and container image scanning tools. They must account for the known false positive and false negative behavior of each tool, establish policy enforcement gates, and ensure that the scope of automated checks covers the relevant threat categories without producing noise levels that cause developers to ignore results.
Security Architects
Security architects design the overall security model for CI/CD infrastructure, including trust boundaries between pipeline stages, provenance and attestation strategies for build artifacts, and integration of pipeline controls into broader software supply chain security programs. They need to understand which threats are addressable through static controls in the pipeline and which require runtime or deployment-layer enforcement.
CISOs and Security Leadership
Security leaders are responsible for ensuring that CI/CD pipeline security receives appropriate investment and organizational priority alongside traditional perimeter and endpoint controls. High-profile supply chain compromises have demonstrated that the pipeline is a material risk area. Leadership must understand the pipeline's role as a privileged path to production and support the organizational changes needed to apply least-privilege access and security gate enforcement without impeding delivery velocity.
Compliance and Risk Professionals
Compliance and risk teams need to understand CI/CD pipelines as part of the software supply chain scope for frameworks and regulations that address software integrity, including emerging requirements around software bills of materials (SBOMs) and artifact provenance. Pipeline security controls may serve as evidence for compliance requirements related to change management, access control, and software integrity, making this an increasingly relevant domain for audit and risk functions.
Inside CI/CD Security
Pipeline Configuration Security
The hardening of pipeline definition files (such as YAML workflows) to prevent injection attacks, privilege escalation, and unauthorized modifications. Includes controls over who can edit pipeline definitions and how external inputs are handled within pipeline steps.
Secret Management
The secure storage, injection, and rotation of credentials, API keys, and tokens used by pipeline jobs. Secrets should be sourced from dedicated vaults or secret stores rather than hardcoded in configuration files or environment variables exposed to all pipeline steps.
Least Privilege for Pipeline Identities
The principle that pipeline runners, service accounts, and CI/CD system identities should hold only the permissions required for their specific tasks. Overly permissive identities are a common vector for lateral movement following a pipeline compromise.
Source Control Integration Controls
Branch protection rules, required code reviews, signed commits, and merge policies that govern which code changes can trigger pipeline execution and under what conditions, reducing the risk of malicious code entering the build process.
Dependency and Supply Chain Controls
Mechanisms for verifying the integrity and provenance of third-party packages, base images, and build tools consumed during pipeline execution. Typically includes pinning dependency versions, verifying checksums, and using private artifact mirrors.
Build Environment Isolation
The use of ephemeral, containerized, or otherwise isolated build environments to limit the blast radius of a compromised build job. Persistent or shared build agents accumulate state that may be exploited across builds.
Artifact Integrity and Signing
The process of cryptographically signing build outputs and verifying those signatures at deployment time to ensure that artifacts have not been tampered with between build and release stages.
Automated Security Testing Integration
The embedding of security scanning tools within pipeline stages, including SAST, SCA, container image scanning, and secrets detection, so that security checks are enforced as part of the standard build and release process rather than as optional post-build steps.
Pipeline Access Control and Auditability
Controls governing which users and systems can trigger, modify, or approve pipeline runs, combined with comprehensive logging of pipeline activity to support detection of unauthorized changes and forensic investigation.
Third-Party Action and Plugin Vetting
The evaluation and governance of external actions, plugins, or shared pipeline components sourced from public registries. Unvetted third-party pipeline components represent a supply chain risk as they execute with the same trust level as first-party pipeline code.
Common questions
Answers to the questions practitioners most commonly ask about CI/CD Security.
Does securing the CI/CD pipeline mean the deployed application itself is secure?
No. CI/CD security focuses on protecting the pipeline infrastructure, build processes, and software supply chain integrity. It does not substitute for application security testing, runtime protection, or secure configuration of the deployed application. A hardened pipeline can still deliver a vulnerable application if the application code itself contains security flaws.
If we add security scanning tools to our CI/CD pipeline, are we covered against supply chain attacks?
Scanning tools in a pipeline address specific, bounded categories of risk such as known vulnerable dependencies or secrets committed to source code. Supply chain attacks can also occur through compromised build tools, tampered pipeline configurations, malicious contributors with legitimate access, or infrastructure hosting the pipeline itself. Scanning alone is not sufficient coverage for the full supply chain threat model.
What is the minimum set of controls typically recommended when first implementing CI/CD security?
Practitioners typically start with secrets management to prevent credentials from being stored in source code or pipeline configuration, dependency scanning to identify known vulnerable components, and strict access controls on pipeline configuration files and runner environments. These three areas address the most commonly exploited weaknesses in early-stage CI/CD security programs.
How should teams handle security findings that block a pipeline when the fix cannot be completed immediately?
Most CI/CD security programs implement a formal exception or waiver process. A finding can be acknowledged with a documented risk acceptance, a compensating control, or a tracked remediation deadline, allowing the pipeline to proceed without silently ignoring the issue. The key requirement is that the exception is recorded, time-bounded, and reviewed by an appropriate owner rather than suppressed without accountability.
What is the difference between securing the pipeline configuration and securing the pipeline runtime environment?
Securing pipeline configuration typically involves controlling who can modify workflow files, job definitions, and trigger conditions, and ensuring those files are version-controlled and reviewed. Securing the runtime environment involves hardening the build agents or runners, isolating job execution, controlling network access from build environments, and ensuring ephemeral or clean environments are used to prevent artifact contamination between builds. Both layers are required and address different attack surfaces.
How do artifact signing and provenance attestations contribute to CI/CD security?
Artifact signing allows consumers of a build output to verify that the artifact was produced by an expected pipeline and was not tampered with after the build completed. Provenance attestations provide a verifiable record of how, when, and from what inputs an artifact was built. Together they support integrity verification further down the supply chain, but they are only meaningful if the signing keys are protected and the attestation generation process itself occurs in a trusted build environment.
Common misconceptions
Enabling automated security scans in a CI/CD pipeline means the pipeline is secure.
Automated security testing addresses the security of the software being built, but does not by itself secure the pipeline infrastructure. A pipeline can run comprehensive SAST and SCA scans while remaining vulnerable to pipeline-level attacks such as secret exfiltration, malicious dependency injection, or compromise of the runner environment. Pipeline security requires hardening the CI/CD system itself, not only what it tests.
Using a managed or cloud-hosted CI/CD platform transfers security responsibility to the vendor.
Managed CI/CD platforms handle availability and underlying infrastructure security, but pipeline configuration, secret management, access control, and the integrity of pipeline definitions remain the responsibility of the adopting organization. Misconfigured pipelines on managed platforms are a common source of credential exposure and supply chain incidents.
CI/CD security is primarily a concern for large organizations with complex pipelines.
Smaller organizations and open-source projects are frequently targeted precisely because their pipelines may receive less security attention. Any pipeline with access to production credentials, package registries, or deployment infrastructure represents a meaningful attack surface regardless of organizational size.
Best practices
Pin all third-party pipeline actions, plugins, and dependencies to specific verified versions or commit hashes rather than mutable tags, and verify integrity through checksums or signatures before use in a build.
Apply least privilege to all pipeline identities and service accounts, scoping permissions to the minimum required for each individual job, and use short-lived credentials or workload identity federation rather than long-lived static secrets where the CI/CD platform supports it.
Store secrets exclusively in a dedicated secret management system and inject them into pipeline jobs at runtime with scoped access, rather than storing them as plaintext in repository files, pipeline configuration, or broadly accessible environment variables.
Enforce branch protection rules and require code review approval before pipeline-triggering merges, ensuring that changes to both application code and pipeline definition files are subject to human review and cannot be introduced unilaterally.
Use ephemeral, isolated build environments for each pipeline run rather than persistent shared agents, reducing the risk that a compromised build job can persist malicious state or access artifacts from unrelated builds.
Maintain comprehensive audit logs of pipeline executions, configuration changes, and access events, and review these logs as part of regular security operations to detect anomalous behavior such as unexpected secret access or pipeline modification by unauthorized users.