-
Notifications
You must be signed in to change notification settings - Fork 213
/
future-directions.md
77 lines (56 loc) · 3.18 KB
/
future-directions.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
---
title: Future directions
description: 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 these notions and add other additional aspects of automatable supply chain security.
---
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.
<section id="build-l4">
## Build track
### Build L4
A build L4 could include further hardening of the build platform and enabling
corraboration 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.
</section>
<section id="source-track">
## Source track
A Source track could provide protection against tampering of the source code
prior to the build.
The initial [draft version (v0.1)](../v0.1/requirements.md#source-requirements)
of SLSA included the following source requirements, which **may or may not**
form the basis for a future Source track:
- Strong authentication of author and reviewer identities, such as 2-factor
authentication using a hardware security key, to resist account and
credential compromise.
- Retention of the source code to allow for after-the-fact inspection and
future rebuilds.
- Mandatory two-person review of all changes to the source to prevent a single
compromised actor or account from introducing malicious changes.
</section>
<section id="build-platform-operations-track">
## Build Platform Operations track
A Build Platform Operations track could provide assurances around the hardening
of build platforms as they are operated.
The initial [draft version (v0.1)] of SLSA included a section on
[common requirements](../v0.1/requirements.md#common-requirements) that formed
the foundation of the guidance for
[verifying build systems](verifying-systems.md), 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.
</section>
[draft version (v0.1)]: ../v0.1/requirements.md