Future directions
The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA might evolve in future versions to re-introduce those notions and add other additional aspects of automatable supply chain security.
Build track
Build L4
A build L4 could include further hardening of the build platform and enabling corroboration of the provenance, for example by providing complete knowledge of the build inputs.
The initial draft version (v0.1) of SLSA defined a “SLSA 4” that included the following requirements, which may or may not be part of a future Build L4:
- Pinned dependencies, which guarantee that each build runs on exactly the same set of inputs.
- Hermetic builds, which guarantee that no extraneous dependencies are used.
- All dependencies listed in the provenance, which enables downstream verifiers to recursively apply SLSA to dependencies.
- Reproducible builds, which enable other build platforms to corroborate the provenance.
Platform Operations track
A Platform Operations track could provide assurances around the hardening of platforms (e.g. build or source platforms) as they are operated.
The initial draft version (v0.1) of SLSA included a section on common requirements that formed the foundation of the guidance for assessing build platforms, which may or may not form the basis for a future Build Platform Operations track:
- Controls for approval, logging, and auditing of all physical and remote access to platform infrastructure, cryptographic secrets, and privileged debugging interfaces.
- Conformance to security best practices to minimize the risk of compromise.
- Protection of cryptographic secrets used by the build platform.