What is the difference between SLSA provenance level 2 and level 3 in enterprise supply chain security?

How SLSA provenance level 2 and level 3 differ

Level 2 gives you signed provenance that can be verified after the build, so you can tell whether the attestation was altered later. Level 3 tightens the trust boundary around the build itself, so the build job cannot shape or forge the attestation content from the outside. For enterprise supply chain security, that is the jump from “verifiable record” to “stronger build-system assurance.”

The practical difference is not just cryptographic signing. Level 2 still leaves room for the workflow to influence what gets claimed about the build, which means the attestation may be accurate only if the build environment behaves honestly. Level 3 reduces that exposure by making the provenance unforgeable from the build job’s perspective, which is why it is more useful when you want stronger confidence in artifact origin and integrity.

For teams comparing controls, the question is whether you need evidence that provenance exists, or evidence that the build process itself could not have been manipulated to produce misleading provenance. That distinction matters most when releases are automated, build permissions are broad, or multiple systems can affect the output of a pipeline. In those cases, provenance quality depends as much on workflow trust as on the signature alone. See the SLSA specification for the framework context, and NHIMG’s CI/CD Pipeline Identity Security Guide for the identity and signing controls that make provenance trustworthy in practice.

Risk and Threat Considerations

Level 2 provenance can still be undermined if an attacker, malicious workflow, or overly permissive build job can influence what gets attested. The risk is not only tampering after the fact, but also shaping the attestation at generation time so the signed record looks valid while misrepresenting the build conditions.

Failure mechanism: The build workflow, its credentials, or its inputs can affect the provenance content, so the signed attestation reflects a compromised or misleading build path rather than an independently protected build result.

Impact: Downstream consumers may trust an artifact on the basis of a provenance record that is technically signed but operationally weak, which can let unsafe, unreviewed, or substituted software move farther into production.

Practitioner Guidance

What to verify: Treat level 2 as a provenance verification baseline, not a guarantee of build isolation. Verify who can influence the workflow, what secrets or tokens the build can reach, and whether the attestation path is protected from job-level manipulation.

Decision rule: If the build environment can alter attestation content, signing inputs, or release metadata, level 3 is the more defensible target. If you only need a signed record for later verification and the workflow is already tightly controlled, level 2 may be sufficient for lower-risk artifacts.

What good looks like: The build system produces attestations that are both verifiable and operationally trustworthy, with minimal opportunity for the job itself to shape the claim. In mature environments, that usually means provenance, signing, and release permissions are governed as part of the same control set.

Practitioner takeaway: Choose level 2 when you mainly need signed provenance, and choose level 3 when you need stronger assurance that the build process itself could not have influenced the attestation in a material way.

Related resources from NHI Mgmt Group

• Guide: Dependency Update Automation Guide
• SLSA Provenance
• Supply Chain
• SLSA
• Chain