What Is a CI/CD Pipeline? Securing the Build Path

In December 2020 the malicious code that shipped to roughly 18,000 SolarWinds Orion customers was not slipped past code review or signed with a stolen key. It was compiled in. Attackers planted an implant on the build server that injected the SUNBURST backdoor during compilation, so the finished artifact was signed with SolarWinds' own legitimate certificate and pushed through the normal update channel. Every customer who ran the update was trusting a build pipeline that had been quietly owned. The code on the developers' workstations was clean. The pipeline that turned it into a product was not.

That is the thing about a CI/CD pipeline. It is the most trusted machine in the building. It holds the credentials to production, it signs the releases, and whatever it produces gets deployed without a second look because the whole point of automation is that nobody looks. Compromise it and you do not breach one system, you breach everyone who installs the output. This guide covers what a CI/CD pipeline actually is, the stages a change moves through, why those properties make it a high-value target, the specific risks that recur in real incidents, and the controls that close them. It is written for the people who have to detect and investigate when the pipeline is the entry point: SOC analysts, threat hunters, and DFIR responders.

What is a CI/CD pipeline?

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It is the automated path that takes a code change from a developer's commit to running in production, with the build, the tests, and the release steps handled by machines instead of by hand.

Continuous Integration is the first half. Developers merge their changes into a shared repository frequently, often many times a day, and every merge triggers an automated build and an automated test run. The goal is to catch integration problems within minutes of the commit that caused them, rather than discovering during a quarterly release that two teams' code does not work together. CI is the discipline of integrating small and often, backed by automation that proves each integration still builds and passes.

Continuous Delivery is the second half. Once a change is built and tested, it is automatically packaged into a release artifact and made ready to deploy, so that shipping is a routine push of a button rather than a manual ceremony. Continuous Deployment goes one step further and removes the button: every change that passes the pipeline goes straight to production with no human gate. The distinction matters in practice. Delivery keeps a human approval before production; deployment does not. Most organizations run delivery and reserve full deployment for services where they trust the test suite completely.

The pipeline is the automation that connects all of this. It is defined as code, usually a YAML or Groovy file checked into the same repository as the application, and executed by a CI/CD platform. The common ones are Jenkins, GitLab CI/CD, GitHub Actions, and CircleCI, with tools like Argo CD handling the deployment end for Kubernetes. All are active products. They differ in hosting model and syntax, but they share the same shape: a trigger fires on a commit, and a sequence of jobs runs on build agents until the change is live.

The stages of a CI/CD pipeline

A pipeline is a sequence of stages, each gating the next. The exact stages vary by team, but a representative pipeline moves through five: source, build, test, release, and deploy. Naming them matters for defenders, because each stage has its own trust boundary and its own way to be abused.

Source. A developer pushes a commit, or opens a merge request, against the repository. This is the trigger. The pipeline checks out the code, and from this point on it is acting on whatever the source control system handed it: the application code, the pipeline definition itself, and every dependency the build will pull in.

Build. The pipeline compiles the code and resolves its dependencies, pulling in third-party packages from registries like npm, PyPI, or a container registry. The output is an artifact: a binary, a container image, a package. This is the stage that turns text into something executable, and it is the stage SolarWinds taught everyone to worry about, because anything that touches the build can alter the artifact without touching the source.

Test. Automated tests run against the build: unit tests, integration tests, and increasingly security scans. A failing test stops the pipeline. This is also where security gates belong, the static analysis, dependency scanning, and configuration checks that decide whether a change is allowed to proceed.

Release. The validated artifact is versioned, signed if the organization signs its artifacts, and published to an artifact repository. This is the hand-off point between "we built it" and "we are ready to ship it," and the integrity of the artifact at this moment is what every downstream system will trust.

Deploy. The release is pushed to an environment, staging first and then production, often into cloud infrastructure or a Kubernetes cluster. This is the stage that holds production credentials, and it is the reason the pipeline is a path straight into the running environment.

Why the pipeline is a high-value target

The pipeline concentrates three things an attacker wants, in one place, with automation that suppresses the human checks that might otherwise catch an intrusion.

First, it holds credentials. To deploy, the pipeline needs to authenticate to production: cloud access keys, registry tokens, Kubernetes service accounts, database passwords. To pull dependencies and push artifacts it needs registry credentials. These secrets are configured into the pipeline so jobs can use them unattended, which means whoever controls a pipeline job controls those secrets. A single over-scoped deploy key can be the difference between a contained incident and a full cloud compromise.

Second, it has production access by design. The pipeline's job is to change the running environment. A defender spends enormous effort keeping standing access out of production; the pipeline is the one system granted exactly that access, continuously, so that deployment can happen without a human in the loop. An attacker who reaches the deploy stage does not need to find a way into production. The pipeline already has one.

Third, it is a supply-chain pivot. Whatever the pipeline produces is trusted and distributed downstream, to other internal systems, to customers, to anyone who installs the artifact. This is the property that turns a single pipeline compromise into a software supply chain attack: the attacker does not attack the targets directly, they poison the build that the targets trust, and the targets install the malicious version themselves. SolarWinds reached roughly 18,000 organizations from one build server. That leverage is why the pipeline is worth far more to an attacker than the application it builds.

These three combine into a quiet failure mode. Pipeline activity looks like pipeline activity. A job that reads a secret, builds an artifact, and deploys to production is doing exactly what it is supposed to do, so a malicious job that reads the same secret and deploys a backdoored artifact does not stand out. The automation that makes CI/CD valuable is the same automation that hides the attack.

The risks that recur in real incidents

The same handful of weaknesses show up across pipeline compromises. They map cleanly onto the OWASP Top 10 CI/CD Security Risks, the OWASP project that catalogs CI/CD-specific failure modes. Six recur often enough to plan around.

Poisoned dependencies. The build pulls third-party packages, and if one of those is malicious, the poison is baked into the artifact. This is dependency chain abuse: typosquatted package names, compromised maintainer accounts, or a legitimate package that pushes a malicious update. The pipeline resolves dependencies automatically, so a poisoned package becomes part of the build with no human ever choosing to run it.

Secrets in the pipeline or its config. Pipeline definitions, environment variables, and build logs are full of credentials, and they leak. A token hardcoded in a YAML file, a secret printed to a build log, an environment variable readable by any job in the pipeline. The Codecov incident in 2021 is the textbook case: attackers altered Codecov's Bash Uploader script after gaining access through a flaw in Codecov's Docker image creation process, and the modified script exfiltrated environment variables, including credentials and secrets, from the CI environments of every customer that ran it. The pipeline's secrets became the attacker's secrets.

Compromised build agents. The runners that execute pipeline jobs are full execution environments with access to source, secrets, and the network. A compromised or attacker-controlled runner can read everything a job touches and tamper with the output. This is exactly the SolarWinds mechanism: the build server itself was implanted, so the artifact was corrupted during compilation while the source stayed clean.

Insecure pipeline permissions. Pipelines that run with far more privilege than they need. A deploy job with full cloud administrator rights instead of permission to update one service. A pipeline identity that can rewrite its own configuration. Over-broad permissions mean that compromising any single job hands the attacker everything the pipeline can reach, which in a CI/CD context is usually production.

Malicious commits and pipeline definition changes. The pipeline is defined as code, so an attacker who can commit to the repository can change what the pipeline does. A modified workflow file that adds a step to exfiltrate secrets, a pull request from a fork that triggers a build with attacker-controlled code, a commit that disables the security scan. If the pipeline trusts the repository and the repository is not protected, the pipeline executes whatever the attacker commits.

Artifact tampering. Modifying the build output between build and deploy, so that what gets deployed is not what was built and tested. Without integrity verification on the artifact, there is nothing to detect that the thing being deployed was swapped after it passed the tests. This is the gap that artifact signing and provenance exist to close.

Pipeline stages, risks, and controls

The risks are not abstract. Each one lands at a specific stage and each has a specific control. This table maps the spine of pipeline defense: where the exposure is, and what closes it.

The pattern across the table is that no single control secures the pipeline. Branch protection does nothing about a poisoned dependency; artifact signing does nothing about a leaked secret. Pipeline security is the sum of a control at every stage, which is also why it is hard: a gap at any one stage is a path through the whole pipeline.

Securing the CI/CD pipeline

The controls that hold up are the same least-privilege and integrity principles that govern the rest of security, applied to a system most teams treat as plumbing. Six matter most.

Least-privilege pipeline identities. Scope every pipeline credential to the smallest action it needs. A deploy job that updates one service gets permission to update that one service, not administrator over the account. Prefer short-lived, automatically issued credentials, OpenID Connect federation from the CI platform to the cloud provider, over long-lived static keys stored in the pipeline. This is the control that limits blast radius: when a job is compromised, the attacker inherits only what that job could do.

Secrets management. Secrets never live in the repository, the pipeline definition, or a build log. They live in a secrets manager and are injected into the job at runtime, scoped to that job, and rotated. Scan the repository and the pipeline config for committed secrets as a gate, because the most common leak is the one someone pasted in to make a build work and forgot. Pipeline hygiene here overlaps directly with code security: the secret in the source is both a code problem and a pipeline problem.

Signed commits and signed artifacts. Require commit signing so the source has a verifiable author, and sign the build artifact so anything downstream can verify it came from your pipeline and was not swapped. Sigstore's cosign is the common open tool for signing artifacts and container images. Signing is what turns "trust the artifact" into "verify the artifact," and it is the direct answer to artifact tampering.

Provenance with SLSA. SLSA (Supply-chain Levels for Software Artifacts) is a supply-chain integrity framework hosted under the OpenSSF. It defines a build track with three levels, L1 through L3, that progressively require verifiable provenance: a signed record of how an artifact was built, from what source, on what builder. The current specification is SLSA v1.2. Provenance is the artifact's birth certificate, and it is what would have made the SolarWinds substitution detectable: a verifier could have seen that the shipped binary did not match the recorded build.

Scanning in the pipeline. Run security checks as blocking pipeline stages, not as a separate audit nobody reads. Static application security testing (SAST) analyzes the source for vulnerabilities. Software composition analysis (SCA) flags known-vulnerable and malicious dependencies. Infrastructure-as-code (IaC) scanning checks the deployment configuration before it provisions anything. Wired into the test stage, these gates catch the problem at the commit that introduced it. This is the heart of code-to-cloud security: tracing and securing a change from the commit through the build to the running cloud resource.

Isolated runners and branch protection. Run each job on an ephemeral, isolated runner that is destroyed after the job, so a compromised build cannot persist or contaminate the next one. Protect the main branch: require review on every change, forbid direct pushes, and require status checks to pass before merge, so an attacker cannot simply commit a malicious pipeline change and have it execute. These two close the build-agent and malicious-commit risks at their source.

Shift-left and DevSecOps

The thread running through every one of those controls is timing. Each one moves a security decision earlier, into the pipeline, instead of leaving it for a scan after deployment. That is what "shift-left" names: pushing security from a late, separate gate to the point in development where a problem is cheapest to fix and easiest to attribute to the change that caused it. A vulnerability caught by SAST on the commit that introduced it costs a code review comment. The same vulnerability found in production costs an incident.

DevSecOps is the operating model that makes shift-left real. It puts security controls into the same automated pipeline that already runs build and test, owned by the same team, rather than bolting security on as a gate a separate team operates after the fact. The pipeline becomes the enforcement point: security policy is code that runs on every commit, and a change that fails a security gate does not ship, the same way a change that fails a unit test does not ship.

For a defender, this changes the evidence available. A pipeline with scanning, signing, and provenance built in produces a record of every build: what was scanned, what was signed, what provenance was generated. That record is exactly what an investigation needs when the question is whether a given artifact is trustworthy. The same automation that enforces the controls is the automation that logs them, which makes a well-instrumented pipeline both harder to attack and easier to investigate when someone tries.

The bottom line

A CI/CD pipeline is the automated path from a developer's commit to running production: Continuous Integration builds and tests every change, Continuous Delivery or Deployment ships the validated result. It moves through source, build, test, release, and deploy, and each stage is a trust boundary with its own way to be abused. The pipeline is a high-value target because it concentrates credentials, production access, and downstream trust in one automated system that runs without a human watching.

The recurring risks are concrete: poisoned dependencies, leaked secrets, compromised build agents, over-privileged identities, malicious commits, and artifact tampering. SolarWinds and Codecov are not anomalies, they are those risks realized. The controls that answer them are least-privilege pipeline identities, real secrets management, signed commits and artifacts, SLSA provenance, scanning wired in as blocking gates, and isolated runners behind a protected branch. Shift them left so the pipeline enforces them on every commit, and the same automation that makes CI/CD a target becomes the record that makes an attack on it detectable.