This page covers the detailed technical requirements for producing artifacts at each SLSA level. The intended audience is platform implementers and security engineers.
For an informative description of the levels intended for all audiences, see Levels. For background, see Terminology. To better understand the reasoning behind the requirements, see Threats and mitigations.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
In order to produce artifacts with a specific build level, responsibility is split between the Producer and Build platform. The build platform MUST strengthen the security controls in order to achieve a specific level while the producer MUST choose and adopt a build platform capable of achieving a desired build level, implementing any controls as specified by the chosen platform.
|Producer||Choose an appropriate build platform||✓||✓||✓|
|Follow a consistent build process||✓||✓||✓|
|Build platform||Provenance generation||Exists||✓||✓||✓|
Security Best Practices
While the exact definition of what constitutes a secure platform is beyond the scope of this specification, all implementations MUST use industry security best practices to be conformant to this specification. This includes, but is not limited to, using proper access controls, securing communications, implementing proper management of cryptographic secrets, doing frequent updates, and promptly fixing known vulnerabilities.
Various relevant standards and guides can be consulted for that matter such as the CIS Critical Security Controls.
A package’s producer is the organization that owns and releases the software. It might be an open-source project, a company, a team within a company, or even an individual.
NOTE: There were more requirements for producers in the initial draft version (v0.1) which impacted how a package can be built. These were removed in the v1.0 specification and will be reassessed and re-added as indicated in the future directions.
Choose an appropriate build platform
The producer MUST select a build platform that is capable of reaching their desired SLSA Build Level.
For example, if a producer wishes to produce a Build Level 3 artifact, they MUST choose a builder capable of producing Build Level 3 provenance.
Follow a consistent build process
The producer MUST build their artifact in a consistent manner such that verifiers can form expectations about the build process. In some implementations, the producer MAY provide explicit metadata to a verifier about their build process. In others, the verifier will form their expectations implicitly (e.g. trust on first use).
If a producer wishes to distribute their artifact through a package ecosystem that requires explicit metadata about the build process in the form of a configuration file, the producer MUST complete the configuration file and keep it up to date. This metadata might include information related to the artifact’s source repository and build parameters.
The producer MUST distribute provenance to artifact consumers. The producer MAY delegate this responsibility to the package ecosystem, provided that the package ecosystem is capable of distributing provenance.
A package’s build platform is the infrastructure used to transform the software from source to package. This includes the transitive closure of all hardware, software, persons, and organizations that can influence the build. A build platform is often a hosted, multi-tenant build service, but it could be a system of multiple independent rebuilders, a special-purpose build platform used by a single software project, or even an individual’s workstation. Ideally, one build platform is used by many different software packages so that consumers can minimize the number of trusted platforms. For more background, see Build Model.
The build platform is responsible for generating provenance describing how the package was produced.
The SLSA Build level describes the overall provenance integrity according to minimum requirements on its:
- Completeness: What information is contained in the provenance?
- Authenticity: How strongly can the provenance be tied back to the builder?
- Accuracy: How resistant is the provenance generation to tampering within the build process?
The build process MUST generate provenance that unambiguously identifies the output package by cryptographic digest and describes how that package was produced. The format MUST be acceptable to the package ecosystem and/or consumer.
It is RECOMMENDED to use the SLSA Provenance format and associated suite because it is designed to be interoperable, universal, and unambiguous when used for SLSA. See that format’s documentation for requirements and implementation guidelines.
If using an alternate format, it MUST contain the equivalent information as SLSA Provenance at each level and SHOULD be bi-directionally translatable to SLSA Provenance.
|Provenance is Authentic||
Authenticity: Consumers MUST be able to validate the authenticity of the provenance attestation in order to:
This SHOULD be through a digital signature from a private key accessible only to the build platform component that generated the provenance attestation.
While many constraints affect choice of signing methodologies, it is RECOMMENDED that build platforms use signing methodologies which improve the ability to detect and remediate key compromise, such as methods which rely on transparency logs or, when transparency isn’t appropriate, time stamping services.
Authenticity allows the consumer to trust the contents of the provenance attestation, such as the identity of the build platform.
Accuracy: The provenance MUST be generated by the control plane (i.e. within the trust boundary identified in the provenance) and not by a tenant of the build platform (i.e. outside the trust boundary), except as noted below.
Completeness: SHOULD be complete.
|Provenance is Unforgeable||
Accuracy: Provenance MUST be strongly resistant to forgery by tenants.
Completeness: SHOULD be complete.
Note: This requirement was called “non-falsifiable” in the initial draft version (v0.1).
The build platform is responsible for isolating between builds, even within the same tenant project. In other words, how strong of a guarantee do we have that the build really executed correctly, without external influence?
The SLSA Build level describes the minimum bar for isolation strength. For more information on assessing a build platform’s isolation strength, see Verifying build platforms.
All build steps ran using a hosted build platform on shared or dedicated infrastructure, not on an individual’s workstation.
Examples: GitHub Actions, Google Cloud Build, Travis CI.
The build platform ensured that the build steps ran in an isolated environment, free of unintended external influence. In other words, any external influence on the build was specifically requested by the build itself. This MUST hold true even between builds within the same tenant project.
The build platform MUST guarantee the following:
There are no sub-requirements on the build itself. Build L3 is limited to ensuring that a well-intentioned build runs securely. It does not require that a build platform prevents a producer from performing a risky or insecure build. In particular, the “Isolated” requirement does not prohibit a build from calling out to a remote execution service or a “self-hosted runner” that is outside the trust boundary of the build platform.
NOTE: This requirement was split into “Isolated” and “Ephemeral Environment” in the initial draft version (v0.1).
NOTE: This requirement is not to be confused with “Hermetic”, which roughly means that the build ran with no network access. Such a requirement requires substantial changes to both the build platform and each individual build, and is considered in the future directions.