Each stage of a pipeline consumes what an earlier stage, or a third party, produced. Without signatures or provenance checked against an expected identity, a tampered build output, script or image looks exactly like a good one.
- Sign artifacts when they are produced and verify the signature, and the signer's identity, before each stage consumes them.
- Generate and check build provenance, for example in the SLSA format, and sign commits where your platform can enforce it.
- Verify the hash or signature of every third-party script or tool a pipeline downloads before running it.
- Detect configuration drift: resources that were not deployed from the reviewed, signed definition.
Guides on this site
Verify artifact signatures against an explicit trust policy
Require the expected artifact, signer and release context before allowing a signed package or image to proceed.
Read SLSA provenance and verify the claim you need
Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls.
Protect the path from pull request to release
Separate untrusted contribution checks from privileged release work and verify the identity of the artifact that is actually deployed.
Protect the source repository: rulesets, reviews and signed commits
Configure the controls every repository that ships software needs: protected branches and tags, required review with CODEOWNERS, signed commits, secret push protection and account security, mapped to the SLSA Source track, the OpenSSF OSPS Baseline and Scorecard.
Case study: the Codecov Bash Uploader compromise (2021)
How a credential leaked through Codecov's Docker image process let an attacker change the Bash Uploader that many CI pipelines downloaded and ran, which sent their environment variables, and the secrets in them, to the attacker for two months in 2021.
Protect package publication and the update channel
Constrain release identities, verify what consumers receive, and prepare for publisher or update-key compromise.
Practice
- Signed artifact provenance lab: Reject a release from the wrong producer · Browser lab
- Build and verify a signed software release · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.