SLSA Source Track Guide: Source Levels, VSAs and Branch Controls Explained

Build provenance proves which pipeline turned a commit into a package, but it says nothing about whether that commit should ever have existed. The SLSA Source Track, published in SLSA v1.2, fills that gap with four source levels, rules for history, tags and code review, and attestations that let consumers check how a revision came to be. This guide explains the Source Track requirements level by level, how Source Verification Summary Attestations (Source VSAs) are structured and verified, and how to map the controls onto a real source control system such as GitHub or GitLab. It is for platform engineers, AppSec teams and maintainers who already know the Build Track from the SLSA and Build Provenance Guide and now need to secure the source end of the chain. Facts are from the SLSA v1.2 specification as checked on 27 October 2026.

Key takeaways

• The Source Track is final in SLSA v1.2. v1.2 was released on 24 November 2025, is backwards compatible with v1.1, and made no changes after its second release candidate; the Build Environment and Dependency tracks are still in development.
• Four levels, each a claim from onboarding forward. L1 version control, L2 history and provenance, L3 continuous technical controls, L4 two-party review. No claims are made for revisions before a branch was onboarded.
• Continuity is the hard part. A control only counts from the revision where it was switched on; any gap, such as an admin disabling branch protection for an afternoon, resets it.
• Consumers verify a Source VSA, not settings screenshots. The source control system issues a signed summary naming the commit, repository, references and level, and verifiers check it against a configured root of trust and their own expectations.
• The Source Track does not stop a trusted insider. SLSA says collusion between reviewers, rubber-stamp reviews and underhanded code are not currently addressed; pair it with review culture, maintainer identity controls and build provenance.

What the Source Track covers and why it exists

SLSA's threat model splits the supply chain into source, build, usage and dependency threats. The Source Track addresses threats A (producer), B (modifying the source) and C (source code management) from the SLSA v1.2 threat model. The adversary it defends against wants to inject unofficial behaviour into protected source code while avoiding detection, which means bypassing the organisation's change management process.

The SLSA blog analysis of the May 2026 Mini Shai-Hulud npm attack shows why this matters: the malicious packages carried cryptographically valid build provenance because the attacker ran code inside a legitimate pipeline. Build provenance accurately recorded the repository and workflow. Only policy that also demands source evidence (branch protection active, review met, authenticated identities) adds the next barrier. See the Shai-Hulud npm Worm Guide.

Key terms

The four source levels

A revision with no Source VSA is Source Level 0. At L1 and L2 an SCS may issue VSAs from its understanding of its own design, but from L2 upward it must base them on its own source provenance.

Requirements in practice

• History (L2): the SCS must record every change to Named References, and a branch may only move to a revision that descends from its current one. In git this means a technical control that blocks git push --force.
• Tags (L2): if the SCS supports tags, it must prevent them from being moved or deleted. The tj-actions/changed-files Compromise is the textbook case: a stolen bot token repointed almost all existing version tags to one malicious commit.
• Safe expunging (L2): removing content from history is allowed only for legal or privacy reasons, must follow a documented, tracked process, and should require an Administrator plus at least one other trusted person.
• Identity management (L2): the SCS must authenticate actors, let the organisation say who may perform sensitive actions, and document how actors are identified for attribution.
• Continuous controls (L3): if you claim every revision on main was tested, the SCS must enforce it; a convention is not enough. Custom controls (for example a required workflow) must be named, explained and traceable in the provenance.
• Two-party review (L4): uploader plus a different reviewer, or two reviewers, all trusted persons. If the change is modified during review, the new revision must be reviewed too. Moving reviewed content to another branch or repository needs review again, except well-understood automatic merges such as cutting a release branch.
• Robot exceptions (L4): an organisation may give a trusted robot, such as an import bot or Dependabot, a perpetual exception. That makes bot identities high-value targets, as the Fake Dependabot Commits incident showed when stolen tokens pushed code disguised as dependabot[bot].

Roles, identities and where identity fits

The specification defines four roles: Administrator (privileged operations such as changing history or security policy), Trusted person (may propose and approve), Trusted robot, and Untrusted person (may read, propose or review, but may not approve). Its assessment guidance asks consumers to judge an SCS against three adversary profiles: contributors, project maintainers who can change controls, and SCS administrators who can bypass maintainer controls and reach the control plane's signing secrets.

Two points matter for identity teams. First, the B1 mitigation requires that no actor can control or influence multiple accounts with review privileges, so one person with a second "test" account defeats L4. Second, the Future Considerations section lists forbidding second factors that are not phishing resistant and forbidding bearer tokens such as personal access tokens; these are not requirements in v1.2, but they signal where the bar is heading. Treat bot tokens, deploy keys and GitHub App credentials as part of the source trust boundary. See the Git Repository Security Guide and the Phishing-Resistant MFA Guide.

Source VSAs and source provenance

SLSA deliberately leaves the format of source provenance to each SCS, because GitHub, Gerrit and Subversion workflows produce different evidence. Interoperability comes from the Source VSA, which uses the SLSA Verification Summary Attestation format inside an in-toto Statement. See the in-toto Attestations Guide.

Organisation-defined properties must start with ORG_SOURCE_, and the SCS must enforce that prefix; ORG_SOURCE_INTERNAL_ marks properties not meant for external consumers. One detail to watch: the v1.2 text lists level values only up to SLSA_SOURCE_LEVEL_3 in the VSA field description even though the track defines L4, so confirm how your tooling expresses L4 before writing policy against it.

How to verify a source revision

1. Bootstrap roots of trust once: map each recognised SCS identity (public key or Sigstore identity) and verifier.id to the maximum source level you trust it for. A verifier may trust an SCS that claims L3 only up to L2.
2. Check the SCS: confirm the VSA signature chains to a root of trust and that its subject matches the fetched revision.
3. Check expectations: compare resourceUri, sourceRefs, verificationResult and verifiedLevels with expected values, set either by trust on first use (alert on any change) or by the producer through an authenticated channel protected against unilateral edits.
4. Optionally verify evidence: at L3 and above, inspect the source provenance attestations directly, with the producer's documentation of what each one means.
5. Choose where to enforce: the spec lists build systems at source fetch, package ecosystems at upload, consumers at download, or continuous monitoring. At least one should be used.

Mapping the Source Track onto your SCS

The Source Track is platform-neutral. The table maps its requirements to GitHub ruleset rules, which are documented and widely used; GitLab protected branches and tags provide equivalents. Tooling to emit Source Track attestations is still young: the SLSA project's own source-tool is marked "in development", and gittuf, an OpenSSF incubating project that enforces git policy independently of the forge, is in beta.

Choosing a target level

• L2 for everything: it costs little on a hosted forge (block force pushes, protect tags) and gives consumers trustworthy history.
• L3 for repositories that ship to customers or production: the real work is documenting each control and proving continuity, which means monitoring rule changes.
• L4 where unilateral change is unacceptable: critical libraries, infrastructure-as-code, release tooling. Small teams struggle with two trusted persons per change; a two-person open source project can reach L4 only if both maintainers review each other's work promptly.
• Large organisations: use organisation-level rulesets so repositories inherit controls, and consider merge trains, for which the spec's example controls require an attestation that the train did not add or remove content.

Rolling out the Source Track

1. Inventory and classify: list repositories, their consumers and the target level for each. Record who holds admin and bypass rights.
2. Write the control documentation first: L3 requires the meaning of each technical control to be documented, so write it before you claim anything.
3. Pilot in evaluate mode: where your forge offers an evaluate or audit status for rules, run it on two or three repositories to see which merges would fail, then switch to active.
4. Onboard at a known revision: continuity starts at the first revision after a control is enforced. Record that commit as the onboarding point; earlier history carries no claim.
5. Issue and publish VSAs: use your SCS's native support or tooling such as source-tool, and make VSAs fetchable by anyone authorised to read the revision.
6. Enforce downstream: add source VSA checks to the build system at fetch time, alongside build provenance checks at deploy. See the CI/CD Security Guide.
7. Roll back safely: if a rule blocks a release, use a documented break-glass bypass and accept that continuity resets for the affected control; never quietly disable protection.

Detection and measurement

• Rule change events: alert on any ruleset or branch protection edit, any addition to a bypass list and any admin bypass use, since each can break continuity.
• Reference events: forced updates, tag moves or deletions on protected patterns should be impossible; treat any occurrence as an incident.
• Merges without review: merged pull requests with zero non-author approvals, and direct pushes by robot identities.
• Expunging log: every safe-expunging action with its ticket and the second approver.

Metrics that show the programme working:

• Percentage of production-bound repositories with a Source VSA at the target level.
• Continuity resets per quarter (target falling to zero).
• Number of bypass actors per protected repository (target one break-glass role or none).
• Share of builds that verify source VSAs before building.
• Robot identities holding review exceptions, each with an owner and rotation date.

Common failure patterns

• Moving release tags: teams reuse tags such as v1 as moving pointers; under SLSA these are Named References, not Tags, and consumers pinning them inherit the risk the tj-actions incident exposed.
• Admin bypass as routine: repository admins merging their own changes "just this once" both violates L4 and resets L3 continuity. SLSA threat B1 names controls being disabled by trusted admins as a specific threat.
• Stale approvals: approving a pull request and then letting the author push more commits without re-review fails the final-revision rule.
• Multiple accounts per person: a maintainer with a second account, or a bot whose token a single engineer controls, can approve their own changes.
• Trusting the repository but not the release artefact: in the XZ Utils Backdoor, a trusted maintainer persona hid the activation in release tarballs rather than in the reviewed source. The Source Track would not have stopped a trusted producer (threat A); build provenance tying artefacts to a source revision and checks that tarballs match the repository are what close that gap.
• Claiming levels without verification: publishing a badge without fetchable VSAs, or verifying that a VSA exists without checking resourceUri and sourceRefs.

Framework mapping

Practitioner checklist

• Target source levels are set per repository and recorded with an onboarding revision.
• Force pushes are blocked and release tags are protected against updates and deletion on every production repository.
• Each technical control claimed at L3 is documented, enforced by the SCS and monitored for changes.
• L4 repositories require approval by someone other than the last pusher and dismiss stale approvals.
• Bypass lists are empty or limited to a logged break-glass role.
• Robot identities with review exceptions are inventoried, owned and use short-lived credentials where possible.
• No person controls more than one account with review rights.
• Source VSAs are published and fetchable, and builds verify them against configured roots of trust and expectations.
• A safe expunging procedure exists with two-person approval and a log.

Standards and references

• OpenSSF SLSA: Source Track Requirements (v1.2)
• OpenSSF SLSA: Verifying Source (v1.2)
• OpenSSF SLSA: Source Example Controls (v1.2)
• OpenSSF SLSA: Assessing Source Control Systems (v1.2)
• OpenSSF SLSA: Threats and Mitigations (v1.2)
• GitHub Docs: Available rules for rulesets
• OpenSSF: gittuf
• OpenSSF SLSA: Mini Shai-Hulud, Where SLSA's Boundaries Fall

Related NHI Mgmt Group resources: SLSA and Build Provenance Guide · GitHub and GitHub Actions Security Guide · Secure Code Review Guide · Software Supply Chain Security Guide