OpenSSF publication
SLSA
Supply-chain Levels for Software Artifacts — a framework of progressive security requirements for source, build, and provenance integrity.
How each persona uses SLSA
Software Developer / Maintainer Developer
Follows SLSA guidelines to implement secure coding and build practices that prevent tampering with their source code.
Open Source Professional (OSPO) OSPO
Adopts the SLSA framework as an organizational standard to systematically measure and improve the supply chain security of all projects.
Security Engineer / Architect Security
Uses the SLSA framework to identify architectural gaps in the build process and design tamper-evident build systems.
CI/CD DevOps & Tooling Integrator DevOps
Applies the SLSA framework to generate non-falsifiable build provenance, ensuring that the artifact produced can be cryptographically traced back to the specific source and build platform.
Package & Repository Manager Package Manager
Requires specific SLSA compliance levels before allowing high-profile packages to be published or verified in the repository.
Executive / End-User Consumer Executive
Mandates SLSA compliance to assure enterprise customers and regulators that the organization's software is protected against supply chain tampering.
Problems SLSA helps with
Build & Provenance Integrity Build Integrity
Defines progressive levels for source, build, and provenance integrity so artefacts can be traced back to their origin.
Policy & Compliance Enforcement Compliance
Gives organizations a tiered standard to mandate and demonstrate supply-chain security to customers and regulators.
Relationships
Outgoing
-
producesSLSA Provenancepublication
Conforming SLSA build-track implementations emit signed SLSA Provenance for every artefact they produce.
Incoming
- implemented byslsa-github-generator
- implemented byslsa-verifier