SLSA Framework
SLSA is a framework for describing and improving the integrity of software from source change through build and distribution. Its tracks and levels help producers create evidence about software and help consumers decide whether that evidence meets their trust policy.
itSoftware supply chain security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
SLSA Framework
Software reaches you through a chain of people, systems, and transformations. A source revision enters a build platform. The platform produces an artifact. A registry or other channel distributes that artifact. Each link creates a chance for unauthorized change.
SLSA gives you a shared way to reason about that chain. The name stands for Supply-chain Levels for Software Artifacts. The approved version 1.2 specification organizes requirements into independent tracks. Each track addresses one part of the supply chain. Levels within a track represent stronger guarantees.
SLSA is useful to three groups:
- Producers use its requirements to improve how they create and release software.
- Consumers verify evidence before they trust or use an artifact or source revision.
- Infrastructure providers build the source control, build, package, and distribution systems that make those guarantees possible.
The central idea is evidence plus verification. A producer distributes provenance that describes how an artifact or source revision came to exist. A verifier authenticates that provenance and compares it with explicit expectations. Evidence without inspection does not enforce a policy.
Two tracks, two questions
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://slsa.dev/spec/v1.2/
Supports
- SLSA version 1.2 as the approved current specification
- Build and Source track organization
- Provenance and verification summary formats as recommended formats
- https://slsa.dev/spec/v1.2/about
Supports
- Incrementally adoptable guidelines and intended audiences
- Tracks and ascending levels
- Limits involving vulnerabilities, dependencies, and broader security controls
- https://slsa.dev/spec/v1.2/tracks
Supports
- Independent tracks with distinct threats and requirements
- Build provenance purpose and consumer verification model
- Source track purpose
- https://slsa.dev/spec/v1.2/build-track-basics
Supports
- Build Levels 1 through 3 names, requirements, and benefits
- Build Level 1 provenance limitations
- Build Level 2 hosted platform and post-build tamper protection
- Build Level 3 hardened platform and during-build tamper protection
- https://slsa.dev/spec/v1.2/build-requirements
Supports
- Producer and build-platform responsibilities
- Provenance existence, authenticity, accuracy, and completeness requirements
- Hosted and isolated build requirements
- Ephemeral environments, signing-secret protection, and cache isolation
- https://slsa.dev/spec/v1.2/source-requirements
Supports
- Source Levels 1 through 4 names and requirements
- Source revision, source control system, and source provenance definitions
- Reliable history, enforced controls, and two-party review
- https://slsa.dev/spec/v1.2/provenance
Supports
- Provenance definition
- Distinction between Build and Source provenance
- https://slsa.dev/spec/v1.2/verifying-artifacts
Supports
- Provenance inspection as verification
- Signature, subject digest, predicate type, and builder trust checks
- Canonical source, build type, and external parameter expectations
- Publication, consumer, and monitoring verification architectures
- https://slsa.dev/spec/v1.2/threats
Supports
- Source, build, distribution, usage, dependency, and verification threats
- Malicious producer and recursive dependency risks
- Automation as a design priority for broad adoption
- https://slsa.dev/spec/v1.2/use-cases
Supports
- First-party, open source, and vendor applications
- Publication and download verification examples
- https://github.com/sindresorhus/awesome
Supports
- Starting point for discovering security and DevSecOps awesome lists
- https://github.com/bureado/awesome-software-supply-chain-security
Supports
- Discovery of Cosign, SLSA GitHub Generator, in-toto, Witness, and GUAC
- Project categorization across signing, provenance, frameworks, and metadata
- https://docs.sigstore.dev/quickstart/quickstart-cosign/
Supports
- Cosign as a command-line tool for signing artifacts and verifying signatures
- Verification bundles containing signature, certificate, and log inclusion proof
- https://github.com/slsa-framework/slsa-github-generator
Supports
- GitHub Actions provenance generation and verification tooling
- Build Level 3 provenance support and stated limitations
- https://in-toto.io/
Supports
- Open metadata framework for supply-chain integrity
- Evidence about steps, actors, and ordering
- https://witness.dev/docs/
Supports
- Pipeline attestations using the in-toto specification
- Policy verification and software journey audit trails
- https://docs.guac.sh/guac/
Supports
- Ingestion of software security metadata into a graph
- Supply-chain visualization, policy, audit, and risk analysis uses