| Myth | Reality |
|---|---|
| If application code is reviewed and scanned, the pipeline that builds it doesn’t need separate security attention. | Attackers who compromise the build system can inject malicious code after review and before compilation, bypassing code review entirely — the SolarWinds and multiple 2025-2026 GitHub Action supply chain attacks all targeted the build process, not the source code. |
| Long-lived CI/CD service account credentials are fine as long as they’re stored in a secrets manager. | A securely stored but long-lived, broadly-scoped credential is still a standing target. Short-lived, narrowly-scoped, just-in-time credentials limit the blast radius even if the secrets manager itself is compromised. |
| Third-party CI/CD actions and plugins from a public marketplace are safe if they have many stars or downloads. | Popularity is not provenance. Several 2025-2026 incidents (including compromises of widely used GitHub Actions) show that popular, trusted community actions can be hijacked or have malicious updates pushed without warning. |
Why the Build System Became the Target
For years, application security programs focused overwhelmingly on the code itself — static analysis, dependency scanning, code review. That focus made sense when the biggest risk was a vulnerability shipped in your own code. It made less sense once attackers realized that compromising the CI/CD pipeline gives them something far more valuable: the ability to inject malicious code into every artifact the pipeline produces, signed with your own organization’s legitimate build credentials, distributed to every customer or environment that trusts your releases.
The SolarWinds attack remains the reference case — attackers compromised the build system itself and inserted malicious code into the compilation process, producing a trojanized but legitimately signed update that shipped to roughly eighteen thousand customers. That pattern has repeated at smaller scale continuously since. Between December 2024 and March 2026 alone, security researchers tracked at least six significant supply chain attacks targeting CI/CD build environments directly, including compromises of widely used GitHub Actions such as trivy-action, tj-actions, and reviewdog, plus incidents affecting LiteLLM, Telnyx, and Ultralytics build pipelines. None of these required finding a vulnerability in the target application’s own code — each one compromised something the build depended on.
That shift in attacker behavior means CI/CD pipeline security has to be treated as its own discipline, not an afterthought bolted onto application security. This guide covers the five areas that matter most: isolating the build runners themselves, injecting secrets without ever writing them to disk or logs, signing commits and artifacts so tampering is detectable, defending against the specific supply chain attack patterns targeting pipelines today, and controlling who can change the pipeline configuration in the first place.
Runner and Agent Isolation
CI/CD runners execute arbitrary, often third-party code — your own build scripts, but also every dependency, every plugin, and every community action referenced in the pipeline definition. Treating a runner as trusted, general-purpose infrastructure is the single most common structural mistake in pipeline security.
Isolation Checklist
- Treat every runner as untrusted by default and assume any job running on it could attempt to escape into the host or reach other jobs’ data.
- Use ephemeral, single-use runners that are destroyed after each job rather than long-lived, reused runner instances that can accumulate state or cached credentials across jobs.
- Isolate jobs with strong sandboxing — microVMs (Firecracker) or gVisor rather than a shared container runtime with weak isolation boundaries — for any job executing untrusted or third-party code.
- Separate runners by trust tier: a runner executing a pull request from an external contributor should never share infrastructure with a runner that has production deployment credentials.
- Restrict outbound network access from build runners to an explicit allowlist of required destinations (package registries, artifact stores) rather than unrestricted internet access.
- Disable self-hosted runners on public repositories for pull requests from forks, or require manual approval before a fork’s workflow runs, since this is one of the most common real-world CI/CD compromise vectors.
Figure: Trust tiers for CI/CD runner infrastructure
Untrusted, fork-triggered pull request builds run on fully isolated, network-restricted, ephemeral runners with no access to secrets. Trusted internal builds run on a separate runner pool with scoped, short-lived credentials. Production deployment jobs run on the most restricted tier, with just-in-time credentials, mandatory approval gates, and full audit logging, physically or logically separated from the runners handling untrusted input.
Secrets Injection: Short-Lived, Scoped, Never on Disk
Long-lived static credentials embedded in pipeline configuration or environment variables are a recurring root cause in CI/CD breaches — once leaked through a misconfigured log, a compromised dependency, or an over-permissioned runner, they remain valid until someone notices and rotates them, which in many breaches takes weeks or months.
- Use OpenID Connect (OIDC) federation between your CI/CD platform and cloud provider so jobs receive short-lived, automatically-expiring credentials instead of long-lived static keys stored as pipeline secrets.
- Where OIDC federation isn’t available, pull secrets just-in-time from a secrets manager (Vault, AWS Secrets Manager) at the moment a job needs them, rather than injecting them as environment variables for the full job duration.
- Mask and scrub secrets from build logs automatically; a shocking share of real leaks come from a secret printed to stdout during a debugging session and never noticed.
- Scope every credential to the minimum permission the specific job needs — a build job that only needs read access to a package registry should never carry deploy credentials.
- Rotate any secret that cannot be made short-lived on a defined schedule, and rotate immediately, unconditionally, after any runner compromise or suspected exposure.
| Credential Type | Recommended Approach | Risk If Static |
|---|---|---|
| Cloud provider access | OIDC federation, short-lived tokens | Leaked static keys remain valid indefinitely |
| Package registry publish | Scoped, short-lived tokens per release | Compromised token can publish malicious package versions |
| Container registry push | Just-in-time credentials tied to job identity | Standing credential enables silent image tampering |
| Production deployment | Just-in-time, approval-gated, fully audited | Direct path to production compromise if leaked |
Signing Commits and Artifacts
Signing establishes a verifiable chain from source code to the artifact that actually gets deployed, making tampering detectable rather than invisible. This has moved from a nice-to-have to close to a baseline requirement as supply chain attacks have matured.
- Require signed commits (GPG or Sigstore/gitsign) on protected branches so every change to the codebase has a verifiable, non-repudiable author.
- Sign build artifacts using Sigstore Cosign or an equivalent tool, and verify signatures at every deployment gate before an artifact is allowed to run.
- Generate SLSA provenance attestations describing exactly how, where, and from what source an artifact was built, so downstream consumers (including your own deployment tooling) can verify build integrity, not just artifact integrity.
- Adopt hermetic builds where practical — fully specifying all inputs with no network access during the build itself — which is the requirement for SLSA Level 4, the highest current supply chain integrity standard.
- Treat SLSA Level 3 as the practical minimum for anything touching critical infrastructure or customer-facing releases as of 2026, per current Linux Foundation guidance, since it requires a non-falsifiable build history and a hardened build platform.
| SLSA Level | Core Requirement | Typical Applicability |
|---|---|---|
| Level 1 | Build process is scripted and provenance exists | Baseline for any automated CI/CD pipeline |
| Level 2 | Provenance is authenticated, build service is hosted | Standard for organizations using managed CI/CD platforms |
| Level 3 | Hardened build platform, non-falsifiable provenance | Minimum for critical infrastructure and regulated releases |
| Level 4 | Hermetic, fully reproducible, two-person reviewed builds | Highest-assurance software, security-critical supply chains |
Defending Against Supply Chain Attacks on the Pipeline Itself
The specific attack pattern worth understanding in depth is dependency and action compromise: an attacker gains control of a widely used third-party GitHub Action, npm package, or plugin referenced by thousands of pipelines, and pushes a malicious update. Because pipelines commonly reference dependencies by mutable tag or version range rather than an immutable content hash, the malicious update propagates automatically into every consuming pipeline’s next run, with no code change required on the victim’s side at all.
- Pin third-party actions and dependencies to an immutable commit SHA or content digest, never to a mutable tag like @v2 or @latest.
- Vendor or mirror critical third-party actions internally after review, rather than pulling directly from a public marketplace on every run.
- Monitor security advisories for the specific actions and plugins your pipelines depend on, the same way you monitor advisories for application dependencies.
- Require review and approval for any change to pipeline configuration files themselves, including changes to which actions or plugins are referenced.
- Run a periodic audit of every third-party action, plugin, and script your pipelines invoke, since dependency sprawl in pipeline configuration tends to go unreviewed far longer than application code dependencies.
Detecting and Responding to a Pipeline Compromise
Prevention controls will eventually fail somewhere, so pipeline security also needs a detection and response plan specific to build infrastructure, distinct from a generic application incident response playbook. Build systems have their own telltale compromise indicators: unexpected outbound network connections from a runner during a build, a build artifact whose checksum doesn’t match its recorded provenance, a workflow file modified outside the normal review process, or a sudden spike in credential requests from a service account that normally runs on a predictable schedule.
Instrument build infrastructure with the same seriousness as production systems — ship runner logs, network egress logs, and pipeline configuration change events to a central SIEM where they can be correlated and alerted on, rather than leaving them isolated inside the CI/CD platform’s own limited retention window. When a compromise is suspected, the response needs to answer a specific question fast: which artifacts were built using the potentially compromised runner, credential, or dependency, and where were those artifacts subsequently deployed? This is exactly the question a mature SBOM and artifact provenance program answers quickly; without it, incident response teams are left manually reconstructing build history from scattered logs under time pressure, often the difference between a contained incident and a prolonged, uncertain cleanup across every downstream environment.
Rehearse this scenario before it happens. A tabletop exercise simulating a compromised third-party action or a leaked deployment credential surfaces gaps in logging, ownership, and rollback tooling far more cheaply than discovering them during a live incident.
Access Control for Pipeline Configuration
The pipeline configuration itself — the YAML files defining build steps, the platform’s admin settings, the list of authorized runners — is as sensitive as production infrastructure, because whoever controls it controls what code actually runs and what credentials it has access to.
- Require pull request review for any change to pipeline configuration files, with the same rigor applied to application code, not a lighter-touch process because “it’s just CI config.”
- Restrict who can modify branch protection rules, required status checks, and merge permissions — a compromised account with admin rights over these settings can disable every other control on this list.
- Separate the identity that can approve a pipeline configuration change from the identity that can trigger a production deployment, so no single compromised account has both capabilities.
- Audit CI/CD platform admin access on the same cadence as production infrastructure access, since it is functionally equivalent in terms of blast radius.
- Log every pipeline configuration change to an immutable audit trail separate from the CI/CD platform itself, so a compromise of the platform doesn’t also erase the evidence of what changed.
Common mistake
Teams frequently apply strict access control and code review to the application repository but treat the CI/CD configuration repository — or the CI/CD platform’s own admin settings — as a lower-stakes afterthought open to a much broader group of engineers. Since pipeline configuration determines what code runs and what credentials it can access, a compromised or careless change there is at least as dangerous as a compromised application commit, and often more so because it can affect every subsequent build silently.
What worked
Pinning every third-party GitHub Action to an immutable commit SHA, then running a quarterly script to check for and review upstream updates before bumping the pin, caught two instances of unexpected behavioral changes in dependency actions before they reached production, changes that would have been silently pulled in automatically under the team’s previous mutable-tag configuration.
Frequently Overlooked CI/CD Security Details
- Self-hosted runner cleanupEphemeral runners that aren’t actually torn down between jobs can leak cached credentials or artifacts from a prior, unrelated build.
- Workflow trigger scopeA workflow triggered on pull_request_target instead of pull_request can expose secrets to fork-submitted code if configured carelessly.
- Artifact retention and cleanupOld build artifacts sitting in a registry with weak access control can be pulled and deployed long after they should have been retired.
- Build cache poisoningShared build caches can be a vector for injecting malicious dependencies if cache keys aren’t scoped tightly per project and branch.
- Notification webhook exposureCI/CD platforms often send build status webhooks to external services; verify those endpoints don’t leak sensitive build metadata.
Glossary
- SLSA (Supply-chain Levels for Software Artifacts)
- A Linux Foundation framework defining progressive levels of build integrity and provenance assurance, from basic scripted builds to fully hermetic, reproducible builds.
- Hermetic build
- A build process with all inputs fully specified in advance and no network access during execution, ensuring the build cannot be influenced by anything outside its declared dependencies.
- OIDC (OpenID Connect) federation
- An authentication method that lets a CI/CD platform exchange a short-lived identity token for temporary cloud credentials, eliminating the need for long-lived static secrets.
- Provenance attestation
- A signed statement describing how, where, and from what source code an artifact was built, allowing downstream systems to verify build integrity before trusting the artifact.
- Ephemeral runner
- A build execution environment that is created fresh for a single job and destroyed immediately afterward, preventing state or credentials from persisting across builds.
Key Takeaways
- Attackers increasingly target the CI/CD build system directly rather than application code, since compromising the pipeline compromises every artifact it produces.
- Isolate build runners with ephemeral, sandboxed environments and trust tiers separating untrusted fork-triggered builds from production deployment jobs.
- Inject secrets just-in-time using OIDC federation or short-lived tokens rather than storing long-lived static credentials in pipeline configuration.
- Sign commits and artifacts and generate SLSA provenance attestations so tampering anywhere in the build chain becomes detectable.
- Pin third-party actions and dependencies to immutable commit hashes, never mutable tags, to prevent silent malicious updates from propagating automatically.
- Treat pipeline configuration access control with the same rigor as production infrastructure access, since it determines what code runs and what credentials it can reach.
- SLSA Level 3 is emerging as the practical minimum standard for critical infrastructure and regulated software releases as of 2026.
FAQs
Why are attackers targeting CI/CD pipelines instead of application code directly?
Compromising the build system lets an attacker inject malicious code into every artifact the pipeline produces, signed with the organization’s own legitimate credentials and distributed to every customer or environment that trusts the release, which is a far larger blast radius than finding a single application vulnerability.
What is SLSA and what level should organizations target?
SLSA (Supply-chain Levels for Software Artifacts) is a Linux Foundation framework defining progressive build integrity assurance levels; as of 2026, Level 3 — requiring a hardened build platform and non-falsifiable provenance — is considered the practical minimum for critical infrastructure and regulated releases, with Level 4 reserved for the highest-assurance use cases.
Why should third-party CI/CD actions be pinned to a commit hash instead of a version tag?
Version tags like @v2 are mutable and can be repointed to new, potentially malicious code by the action’s maintainer or an attacker who compromises their account, while a pinned commit SHA or content digest references an exact, immutable version that cannot change without your explicit review and re-pinning.
What is OIDC federation and why does it reduce CI/CD risk?
OIDC federation lets a CI/CD platform exchange a short-lived identity token for temporary cloud provider credentials at the moment a job runs, eliminating the need to store long-lived static access keys as pipeline secrets, which significantly reduces the impact of any single leaked credential.
How should organizations handle CI/CD jobs triggered by pull requests from external forks?
Fork-triggered pull request builds should run on isolated, network-restricted runners with no access to secrets or production credentials, and workflows using elevated trigger types like pull_request_target should require manual approval before running untrusted contributor code.
What is a hermetic build and why does it matter for supply chain security?
A hermetic build fully specifies all its inputs in advance and disallows network access during execution, ensuring the build output cannot be influenced by anything outside its declared dependency set, which is the core requirement for the highest SLSA assurance level.
How often should CI/CD service account credentials be rotated?
Wherever possible, credentials should be short-lived and automatically expiring through OIDC federation rather than rotated on a schedule at all; for any credential that cannot be made short-lived, rotate on a defined recurring schedule and immediately, unconditionally, after any suspected runner or platform compromise.
What access control matters most for CI/CD pipeline configuration itself?
Pipeline configuration changes should require the same pull request review rigor as application code, admin rights over branch protection and merge settings should be tightly restricted, and the identity that can approve a configuration change should be separate from the identity that can trigger a production deployment.
For related supply chain and build security guidance, see our overview of software supply chain attacks, our practical guide to SBOM implementation and vulnerability response, our breakdown of secrets management best practices, and our dependency confusion and typosquatting defense guide. Readers building a broader DevSecOps program may also find our shift-left security guide and our secure coding practices tutorial useful.
- Cycode, “What Is CI/CD Build Hardening? eBPF, Runtime SBOMs, and SLSA Attestation Explained” – cycode.com
- Palo Alto Networks, “Harden Your CI/CD Pipelines” – paloaltonetworks.com
- OWASP Foundation, “CI/CD Security Cheat Sheet” – cheatsheetseries.owasp.org
- Secure-by-Design Handbook, “CI/CD Pipeline Hardening” – securebydesignhandbook.com
- Linux Foundation, SLSA specification documentation – slsa.dev
- Test Triangle, “CI/CD Pipeline Security Best Practices: The 2026 Strategic Enterprise Checklist” – testtriangle.com
