On November 12, 2025, the SLSA steering committee announced approval of SLSA v1.2 as the latest version of the Supply-chain Levels for Software Artifacts framework. The release closes a gap that has existed since the original SLSA v0.1 draft of 2021: a complete, normative Source Track that sits alongside the now-stable Build Track. Where v1.1 (approved April 2025) was largely a clarity refresh that added verifier metadata to the Verification Summary Attestation (VSA), v1.2 is a structural release. It promotes the Source Track from "experimental" to "approved," reorders the source levels around history and continuous enforcement, and improves the verification flow for source-level VSAs so that downstream consumers can finally treat source guarantees as first-class attestation evidence.
What is the Source Track and why does it matter now?
The Source Track covers threats from authoring, reviewing, and management of source code — everything that happens before a tagged commit reaches a SLSA-compliant builder. SLSA v1.0 deliberately deferred this work because the community wanted to ship the Build Track quickly in response to SolarWinds and the 2022 supply-chain wave. The result was a three-year period where producers could claim Build L3 on a tarball whose git history may have been silently rewritten or whose tag may have been pushed by an unreviewed maintainer. v1.2 fixes that asymmetry. The new Source Track explicitly enumerates threats covered by source controls — unauthorized commits, force-pushes that erase evidence, single-maintainer takeovers — and ties each threat to a level requirement that a verifier can mechanically check against a source VSA.
How are the Source levels organized?
Source L1 (existence and identity), L2 (history and provenance), and L3 (continuous enforcement of technical controls) replace the older sketch that conflated review policy with cryptographic verification. Source L2 now requires the Source Control Platform (SCP) — or an independent tool such as gittuf — to issue a VSA that attests the revision's history is preserved and the platform's identity bindings can be inspected. Source L3 adds the requirement that branch protection, code review, and any other declared controls were technically enforced for every commit in the revision's reachability set, not just declared as policy. The level table now reads:
| Level | Track | Requirement summary | | --- | --- | --- | | Source L1 | Source | Revision has a stable, immutable identifier (commit hash) and an SCP-issued source identifier | | Source L2 | Source | Full history preserved; VSA covers history retention and platform identity | | Source L3 | Source | Declared technical controls (branch protection, signed reviews, status checks) continuously enforced and attested | | Build L1 | Build | Provenance exists | | Build L2 | Build | Provenance signed by hosted builder | | Build L3 | Build | Hardened, isolated builder; provenance non-forgeable |
The Source levels deliberately mirror the Build levels in number but not in semantic — a Source L3 producer is not "equivalent" to a Build L3 producer, and consumers must reason about the two tracks independently.
What does a Source VSA actually look like?
The Source VSA reuses the existing https://slsa.dev/verification_summary/v1 predicate type but adds a sourceLevels field alongside buildLevels. A minimum L2 VSA from a GitHub-hosted source verifier looks like:
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [{
"name": "git+https://github.com/example/repo",
"digest": { "gitCommit": "a7f3...c12" }
}],
"predicateType": "https://slsa.dev/verification_summary/v1",
"predicate": {
"verifier": { "id": "https://verifier.example.com" },
"timeVerified": "2025-11-15T09:42:00Z",
"resourceUri": "git+https://github.com/example/repo@refs/tags/v3.4.0",
"policy": { "uri": "https://policy.example.com/source-l2" },
"verificationResult": "PASSED",
"verifiedLevels": ["SLSA_SOURCE_LEVEL_2"]
}
}
The verifiedLevels array can carry both SLSA_SOURCE_LEVEL_2 and SLSA_BUILD_LEVEL_3 when one verifier attests to both tracks — for instance, a Sigstore-style policy verifier that consumes both source and build evidence.
What backward-compatibility guarantees does v1.2 give?
The spec is explicit that v1.2 is backwards compatible with v1.1: any VSA emitted under v1.1 remains valid, and any Build Track claim made at v1.0 or v1.1 carries forward unchanged. The Source Track changes are additive — there is no "Source L1" requirement retroactively imposed on projects that previously claimed Build L2 only. Producers who were claiming the old "Source L4" from the v0.1 draft must remap; the v1.2 announcement post explicitly notes that the old Source L4 corresponded most closely to the new L3 but with stricter two-party review, which is now a separate policy requirement rather than a level.
Which builders and SCPs already support v1.2?
GitHub's actions/attest-build-provenance action emits VSAs that include the new sourceLevels field when the workflow is run against a branch with required reviews configured, treating the GitHub branch protection state as the technical control evidence. GitLab Build Cloud emits equivalent attestations under its slsa-source-level runner tag. The gittuf project — which became OpenSSF Incubating in June 2025 — provides a platform-agnostic path to Source L3 by storing policy and enforcement records in the Reference State Log (RSL) inside the repository itself, so a verifier can prove enforcement without trusting the forge. Sigstore's cosign verify-attestation reads source VSAs from Rekor entries as of cosign v2.5.
What should producers do in the next 90 days?
First, decide which Source level you can credibly claim today — most teams using GitHub or GitLab with branch protection and required reviews can reach Source L2 immediately and Source L3 within a sprint of CI work. Second, update your provenance generators to emit the v1.2 predicate schema with sourceLevels populated; the change is one line in slsa-github-generator. Third, add a source-VSA verification step to consumer pipelines so downstream builds reject artifacts whose source commit lacks an attested history. Fourth, document your level claim in SECURITY.md with a link to the issuing verifier — auditors will ask, and "we run on GitHub" is no longer a sufficient answer.
How Safeguard Helps
Safeguard ingests SLSA v1.2 Source and Build VSAs as first-class attestation types and links them to the artifacts they cover in the dependency graph. Policy gates can require SLSA_SOURCE_LEVEL_2 or higher on any component crossing a tier boundary — for example, blocking any third-party dependency without a source VSA from reaching a FedRAMP-aligned product. Griffin AI reads the verifiedLevels array and answers "show me every container image whose top-level source revision is only Source L1" without operators writing GraphQL. For producers, Safeguard's evidence pack exports Source and Build VSAs in the bundle format expected by CISA Self-Attestation reviewers and EU CRA conformity assessment bodies, so the same VSA satisfies multiple frameworks at once.