SLSA

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

Requirements

Source: https://slsa.dev/spec/v0.1/requirements

Implementation

GitHub

Tool	Description
SLSA GitHub Actions Demo	A proof-of-concept SLSA provenance generator for GitHub Actions.
slsa-github-generator	Tools for generating non-forgeable SLSA provenance on GitHub that meets the build and provenance requirements for SLSA level 3 and above General Availability of SLSA 3 Go native builder for GitHub Actions: how to use trusted builders for Go applications General availability of SLSA3 Generic Generator for GitHub Actions: generate provenance documents for projects developed in any programming language General availability of SLSA 3 Container Generator for GitHub Actions: allows any GitHub project to produce SLSA level 3 compliant provenance statements so users can verify the origin of container images they use
slsa-verifier	Verification of SLSA provenance
syft	CLI tool and library for generating a Software Bill of Materials from container images and filesystems

References

SLSA

Link	Notes
Supply-chain Levels for Software Artifacts (SLSA)	End-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain Inspired by Google's internal "Binary Authorization for Borg" Introducing SLSA, an End-to-End Framework for Supply Chain Integrity
How to SLSA	Three-part series exploring how three fictional organizations would apply SLSA to meet their different needs Part 1 - The Basics Part 2 - The Details Part 3 - Putting it all together
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

SBOMs

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