Supply Chain Levels for Software Artifacts (SLSA)
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.
- Source code must be:
- Version controlled
- Have a verifiable history
- Retained indefinitely
- Two-person reviewed
- Software builds must be:
- 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
- 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.
ActiveState’s commitment to open source and participation in SLSA.
ActiveState is committed to participating in the open source community. Recently, Loreli Cadapan, Chief Product Officer spoke as a part of the OpenSSF Tech Talk on Securing the Software Supply Chain: An In-Depth Exploration of SLSA. You’ll get a comprehensive overview of SLSA and dig into SLSA fundamentals, trust and transparency in software artifacts, security levels of SLSA, industry impact, future trends, and more. View the recording here. SLSA also relies heavily on software attestations & SBOMs.
Learn more about our approach to Supply chain Levels for Software Artifacts (SLSA) in our whitepaper.