SLSA v1.2 Source Level 4 requires that the source control system enforces review by two trusted persons for all changes to protected branches before they land. It sits on top of levels for version control, history and provenance, and continuous technical controls. It covers source review, not build integrity.
The four Source levels
The v1.2 Source track describes four levels, each building on the one before. These are the summaries as the specification words them, in short form.
| Level | Name | Summary |
|---|---|---|
| 1 | Version controlled | Source is stored and managed in a modern version control system |
| 2 | History and provenance | Branch history is continuous, immutable and retained, and the system issues source provenance attestations |
| 3 | Continuous technical controls | The system enforces the organization's technical controls for specific named references |
| 4 | Two party review | Two trusted persons review all changes to protected branches |
The page adds that if a source control system produces no verification summary attestation for a revision, the revision has Source Level 0.
What two party review means in practice
Level 4 is about protected branches, the named references where your release code lives. Every change that reaches them needs approval from two trusted persons before submission. That has consequences:
- Two people, not one. The rule asks for two trusted persons, so a single approver is not enough. Check the spec text for how it treats the change author.
- Enforcement is by the system. It is the source control system that requires the review, not a team habit. Branch protection rules are the usual mechanism.
- Trust is defined. You decide who counts as a trusted person and document it so a verifier can check.
- All changes, no exceptions. Hotfixes, dependency bumps and bot changes all need a path that meets the rule.
Where small teams struggle
Two party review is hard for a one or two person team. If you have two maintainers, each must review the other's work, and absence blocks releases. Before aiming for L4, answer these:
- Who are the trusted persons, by name or by role?
- What happens when one is on leave?
- How do bot-authored changes get reviewed?
- Is there an emergency path, and is its use logged?
If you cannot answer these, L3 is a sensible target while you build the habit. There is no benefit to claiming a level your process cannot sustain.
What it does not prove
Source review addresses the risk that a bad change slips into the branch. It does not tell you whether the build from that source was tampered with. That is the Build track's job. It also does not tell you the reviewers read carefully. A review is only as good as the person doing it, so pair the control with clear review guidelines and small changes.
For a related look at the review habit itself, see two person review when you are the only maintainer. For version wording in claims, read which SLSA version should you cite.
Safeguard's policies, gates and guardrails can enforce checks on pull requests, and its evidence automation helps keep the record of who approved what. The free scan is at gold.safeguard.sh/scan.
Quick check
Does Source L4 mean the build is secure?
No. It concerns review of source changes. Build integrity belongs to the Build track.
What is the default level if no attestation exists?
The specification says a revision with no verification summary attestation has Source Level 0.
Sources
Last reviewed: 19 October 2026.
