SLSA, or Supply Chain Levels for Software Artifacts is a security framework designed to prevent tampering within the software development process, improve the supply chain integrity of built artifacts, ensure the security of open source packages (beyond just vulnerability management) and secure the infrastructure your projects rely on from supply chain attacks.
SLSA was originally created by Google in response to the growing threats against the software supply chain, which includes everything from the third-party code an organization imports from open source ecosystems as well as third-party vendors through the systems and processes used across the software development lifecycle to the distribution systems that make software available both internally to developers and externally to customers.
Like OpenSSF, SLSA is now led by a vendor-neutral steering group encompassing multiple industries since any organization that builds, deploys or sells software can benefit from an industry-standard framework that enables better software security, integrity and reliability.
What is the SLSA Specification?
The SLSA specification outlines a set of security controls that can be implemented to improve the supply chain security and integrity of the software you build, as well as the source and dependencies required by each build.
- SLSA Level 1 – requires documenting of the supply chain, as well as infrastructure to generate provenance.
- SLSA Level 2 – requires that build systems be source-aware, and signatures be used to prevent tampering.
- SLSA Level 3 – requires that build definitions be derived from source, as well as a more hardened Continuous Integration (CI) process.
- SLSA Level 4 – requires that build environments are fully accounted for, dependencies are tracked in provenance, and insider threats are ruled out.
How can I use the SLSA framework?
The SLSA framework is a set of requirements for controls that can help secure the infrastructure, workflow and processes associated with source code, dependencies and build systems. The framework defines the requirement and goal for each control, but how you implement them will depend on your specific software development process.
For example:
- Source code must be:
- Version controlled
- Have a verifiable history
- Retained indefinitely
- Two-person reviewed
- Software builds must be:
- Scripted
- Parameterless
- Reproducible
- Driven by a dedicated build service
- Defined as code
- Built in ephemeral (rather than persistent) environments
- Built in isolated environments
- Built in hermetically sealed (i.e., no access to the internet) environments
- Dependency provenance must be:
- Available in a format like the in-toto ITE-6 attestation format
- Authenticated by a digital signature
- Generated by the build service
- Non-falsifiable
- Include a complete list of all build dependencies
In the software industry, provenance refers to the traceability of components (e.g., ability to identify the source/origin of a component, such as its public or private repo), as well as built artifacts produced during the development process (e.g., ability to identify the build process). Provenance can be verified by an attestation.
What are SLSA software attestations?
A SLSA software attestation is an authenticated, machine-readable statement (metadata) about one or more software artifacts generated in the in-toto ITE-6 format during the signing process. It can be used to verify a component, process or other entity, such as the provenance (source) of a dependency, vulnerability status of a component, result of a CI/CD test, etc.
A SLSA software attestation includes the following parts:
- Envelope: must minimally contain a statement and a signature that denotes the attestor. It is used to handle authentication and serialization.
- Statement: must minimally contain a subject and predicate:
- Subject: Identifies which artifacts the predicate applies to.
- Predicate: Contains arbitrary metadata about the subject.
- Bundle: (optional) a collection of attestations that are not necessarily related.
While popular cloud-native build systems like Github Actions and Azure DevOps can provide attestations for proprietary software builds, only the ActiveState Platform automatically builds all open source (including binary open source packages that contain native libraries) from source code, and provides an attestation for each.
Read Similar Stories
Click to learn what a software bill of materials is and how it can help you secure your development processes
Learn more about dependency confusion attacks, how they work and how to protect yourself from them.
Learn the different steps that go into securing your build processes.
