Build Pipeline Security
Build pipeline security protects the CI/CD systems that compile, test, and deploy software. It addresses threats like compromised build agents, injected dependencies, leaked secrets, and tampered artifacts that can turn the delivery pipeline itself into an attack vector.
itSoftware supply chain security | OpenSkills.info
Intro
Build Pipeline Security
A build pipeline turns a source revision into something people can run. It may compile code, fetch dependencies, run tests, package files, publish artifacts, and deploy a release. Each step carries trust from one system to the next.
That trust makes the pipeline a security boundary. A compromised build can produce malicious software from clean source. A stolen deployment credential can turn a test job into production access. A changed dependency or reusable pipeline component can alter many releases at once.
Build pipeline security protects the path from approved source to released artifact. You control who and what may enter that path. You limit what each job can do. You preserve evidence about what happened. You verify that evidence before accepting the output.
The pipeline as a chain of trust
A typical path looks like this:
source revision
↓
pipeline definition
↓
build platform and runner
↓
dependencies, tools, and configuration
↓
artifact and provenance
↓
registry, promotion, and deployment
Every arrow crosses a trust boundary. The pipeline must authenticate its input, constrain its execution, and identify its output. A green status icon only says that configured jobs reported success. It does not prove that the configuration was authorized or that the runner was trustworthy.
Treat the pipeline as production infrastructure. It often holds repository tokens, package credentials, signing authority, cloud identities, and deployment access. Its configuration deserves review, change control, monitoring, and recovery planning.
Begin with a threat model
List the assets an attacker would want:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- Secure development environments and protected software components
- Least-privilege access to development resources
- Verification of third-party components
- Secure configuration of compilation, build, and packaging processes
- Collection and protection of release integrity information and provenance
- Quiz answers about release identity, scanning scope, least privilege, and dependency updates
- https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3441780/nsa-and-cisa-best-practices-to-secure-cloud-continuous-integrationcontinuous-de/
Supports
- CI/CD environments as attractive targets with access to the software delivery lifecycle
- Malicious code introduction, code theft, and denial of service as pipeline risks
- CI/CD hardening as part of secure DevOps and cloud deployment
- Link rationale and introductory quiz answer
- https://media.defense.gov/2023/Jun/28/2003249466/-1/-1/0/CSI_DEFENDING_CI_CD_ENVIRONMENTS.PDF
Supports
- Insecure code, poisoned pipeline execution, insufficient access controls, dependency abuse, third-party compromise, and exposed secrets
- Authentication, authorization, least privilege, network segmentation, and secret protection
- Secure use of development, build, and deployment environments
- Logging, monitoring, patching, dependency management, and incident preparation
- Quiz answers about trust-zone separation, runner state, and scoped credentials
- https://slsa.dev/spec/v1.2/about
Supports
- SLSA as an incremental framework for software supply chain security
- Relationship between trustworthy production, provenance, and artifact verification
- Foundational link rationale
- https://slsa.dev/spec/v1.2/tracks
Supports
- Build Track focus on provenance trustworthiness and completeness
- Provenance description of builder, process, and inputs
- Verification of actual provenance against expected provenance
- Quiz answer about unused provenance
- https://slsa.dev/spec/v1.2/build-track-basics
Supports
- Build Levels 0 through 3 and their security focus
- Level 1 provenance existence
- Level 2 hosted, platform-generated authenticated provenance and consumer validation
- Level 3 cross-run isolation and protection of provenance-signing secrets
- Limits of level claims and quiz answers about build assurance
- https://slsa.dev/spec/v1.2/provenance
Supports
- Provenance as verifiable information about where, when, and how an artifact was produced
- Subject digest binding
- Builder, build process, external parameters, and resolved dependencies as provenance concepts
- Quiz answers about artifact identity and provenance
- https://slsa.dev/spec/v1.2/verifying-artifacts
Supports
- Verification of provenance authenticity and artifact subject
- Comparison with package, builder, source, and build-process expectations
- Separation of provenance generation from enforcement
- Quiz answers about promotion, scan scope, and verification policy
- https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
Supports
- Risk of running pull-request code with write permissions or repository secrets
- Separation of untrusted pull-request processing from privileged follow-up work
- GitHub-specific example for the general untrusted-code boundary
- https://openssf.org/blog/2025/06/11/maintainers-guide-securing-ci-cd-pipelines-after-the-tj-actions-and-reviewdog-supply-chain-attacks/
Supports
- CI/CD components as a supply chain attack path
- Immutable pinning, reduced token permissions, build isolation, and monitoring as layered defenses
- Need to review and update pinned components
- Incident-driven final link rationale and quiz answer
