A demo of SLSA functionality
The build process must be fully scripted/automated and generate provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. Knowing the provenance allows software consumers to make risk-based security decisions. Provenance at SLSA 1 does not protect against tampering, but it offers a basic level of code source identification and can aid in vulnerability management.
Source: https://slsa.dev/spec/v0.1/levels#detailed-explanation
Detailed requirements:
Demo: Create a new tag, e.g., git tag -a v0.1.0 -m "v0.1.0" and push it to
GitHub. This will trigger a GitHub Action that will build the source and
generate a provenance file. The provenance file will be uploaded together with
the resulting binary.
Requires using version control and a hosted build service that generates authenticated provenance. These additional requirements give the software consumer greater confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3.
Detailed requirements:
Same as 1, plus:
- Authenticated - The provenance is signed by the build service in a way that allows the consumer to verify that it has not been tampered with.
- Service generated
- The provenance is generated by the build service, not directly by e.g. a developer.
Demo: Create a new tag, e.g., git tag -a v0.2.0 -m "v0.2.0" and push it to
GitHub. Then you can download the provenance file and verify it using the
signature like so: gpg --verify build.provenance.asc build.provenance.
The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination.
Detailed requirements:
Same as 2, plus:
- Build as code
- For instance, a build.yaml file specifying the build process. Must be verifiably derived from a version controlled document.
- Ephemeral environment
- The build is ran in a stateless environment, e.g., a docker container.
- Isolated
- Build instances must not affect each other.
- Build containers must not access to secrets.
- Etc (see link)
- Non-falsifiable
- Higher demands on how the secret keys are stored, mainly.
Requires two-person review of all changes and a hermetic, reproducible build process. Two-person review is an industry best practice for catching mistakes and deterring bad behavior. Hermetic builds guarantee that the provenance’s list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with.
Detailed requirements:
Same as 3, plus:
- Parameterless
- Hermetic
- Dependencies, etc, are described with immutable references.
- Reproducible*
- Except if you have a good reason.
- Dependencies complete
- Records all build dependencies, as well as state of build environment.
- Security
- General security requirements of the entire system. Undefined as of now.
- Access
- Also poorly defined.
- Superusers
- Admins may override all guarantees of SLSA, as long as they don't do it often?