ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Supply chain Levels for Software Artifacts (SLSA)SLSA LEVELNIST SSDF v1.1AdditionalNIST 800-53r5EO14028NIST SP800-161r1CNCF
2
Source RequirementDescription1234
3
Version controlledEvery change to the source is tracked in a version control system that meets the following requirements
- [Change history]
- [Immutable reference]		O✓✓✓NIST SSDF PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

PS.1.1: Store all forms of code – including source
code, executable code, and configuration-as-code –
based on the principle of least privilege so that only
authorized personnel, tools, services, etc. have
access.
PW.4.1: Acquire and maintain well-secured software
components (e.g., software libraries, modules,
middleware, frameworks) from commercial, opensource, and other third-party developers for use by the
organization’s software.		SA-10, SA-15, SA-15(11), SR-4 PROVENANCE Control: Document, monitor, and maintain valid provenance of the following systems, system components, and associated data4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code
4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
4e(ix): attesting to conformity with secure software development practices;
4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.		SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
4
Verified historyEvery change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp.It must be clear which identities were verified, and those identities must use two-step verification or similar.✓✓PS.1.1: Store all forms of code – including source
code, executable code, and configuration-as-code –
based on the principle of least privilege so that only
authorized personnel, tools, services, etc. have
access.
PS.3.1: Securely archive the necessary files and
supporting data (e.g., integrity verification information,
provenance data) to be retained for each software
release.

PW.4.1: Acquire and maintain well-secured software
components (e.g., software libraries, modules,
middleware, frameworks) from commercial, opensource, and other third-party developers for use by the
organization’s software.		SA-8

SR-4 PROVENANCE
Control: Document, monitor, and maintain valid provenance of the following systems, system
components, and associated data

Discussion: "....document any changes to the provenance,"		4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code
4e(ix): attesting to conformity with secure software development practices;
4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.		SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC
5
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.
- [Immutable history]
- [Limited retention for SLSA 3]		18 mo✓NIST SSDF PS.3.1: Securely archive the necessary files and
supporting data (e.g., integrity verification information,
provenance data) to be retained for each software
release.

PS.1.1: Store all forms of code – including source
code, executable code, and configuration-as-code –
based on the principle of least privilege so that only
authorized personnel, tools, services, etc. have
access.

NIST SSDF - (PO.3): PO.3.3 - Example 3: Establish and enforce security and retention policies for artifact data.		AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
6
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.)✓NIST SSDF PW.7.1: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.

PW.7.2: : Perform the code review and/or code analysis
based on the organization’s secure coding standards,
and record and triage all discovered issues and
recommended remediations in the development
team’s workflow or issue tracking system.		SA-114e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;
4e(ix): attesting to conformity with secure software development practices;		AC-(5): The enterprise should ensure that an appropriate separation of duties is
established for decisions that require the acquisition of both information system and supply chain
components
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
7
Build requirements1234
8
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.✓✓✓✓NIST SSDF PO3.1 Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.

PW.6.1: Use compiler, interpreter, and build tools that
offer features to improve executable security.

PW6.2: Determine which compiler, interpreter, and
build tool features should be used and how each
should be configured, then implement and use the
approved configurations.

PO 3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.		SA-154e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code
4e(ix): attesting to conformity with secure software development practices;		SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLCCloud Native Computing Foundation: Supply Chain Best Practices : Securing Materials—Verification; Securing Build Pipelines—Verification, Automation, Secure Authentication/Access; Securing Artefacts—Verification; Securing Deployments—Verification
9
Build serviceAll build steps ran using some build service, not on a developer’s workstation.✓✓✓NIST SSDF PO3.2 : Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

PW.6.1: Use compiler, interpreter, and build tools that
offer features to improve executable security.

PW6.2: Determine which compiler, interpreter, and
build tool features should be used and how each
should be configured, then implement and use the
approved configurations.		SA-154e(i)(F): secure software development environments- monitoring operations and alerts and responding to attempted and actual cyber incidents
4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section
4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code
4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated
4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis
4e(ix): attesting to conformity with secure software development practices		SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLCCNCFSSCP: Securing Build Pipelines—Verification, Automation, Controlled Environments,
Secure Authentication/Access; Securing Artefacts—Verification, Automation, Controlled
Environments, Encryption; Securing Deployments—Verification, Automation
10
Build as codeThe build definition and configuration is defined in source control and is executed by the build service.✓✓NIST SSDF PO3.3 Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.SA-154e(i)(F): secure software development environments- monitoring operations and alerts and responding to attempted and actual cyber incidents
4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section
4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated
4e(ix): attesting to conformity with secure software development practices		AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC		CNCFSSCP: Securing Build Pipelines—Verification, Automation, Controlled Environments;
Securing Artefacts—Verification
11
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.✓✓NIST SSDF PO4.1 Define criteria for software security checks and track throughout the SDLC.

PO 5.1 Separate and protect each environment involved in software development.		SA-15, SA-15(1)
4e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release
4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated
4e(ix): attesting to conformity with secure software development practices		"AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC"
12
IsolatedThe build service ensured that the build steps ran in an isolated environment free of influence from other build instances, whether prior or concurrent.✓✓NIST SSDF PO5.1: Separate and protect each environment involved in software development.

PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.
PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security.
PW 6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.		 SA-3(1), SA-8, SA-15 4e(i): secure software development environments:
(A) using administratively separate build environments;
(B) auditing trust relationships;
(C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents;
, 4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section
4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code)
4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated
4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis
4e(ix): attesting to conformity with secure software development practices		"AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC"		CNCFSSCP: Securing Build Pipelines—Controlled Environments
13
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.✓NIST SSDF PW6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.

PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

PW6.1 Use compiler, interpreter, and build tools that offer features to improve executable security.		 SA-15, SR-94e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release
4e(ix): attesting to conformity with secure software development practices"		AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC		CNCFSSCP: Securing Build Pipelines—Verification, Automation
14
HermeticAll transitive build steps, sources, and dependencies were fully declared up front with immutable references, and the build steps ran with no network access.✓NIST SSDF PW.6.2: Determine which compiler, interpreter, and
build tool features should be used and how each
should be configured, then implement and use the
approved configurations.

PO 3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

PO 5.1 Separate and protect each environment involved in software development.

PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security.		AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
15
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.ONIST SSDF PW.6.2: Determine which compiler, interpreter, and
build tool features should be used and how each
should be configured, then implement and use the
approved configurations.

PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security.		AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and
facilitates the accuracy of provenance
AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY
This enhancement validates the relationship of provenance and a
component within the supply chain. Therefore, it ensures integrity of provenance.
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
16
Provenance1234
17
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.✓✓✓✓NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

PO 4.1 Define criteria for software security checks and track throughout the SDLC.

PS 2.1 Make software integrity verification information available to software acquirers.

PS 3.1 Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
NTIASBOM: All CNCFSSCP: Securing Materials—Verification, Automation SCTPC: MAINTAIN3SA-8, SR-3, SR-44e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
4e(ix): attesting to conformity with secure software development practices;
4e(vii): providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.		AU(3): The audit records of a supply chain event should be securely handled
and maintained in a manner that conforms to record retention requirements and preserves the integrity of
the findings and the confidentiality of the record information and its sources as appropriate
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC		CNCFSSCP: Securing Materials—Verification, Automation SCTPC: MAINTAIN3
18
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.✓✓✓NIST SSDF PS.2.1: Make software integrity verification information
available to software acquirers

PO 4.1 Define criteria for software security checks and track throughout the SDLC.

PS 2.1 Make software integrity verification information available to software acquirers.		AU(3): The audit records of a supply chain event should be securely handled
and maintained in a manner that conforms to record retention requirements and preserves the integrity of
the findings and the confidentiality of the record information and its sources as appropriate
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
CM(14): Enterprises should verify that the acquired hardware and software
components are genuine and valid by using digitally signed components from trusted certificate authorities
19
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).✓✓✓NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

PS 2.1 Make software integrity verification information available to software acquirers.		Dept of Commerce Minimum Elements for an SBOMSR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC
20
Non-falsifiableProvenance cannot be falsified by the build service’s users.✓✓NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).


PS 2.1 Make software integrity verification information available to software acquirers.		NTIA SBOM collection of materialsAU(3): The audit records of a supply chain event should be securely handled
and maintained in a manner that conforms to record retention requirements and preserves the integrity of
the findings and the confidentiality of the record information and its sources as appropriate
SR-4: Provenance should be documented for systems, system components, and
associated data throughout the SDLC
21
Dependencies completeProvenance records all build dependencies that were available while running the build steps.✓NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

PO 4.1 Define criteria for software security checks and track throughout the SDLC.

PS 2.1 Make software integrity verification information available to software acquirers.		SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC
22
Common requirements1234
23
SecurityThe system meets some TBD baseline security standard to prevent compromise. (Patching, vulnerability scanning, user isolation, transport security, secure boot, machine identity, etc. Perhaps NIST 800-53 or a subset thereof.)✓NIST SSDF PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. (SSDF uses major vulnerability, significant vulnerability, residual vulnerability, risk based approach text

NIST SSDF PW.4.4 Example 5: Determine a plan of action for each software component that is no longer being maintained or will not be available in the near future.

PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

PO 5.1 Separate and protect each environment involved in software development.

PO 5.2 Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.

PS 3.1 Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

PW 6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.
AT-3, CP-2, CP-3, CP-8, CP-9, IR-3, IR-4, PL-2, PM-14, SR-2.SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC

RA-5 VULNERABILITY MONITORING AND SCANNING

RA-3 RISK ASSESSMENT
24
AccessAll physical and remote access must be rare, logged, and gated behind multi-party approval.✓NIST SSDF PO.3.2 Example 6: Continuously monitor tools and tool logs for potential operational and security issues, including policy violations and anomalous behavior.

NIST SSDF PO 5.1 Example 4: Minimize direct human access to toolchain systems, such as build services. Continuously monitor and audit all access attempts and all use of privileged access.

NIST SSDF PO 5.1 Example 9: Continuously monitor all software deployed in each environment for new vulnerabilities, and respond to vulnerabilities appropriately following a risk-based approach.

NIST SSDF PO 5.2 Example 3: Continuously monitor the security posture of all development endpoints, including monitoring and auditing all use of privileged access		CM-5 ACCESS RESTRICTIONS FOR CHANGE Control: Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC
25
SuperusersOnly a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin.✓PO 5.2 Example 2: Configure each development endpoint and the development resources to provide the least functionality needed by users and services and to enforce the principle of least privilege.

PS 1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.		SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100