Notifications
Clear all
Topic starter
21/08/2026 4:56 pm
TL;DR: SLSA v1.2 tightens provenance, build isolation, attestation, and dependency controls to make software supply chain verification more practical in modern CI and CD pipelines, according to Xygeni. The shift matters because build trust now depends on who touched an artifact, how it was produced, and whether that evidence can be verified automatically.
NHIMG editorial — based on content published by Xygeni: SLSA v1.2 and the future of supply chain trust
Questions worth separating out
Q: How should teams implement SLSA controls in CI/CD pipelines?
A: Start by making provenance and attestation verification part of release gating, not an after-the-fact review.
Q: Why do build and release pipelines create identity risk in supply chain security?
A: Because they are governed by non-human identities with broad access to code, registries, and deployment systems.
Q: What do security teams get wrong about provenance in software delivery?
A: They often treat provenance as documentation rather than a continuously verifiable control.
Practitioner guidance
- Map build-system identities end to end Inventory every service account, token, signing key, and automation credential used across CI and CD, then assign a named owner and explicit lifecycle controls to each one.
- Require provenance verification before release Make attestation validation a release gate so artifacts cannot move into promotion or deployment unless provenance, source, and build metadata match policy.
- Reduce trust in shared build infrastructure Separate sensitive build jobs from general-purpose runners, restrict secrets to the narrowest build scope, and avoid letting unrelated pipelines share the same execution boundary.
What's in the full article
Xygeni's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how SLSA v1.2 provenance and attestation validation fit into CI and CD workflows
- Detailed comparison of build isolation and hermetic build expectations across modern pipeline designs
- Implementation guidance for checking dependency trust, artifact integrity, and build-script monitoring together
- Operational examples showing how build security checks can be mapped to release and audit requirements
👉 Read Xygeni's guide to SLSA v1.2 provenance and build trust →
SLSA v1.2 and provenance controls: are your pipelines ready?
Explore further
21/08/2026 5:12 pm
SLSA v1.2 turns provenance from documentation into a control requirement: the value is no longer just that teams can describe a build, but that they can prove it with machine-verifiable evidence. That changes the governance conversation for CI and CD, because artifact trust becomes auditable rather than assumed. Practitioners should treat provenance as a release gate, not a nice-to-have artifact.
A question worth separating out:
Q: Who should own supply chain trust controls across build systems?
A: Ownership should sit jointly with application security, platform engineering, and the teams managing automation identities. The key is clear accountability for runners, secrets, signing keys, and dependency sources so no part of the pipeline sits outside lifecycle control.
👉 Read our full editorial: SLSA v1.2 raises the bar for software supply chain trust
