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
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic - Build Pipeline Security
Build Pipeline Security is the subject of this course. 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.
The useful unit of work is a closed loop: clarify the goal and boundaries, gather the inputs the practice requires, make the decision or change, record evidence, and return with owners for the next cycle. Skipping any link leaves teams busy without durable results.
Tooling supports the loop; it does not replace it. Choose tools after the boundary and evidence model are clear. Comparing products without that model produces feature matrices that do not change how the work runs.
Common failure modes include undefined ownership, metrics that count activity instead of outcomes, and irreversible steps taken without a review path. Treat those as design defects in the practice, not as individual heroics to compensate later.
Operators should be able to explain which signals would change a decision this week. If no signal can change the plan, the practice has become ritual. Keep the feedback path short enough that evidence still influences the next cycle.
Name the owners for each stage of the loop before the work scales. Unowned stages become permanent exceptions. Record decisions with enough context that a future operator can tell why a tradeoff was accepted. Prefer fewer, sharper metrics that change behavior over broad dashboards that only describe activity after the fact.
Read the Intro for the core model. Use the Cheatsheet when you need the operating map. Updates tracks official guidance when this course configures an update source; otherwise the practice is settled without a live feed.
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
