Skip to content


SLSA Overview

What SLSA is

SLSA is a set of standards and technical controls you can adopt to improve artifact integrity, and build towards completely resilient systems. It’s not a single tool, but a step-by-step outline to prevent artifacts being tampered with and tampered artifacts from being used, and at the higher levels, hardening up the platforms that make up a supply chain.

Key Terms

Term Description
Software Integrity Software artifacts that have integrity have not been modified in an unauthorized manner
Code Signing Code signing refers to the creation of a cryptographic digital signature that ties an identity (often a company or a person) to an artifact. This signature proves to the consumer that the software has not been tampered with and that the specified party approves the artifact
Attestations An attestation is signed metadata about one or more software artifacts. Metadata can refer, for instance, to how an artifact was produced, including the build command and associated dependencies. An attestation must also include a signature by the party that created the attestation
SBOMs A software bill of materials, or a list of ingredients that make up software components
Provenance Provenance refers to information about who produced one or more software artifacts, and what steps and materials were used to produce those artifacts

Supply chain threats

SLSA Levels

Level Description Example
  • Documentation of the build process
  • The build process must be fully scripted/automated and generate provenance
Unsigned provenance
  • Tamper resistance of the build service
  • Requires using version control and a hosted build service that generates authenticated provenance
  • Level 2 shows more trustworthiness in the build, builders are source-aware, and signatures are used to prevent provenance being tampered with
Hosted source/build, signed provenance
  • Extra resistance to specific threats
  • The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively
  • Level 3 shows that a system’s builds are fully trustworthy, build definitions come from the source and a system has more hardened CI
Security controls on host, non-falsifiable provenance
  • Highest levels of confidence and trust
  • Requires two-person review of all changes and a hermetic, reproducible build process
  • Level 4 means the build environment is fully accounted for, dependencies are tracked in provenance and insider threats are ruled out
Two-party review + hermetic builds





Tool Description
SLSA GitHub Actions Demo A proof-of-concept SLSA provenance generator for GitHub Actions.
slsa-verifier Verification of SLSA provenance
syft CLI tool and library for generating a Software Bill of Materials from container images and filesystems



Link Notes
Supply-chain Levels for Software Artifacts (SLSA)
How to SLSA
SBOM + SLSA: Accelerating SBOM success with the help of SLSA
  • The strengths of SBOMs and SLSA and how they fundamentally differ
  • How SLSA principles can both support the generation of high-quality SBOMs
General Availability of SLSA 3 Go native builder for GitHub Actions
  • How to use the newly released trusted builders for Go applications, and examples of how you can use the generated information
Improving software supply chain security with tamper-proof builds A reference implementation for achieving SLSA 3 and creating non-forgeable build provenance using only free tooling on GitHub Actions
Announcing GUAC, a great pairing with SLSA (and SBOM) Graph for Understanding Artifact Composition (GUAC) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them
SLSA: The Source of the problem A well-written article on software supply chain security, covering: SLSA, different strategies for attacking Source Code Management (SCM), and attack trees


Link Notes
Not All SBOMs Are Created Equal
  • Why SCA tools don't see locally built software
  • How to make SCA tools see locally built software
SBOMs are just a means to an end
  • The industry movement towards SBOMs needs material interventions to be usable at scale for exceedingly basic use cases
  • This post hopes to begins a discussion at the industry level that brings us closer to our desired state and to challenge the notion of what that desired state even is
What your scanner doesn't know can hurt you How most vulnerability scanners for containers work, and highlights a few challenges this approach has that can lead to blind spots in your infrastructure

Other Resources

Link Notes
Dependencies, Confusions, and Solutions: What Did Twilio Do to Solve Dependency Confusion
  • Naming conventions for all internal packages
  • Block proxying of certain packages
  • Internal package manager as single source
  • Restrict deployed hosts from accessing the registry
  • Controls for laptop access
ssc-reading-list A reading list for software supply-chain security
Open Source Software (OSS) Secure Supply Chain (SSC) Framework Guide from Microsoft outlining how to securely consume OSS dependencies into the developer's workflow