SLSA Supply Chain

Supply-chain Levels for Software Artifacts: provenance, integrity, supply chain security (L1-L4).


Short name	SLSA
Region	International
Country or scope	International
Sector	Supply Chain
In your workspace	On unless you switch it off in Compliance › Manage.

How Safeguard covers SLSA

Scan requirements: 6, all decided by a scan.
Controls: the scan requirements below, plus 11 controls from Safeguard's control catalog for SLSA.
Automated tests: none map to it directly. You can link any automated test to its controls yourself (how).
Policy templates: 24: 2 written for SLSA and 22 from the standard set.

How each kind of coverage works, and what the readiness score counts: Compliance frameworks.

What a scan checks

Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).

Requirement	What Safeguard checks	Decided by
`SLSA-L1-PROV` Provenance Exists	Build Level 1 requires that provenance is generated describing how the artifact was built, including the identity of the builder or tooling (SLSA v1.0 Build L1: provenance exists)	Scan
`SLSA-PROV-FMT` Machine-Readable Attestation	SLSA provenance and related supply chain documents must be machine-readable so verification can be automated; SBOM equivalents are SPDX or CycloneDX documents (SLSA v1.0 provenance format requirements)	Scan
`SLSA-DIGEST` Artifact Digests	Provenance must identify output artifacts by cryptographic digest, so components in the accompanying inventory must carry integrity hashes (SLSA v1.0 provenance schema: subject digests)	Scan
`SLSA-DEPS` Resolved Dependencies Recorded	Higher-fidelity provenance records the dependencies resolved during the build, which maps to a documented dependency graph in the SBOM (SLSA v1.0 provenance: resolvedDependencies)	Scan
`SLSA-ID` Unambiguous Artifact Identity	Verifying an artifact against provenance requires an unambiguous identity for each component, i.e. a standard identifier such as a PURL (SLSA v1.0 verification model)	Scan
`SLSA-PIN` Pinned, Specific Versions	Tamper-resistant builds require inputs pinned to specific immutable versions rather than floating references like 'latest' (SLSA v1.0 build integrity principles)	Scan

More controls in the catalog

The framework's Controls tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.

Control	Name
`SLSA-SRC-L1`	Store All Source Code in Version Control
`SLSA-SRC-L2`	Maintain Verified Commit History
`SLSA-SRC-L3`	Require Two-Person Review for Protected Branch Changes
`SLSA-BUILD-L1`	Use Scripted, Automated Build Process
`SLSA-BUILD-L2`	Run Builds in Isolated Environments
`SLSA-BUILD-L3`	Enforce Hermetic and Parameterless Builds
`SLSA-PROV-L1`	Generate Build Provenance for Every Artifact
`SLSA-PROV-L2`	Authenticate Provenance via Service-Generated Attestation
`SLSA-PROV-L3`	Ensure Provenance is Non-Falsifiable
`SLSA-COMMON-1`	Apply Security Practices to Build Infrastructure
`SLSA-COMMON-2`	Restrict Access to Build Secrets and Signing Keys

Policy templates

Written for SLSA:

SLSA Build Provenance Policy
CI/CD Pipeline Security and Integrity Policy

And 22 from the standard set, adapted to SLSA.