ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Source Requirements1234Status/Justification
2
Version controlledEvery change to the source is tracked in a version control system that meets the following requirements✓✓✓✓Project source code is tracked in git
3
Verified historyEvery change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp.✓✓All Istio PRs are either authored or LGTM'ed by org members Org membership requires 2 factor auth.
4
Retained indefinitelyThe revision and its change history are preserved indefinitely and cannot be deleted, except when subject to an established and transparent policy for obliteration, such as a legal or policy requirement.Git tree remains unaltered. Source code of the build is archived
5
Two-person reviewedEvery change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. (Exceptions from Verified History apply here as well.)✓PR approval mechanism of review + lgtm requires at least one member to approve. But PR authors could be non members and not strongly authenticated. api repo requires two approvals from TOC
6
Build requirements1234Status/Justification
7
Scripted buildAll build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script.✓✓✓✓Prow
8
Build serviceAll build steps ran using some build service, not on a developer’s workstation.✓✓✓Istio builds are built on Prow/GKE
9
Build as codeThe build definition and configuration is defined in source control and is executed by the build service.✓✓https://github.com/istio/release-builder/
10
Ephemeral environmentThe build service ensured that the build steps ran in an ephemeral environment, such as a container or VM, provisioned solely for this build, and not reused from a prior build.✓✓Builds run in containers
11
IsolatedThe build service ensured that the build steps ran in an isolated environment free of influence from other build instances, whether prior or concurrent.
12
ParameterlessThe build output cannot be affected by user parameters other than the build entry point and the top-level source location. In other words, the build is fully defined through the build script and nothing else.
13
HermeticAll transitive build steps, sources, and dependencies were fully declared up front with immutable references, and the build steps ran with no network access.🗙network access part needs to be clarified. https://github.com/istio/release-builder/blob/release-1.16/example/manifest.yaml seems to be downloading everything during buildtime
14
ReproducibleRe-running the build steps with identical input artifacts results in bit-for-bit identical output. Builds that cannot meet this MUST provide a justification why the build cannot be made reproducible.Need to test out
15
Provenance1234Status/Justification
16
AvailableThe provenance is available to the consumer in a format that the consumer accepts. The format SHOULD be in-toto SLSA Provenance, but another format MAY be used if both producer and consumer agree and it meets all the other requirements.🗙🗙🗙🗙No provenance info exists yet
17
AuthenticatedThe provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.
18
Service generatedThe data in the provenance MUST be obtained from the build service (either because the generator is the build service or because the provenance generator reads the data directly from the build service).
19
Non-falsifiableProvenance cannot be falsified by the build service’s users.
20
Dependencies completeProvenance records all build dependencies that were available while running the build steps.
21
Contents of Provenance1234Status/Justification
22
Identifies artifactThe provenance MUST identify the output artifact via at least one cryptographic hash. ✓✓✓✓SBoM provides data for final artifacts. Intermediates have no provenance metadata
23
Identifies builderThe provenance identifies the entity that performed the build and generated the provenance. This represents the entity that the consumer must trust.SBoM provides data for final artifacts. Intermediates have no provenance metadata
24
Identifies build instructionsThe provenance identifies the top-level instructions used to execute the build. The identified instructions SHOULD be at the highest level available to the build
25
Identifies source codeThe provenance identifies the repository origin(s) for the source code used in the build.git tag is in sbom
26
Identifies entry pointThe provenance identifies the “entry point” of the build definition (see build-as-code) used to drive the build including what source repo the configuration was read from.
27
Includes all build parametersThe provenance includes all build parameters under a user’s control. See Parameterless for details. (At L3, the parameters must be listed; at L4, they must be empty.)
28
Includes all transitive dependenciesThe provenance includes all transitive dependencies listed in Dependencies Complete.
29
Includes reproducible infoThe provenance includes a boolean indicating whether build is intended to be reproducible and, if so, all information necessary to reproduce the build. See Reproducible for more details.
30
Includes metadataThe provenance includes metadata to aid debugging and investigations. This SHOULD at least include start and end timestamps and a permalink to debug logs.
31
32
33
34
Mark tasks completed with✓
35
Mark tasks yet to be resolved with🗙
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100