SLSA v1.1 landed quietly in March 2026, and that is exactly how the update was meant to feel. There are no dramatic new levels, no deprecated concepts, and no breaking changes to existing attestation consumers. What there is, though, is a sharper build track, a source track draft that finally makes the framework feel complete, and a set of clarifications that close gaps implementers have been complaining about since v1.0. For teams that invested in SLSA last year, this is a minor-version polish. For teams starting now, it is the right moment to adopt.
This post summarises what changed, why it matters, and where the edges still live. We focus on the guidance that will actually move through a compliance team's workflow: the build track requirements, the source track draft, the attestation predicates, and the new clarifications around compromise response. We are not going to re-explain the levels; the official specification does that well, and the community has learned to speak that vocabulary fluently.
What changed at the build track?
The build track sharpened several requirements that implementers had been interpreting loosely. Level 3 now explicitly requires that build platforms retain the build instructions as part of the attestation, not just a reference to them. Isolation requirements are stricter: build steps must run in environments that cannot influence other concurrent builds, which is a clarification aimed at shared-tenancy CI providers. And the attestation format has gained a standardized internalParameters field that lets platforms record non-public build inputs without leaking secrets.
The change that matters most operationally is around "hosted" build platforms. v1.1 tightens the definition so that a platform operating on hardware the consumer does not control must meet a documented set of isolation and logging requirements before it can claim Level 3 on behalf of the consumer. In practice, this means GitHub Actions, GitLab SaaS, and Buildkite all updated their SLSA posture pages within weeks of the release, and a few smaller CI providers quietly stopped claiming Level 3 until they could meet the bar.
What is the new source track?
The new source track is a draft specification that extends SLSA's guarantees from the build environment back into the source repository. It defines levels that address branch protection, commit signing, review requirements, and the ability to retrieve the exact source snapshot that produced an attested artifact. At the highest level, the source track requires cryptographic linking between every commit, the reviewer identities, and the resulting build.
The draft is opinionated in ways that will be familiar to teams running a modern GitHub Enterprise setup: protected branches, required reviewers, signed commits, and Git provenance metadata. It is also explicit that the source track is a supplement to, not a replacement for, the build track. A mature SLSA posture in 2026 means claiming levels across both tracks, not choosing between them.
How did attestation semantics get clarified?
Attestation semantics got clarified in three places that were causing field confusion. First, the builder.id field is now unambiguously a URI identifying the exact build system version, not just the vendor. Second, resolvedDependencies is reserved for externally fetched inputs that influence the build, and the spec gives concrete examples of what belongs in it and what does not. Third, the buildType field must now reference a public schema, so consumers of attestations can validate the expected structure of the remaining fields.
These sound like minor editorial changes, and in a sense they are. But the field confusion was real. We have reviewed attestations where builder.id pointed to "github-actions" with no version, and where resolvedDependencies included the builder itself. The clarifications let verifiers be stricter without rejecting good-faith attestations, which is exactly where a framework wants to land.
How does v1.1 handle compromise response?
v1.1 adds explicit guidance on compromise response, a section that was previously implied but never written down. The guidance is pragmatic: build platforms must publish a process for invalidating attestations tied to a compromised build environment, and consumers are encouraged to treat attestations from periods of known compromise as untrusted even if individual attestations remain cryptographically valid.
The practical implication is that enterprise policy gates should include a "known compromise window" check against a feed that the build platform publishes. Early implementations of this feed are rough, but the direction is clear. A year from now, we expect every major CI provider to publish a signed feed of its own incident windows, and policy engines will subscribe to them the way they subscribe to CVE feeds today.
What should teams do right now?
Teams should treat v1.1 as a prompt to audit their existing attestation production and consumption. If you produce attestations, check that your builder ID is a versioned URI, that your resolvedDependencies list is clean, and that your buildType points to a published schema. If you consume attestations, update your verification library to the v1.1 predicates and start dropping attestations from known-compromised windows. If you have been waiting to adopt the source track, the draft is stable enough to pilot.
Most importantly, teams should stop treating SLSA as a binary compliance artifact. The framework is a lever for real supply chain assurance, and the v1.1 updates make that lever more useful. The best deployments we see are the ones that wire attestation verification into policy gates and into incident response, not the ones that simply collect attestations for audit.
How Safeguard Helps
Safeguard verifies SLSA v1.1 attestations on ingest, normalises them into the same SBOM model as CycloneDX and SPDX, and records the full build provenance alongside every component. Reachability analysis runs on the attested artifact so you can confirm which CVEs are callable from your deployed services, and TPRM scores suppliers based in part on their SLSA posture across both build and source tracks. Griffin AI flags attestations that fall inside known-compromise windows and surfaces packages that silently lost provenance during a rebuild. Policy gates in CI block merges and deployments that fail your SLSA bar, so the framework becomes a real enforcement mechanism rather than a compliance checkbox.