Container Image Provenance<\/a> shows how these ideas apply to OCI images and signed attestations.<\/p>\nBuild L0 means no SLSA guarantees<\/h3>\n Build L0 has no requirements. It represents artifacts produced without the provenance and build-platform guarantees defined by SLSA.<\/p>\n
This can be acceptable for local experiments or test outputs that never become trusted releases.<\/p>\n
Production policy should be explicit if L0 artifacts are allowed, because \u201cwe built it ourselves\u201d is not equivalent to verifiable provenance.<\/p>\n
Build L1 requires provenance to exist<\/h3>\n At Build L1, the build process generates provenance that identifies the output artifact and describes how it was produced.<\/p>\n
The producer follows a consistent build process and distributes provenance to consumers.<\/p>\n
L1 is valuable for traceability and release mistakes, but provenance can still be unsigned or forgeable, so it is not a strong anti-tampering guarantee.<\/p>\n
Build L2 adds a hosted builder and authentic provenance<\/h3>\n Build L2 requires the build to run on a hosted build platform and the platform to generate authentic provenance that consumers can validate.<\/p>\n
This helps prevent tampering after the build because the provenance can be tied cryptographically to the builder.<\/p>\n
The tenant-defined build steps should not be the component that can simply invent the signed provenance without platform control.<\/p>\n
Build L3 hardens provenance and build isolation<\/h3>\n Build L3 adds stronger guarantees against tampering during the build. SLSA requires provenance to be strongly resistant to forgery, signing material to remain inaccessible to user-defined build steps, and the build environment to be isolated.<\/p>\n
The build platform should prevent concurrent or subsequent builds from influencing one another and should prevent cache poisoning across builds.<\/p>\n
L3 is intended for most software releases that need strong supply-chain trust.<\/p>\n
Source L1 starts with version control<\/h3>\n SLSA 1.2 reintroduces a Source track. Source L1 requires the organization to use an appropriate source control system capable of producing discrete source revisions.<\/p>\n
This creates a stable object that downstream builds can refer to.<\/p>\n
A source archive copied around manually without durable revision identity is a weak basis for trustworthy provenance.<\/p>\n
Source L2 preserves history and produces source provenance<\/h3>\n Source L2 adds preserved change history and source provenance so consumers can understand where the revision came from and how the source-control system recorded it.<\/p>\n
This helps distinguish one reviewed repository history from an arbitrary code snapshot.<\/p>\n
Organizations should keep the source-control configuration aligned with the claimed level.<\/p>\n
Source L3 adds organization-enforced technical controls<\/h3>\n At Source L3, the organization configures technical controls in the source-control system to enforce aspects of the intended development process.<\/p>\n
The exact controls are defined through the Source-track requirements rather than one generic branch policy.<\/p>\n
The important point is that control enforcement moves from social convention toward verifiable platform behavior.<\/p>\n
Source L4 includes code review requirements<\/h3>\n Source L4 adds required code review, strengthening resistance to unauthorized or unilateral source changes.<\/p>\n
This is a separate track from Build L3. A project can have strong build provenance but weak source controls, or strong source review with a weak build environment.<\/p>\n
Security teams should therefore report track and level explicitly rather than saying \u201cthe project is SLSA 3\u201d without context.<\/p>\n
Provenance must be verified against expectations<\/h3>\n SLSA guidance emphasizes that provenance only creates security value when a consumer checks it.<\/p>\n
Verification should confirm trusted builder identity, signature authenticity, canonical source repository, build type, external parameters, and other producer-defined expectations.<\/p>\n
An artifact with excellent provenance that nobody validates at registry admission or deployment is still vulnerable to substitution.<\/p>\n
Attestation format and level are related but not identical<\/h3>\n SLSA recommends provenance formats within the in-toto attestation model, but simply creating a JSON attestation does not mean the build meets L2 or L3.<\/p>\n
The level depends on how provenance is generated, authenticated, isolated, and verified\u2014not merely on the schema used.<\/p>\n
Sigstore Cosign can carry SLSA provenance attestations, but the organization still needs a trustworthy builder and verification policy.<\/p>\n
SLSA adoption should be incremental and policy-driven<\/h3>\n Teams can begin by generating provenance, then move builds onto approved hosted platforms, strengthen authentication and isolation, and add source-track controls.<\/p>\n
Different artifact classes can have different required levels based on impact.<\/p>\n
The mature program defines which build\/source levels are required for production releases, verifies those claims automatically, and treats exceptions as visible risk rather than silently lowering the bar.<\/p>\n
Organizations should avoid using a single badge to summarize all supply-chain trust. Build L3 says strong things about build isolation and provenance integrity, but it does not automatically prove Source L4 code review, dependency security, vulnerability status, or operational security of the deployed service.<\/p>\n
Source and Build track adoption can proceed independently. A team can first standardize hosted builds and provenance while later strengthening source-control review, or improve source governance before moving legacy builds to an L3-capable platform. Reporting both tracks makes progress visible without waiting for perfection.<\/p>\n
Builder assessment is a platform responsibility. Individual application teams should not each attempt to prove the same hosted CI service meets Build L3. A central platform or security team can assess approved builders and publish which levels they support under which configurations.<\/p>\n
Verification should happen at a choke point that attackers cannot bypass easily: package registry publication, artifact promotion, Kubernetes admission, deployment controller, or host policy. Verification performed only by a developer command on their workstation is too easy to skip under pressure.<\/p>\n
Exceptions should be package-specific and visible. Legacy software may temporarily remain at Build L1 while critical releases require L3. The policy should record why the lower level is accepted and what migration path exists rather than lowering the organization-wide requirement silently.<\/p>\n
SLSA can also support procurement and third-party software review. Vendors can provide provenance or verification summaries that help consumers understand source and build guarantees without exposing all private build details. The organization still needs to decide what evidence it requires for the software\u2019s risk level.<\/p>\n
Build L3 isolation should be understood precisely. It does not require hermetic builds with no network access, but it requires that builds cannot influence one another unexpectedly, cannot access the provenance signing secret, and cannot poison shared state in ways that change another build\u2019s output outside declared parameters.<\/p>\n
The Source track adds controls that were intentionally separated from the Build track. This is useful because organizations can assess source-control security and build-system security independently rather than compressing different guarantees into one number.<\/p>\n
Verification Summary Attestations can be useful when consumers need a signed statement that verification occurred without receiving every detail of private provenance. This can help closed-source suppliers communicate verified properties while limiting unnecessary disclosure.<\/p>\n
Provenance retention should match artifact retention. If a binary is supported for five years, the organization should preserve the evidence needed to verify how it was built for the same period or according to applicable support\/audit requirements.<\/p>\n
SLSA policy should integrate with SBOM and vulnerability management rather than replace them. Provenance answers origin and build-process questions; SBOM answers dependency composition; vulnerability tools answer known-risk questions. Supply-chain assurance is strongest when those evidence types reinforce one another.<\/p>\n
Source L4 code review should be interpreted as a source-control guarantee, not proof that reviewers understood every security implication. Review quality still depends on reviewer expertise, test coverage, dependency management, and secure development practices outside the SLSA level.<\/p>\n
Likewise, Build L3 does not guarantee that the producer chose safe build parameters or dependencies. It strengthens confidence that the artifact was built as declared on an isolated trusted platform. Policy still needs to define what an acceptable build is.<\/p>\n
Organizations should publish expected levels by artifact class\u2014production services, internal tools, firmware, open-source releases, third-party packages\u2014so teams know the target before they design CI\/CD.<\/p>\n
SLSA adoption becomes effective when level claims can be verified automatically and exceptions are rare, documented, and time-bound. The specification provides the assurance language; the organization supplies the trust policy around it.<\/p>\n
Build-platform changes should trigger reassessment of the claimed level. Moving from one CI provider, runner type, or provenance-signing configuration to another can alter isolation and authenticity guarantees even if application source remains unchanged.<\/p>\n
Verification policy should preserve failure evidence. When an artifact is rejected because provenance does not match expectations, store the reason and artifact digest so supply-chain incidents can be investigated rather than hidden behind a generic deployment failure.<\/p>\n
Keep level claims tied to evidence, verified automatically, and rechecked whenever source or build controls change.<\/p>\n
A practical next step is to tie each targeted SLSA improvement to the build system that can actually enforce it. Provenance, isolated builds, protected source, and artifact verification provide more value when teams can test the control continuously instead of documenting intent.<\/p>\n","protected":false},"excerpt":{"rendered":"
SLSA\u2014Supply-chain Levels for Software Artifacts\u2014is a specification for improving software supply-chain security through verifiable provenance and stronger controls around source and build systems. The current approved specification is version 1.2. A key current-state detail is that SLSA no longer has one universal \u201clevel\u201d for everything: it has separate tracks, including a Build track and a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19835","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t