---
{
  "title": "CI/CD pipeline security",
  "summary": "CI/CD security protects the systems that transform source into deployed software.",
  "topic": "delivery",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    5
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: CI CD Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

CI/CD security protects the systems that transform source into deployed software. Pipelines often hold credentials and authority that make them attractive targets. Untrusted contributions, build scripts, third-party actions, artifacts, and deployment approvals create distinct trust boundaries within the process.

## A practical example

A repository accepts outside contributions, but their test jobs cannot access production deployment secrets. A later trusted release job verifies its input artifact and uses narrowly scoped credentials, rather than inheriting unrestricted permissions throughout the workflow.

## What to check

Map source trust, runner isolation, credential access, artifact handoffs, and deployment authority. Minimize permissions and verify which triggers execute code supplied by less-trusted actors.

## A common pitfall

Treating a pipeline as disposable infrastructure can overlook its ability to modify production. A build that executes untrusted code while holding secrets creates a direct exposure path.

## Think it through

Should a contribution test job receive production credentials because it only runs tests?

**Answer:** No. Tests execute code and can expose any credentials or authority available to that job.


## Every handoff is a trust decision

A pipeline transforms inputs through several stages: source selection, dependency retrieval, build, test, packaging, and deployment. Each stage can introduce or modify material that a later stage trusts. Map those handoffs and the identities allowed to change them. A protected source branch does not help if an unrelated artifact can be swapped into the release path afterward.

Build systems often have access that exceeds an ordinary developer account. Limit credentials to the job and environment that need them, and prefer short-lived authority where supported. Review who can change workflow definitions as well as application code. Modifying the instructions that produce a release can be as consequential as modifying the product itself.

## A fictional artifact mismatch

A team tests one application package but later deploys a package rebuilt from a slightly different dependency resolution. The release may no longer be the artifact that passed review. Binding deployment to the intended artifact identity helps preserve the connection between evidence and release. The exact verification mechanism should fit the build and distribution system.

This does not eliminate the need to trust and monitor the builder. A compromised authorized build environment can produce misleading outputs or evidence. Pipeline security therefore combines boundaries, reproducibility where feasible, review, credential control, and the ability to investigate what actually ran.

## Trace one release

For a training application, list the source revision, resolved dependencies, build environment, resulting artifact, and deployment target. Explain how you would establish that the deployed artifact is the one tested. Then identify who can alter each step. This exercise exposes authority and substitution risks that a simple statement such as our pipeline passed cannot answer.

## Related concepts

- [[software-supply-chain]]
- [[secrets-management]]
- [[trust-boundaries]]