How to use this reference
Map documented build controls and provenance expectations to an approved architecture review; distinguish attestation presence from trusted verification.
Before reading
- Basic familiarity with version control and continuous integration
- Understanding of software artifacts, hashes, and digital-signature concepts
Context and limits
- Build L1 provenance alone does not provide tamper protection.
- The specification version is 1.2, while the build-provenance predicate identifier remains https://slsa.dev/provenance/v1; the page explains this major-version convention.
- A recorded attestation is useful only within an explicit trust and verification model.
Related visual models
Build evidence must match the artifact and trusted builder
Editorial conceptual model combining the Angular case with SLSA build guidance. The case supports separating automation trust and shared build state; the consumer verification gate is a general design synthesis, not a…
Reviewed 2026-10-03Read
Sources and provenance
- Official stable entry point redirects to v1.2 SLSA Community · reviewed 2026-10-02
- Version 1.2 and Approved status SLSA Community · reviewed 2026-10-02
- SLSA Community release announcement dated 24 November 2025 SLSA Community · reviewed 2026-10-02
- Build-level distinctions and provenance limitations SLSA Community · reviewed 2026-10-02
- Build provenance model and predicate-version convention SLSA Community · reviewed 2026-10-02
Record reviewed 2026-10-02. Snapshot d5550c789111. Open the complete JSON contract.