About SLSA
SLSA, pronounced salsa, stands for Supply-chain Levels for Software Artifacts. SLSA is a set of industry guidelines for safeguarding artifact integrity across the software supply chain. SLSA standards and controls are designed to prevent tampering, improve integrity, and secure packages and infrastructure. SLSA guidelines are set forth by a cross-organization, vendor-neutral steering group under the auspices of the Open Source Security Foundation (OpenSSF). Minimus complies with SLSA L3, the highest level of supply chain security. This is to guarantee that Minimus software hasn’t been tampered with and can be securely traced back to its source. By verifying Minimus image signatures, users can verify that the source code packaged and delivered by Minimus is the same code they are actually using.SLSA L3 Overview
The SLSA framework defines 3 levels of requirements that mitigate supply-chain attacks, with SLSA L3 being the highest level of assurance: artifacts must be built in isolated, verifiable, and tamper-resistant environments with non-falsifiable provenance with immutable attestations. The following table is provided in the official SLSA site (ref):| Level | Requirements | Focus |
|---|---|---|
| Build L0 | (none) | (n/a) |
| Build L1 | Provenance showing how the package was built | Mistakes, documentation |
| Build L2 | Signed provenance, generated by a hosted build platform | Tampering after the build |
| Build L3 | Hardened build platform | Tampering during the build |
- Verified provenance: Provenance must be authenticated and non-falsifiable.
- Build isolation: Each build is hermetically sealed to prevent cross-build contamination.
- Controlled secrets and inputs: Build secrets are managed by the platform, not user code.
- Auditable source and build systems: Source and build platforms must enforce versioned, tamper-evident change tracking.
How Minimus Images Achieve SLSA Level 3 Compliance
Users can rely on Minimus images and packages with confidence because Minimus takes every precaution when building its artifacts. Following is the list of protections in place. 1. Authenticated Provenance Generation The Minimus build service automatically generates provenance metadata for every image build. This metadata includes commit hashes, dependency manifests, environment hashes, and builder identity. Provenance is signed by the Minimus attestation service using the Sigstore toolchain to guarantee authenticity. 2. Isolated, Ephemeral Build Environments Each build runs in a disposable, isolated sandbox provisioned via Minimus’ internal CI orchestrator. Environments are short-lived and immutable: once the build completes, the runner and its intermediate data are destroyed. This architecture ensures no state persists across builds, satisfying SLSA L3 isolation requirements. 3. Controlled Secrets and Build Inputs Build secrets such as signing credentials and deployment tokens are injected only at runtime and are unavailable to user-defined steps. Inputs such as source and dependencies are pulled from verified registries using pinned references, preventing substitution attacks. 4. Auditable Build and Source Systems All repositories in the Minimus source control are versioned and protected by mandatory code-review policies. Build definitions including pipelines are also version-controlled, and every pipeline execution is logged and stored immutably for post-build verification. 5. Provenance Verification and Policy Enforcement Users can verify the provenance of Minimus images by validating image signatures and SBOM signatures using Cosign.Summary Table: Minimus Implementation of SLSA L3 Guidelines
| SLSA L3 Objective | Requirement | Minimus Implementation |
|---|---|---|
| Authenticated provenance | Non-falsifiable provenance signed by trusted builder | Sigstore provenance generated per build |
| Build isolation | No shared state between builds | Ephemeral sandbox runners with immutable environments |
| Secret protection | Build secrets not accessible to user code | Secrets injected at runtime and isolated from user logic |
| Verified inputs | Dependencies must be versioned and verified | Commit-pinned sources and dependency registries |
| Auditable source & build systems | Controlled, versioned, and monitored | Mandatory code reviews, immutable CI logs |
| Provenance verification | Allow users to verify artifacts | Image and SBOM signature provided for every image build |