Adoptium SLSA Levels

[jiekang]

This issue serves to document the SLSA criteria for Adoptium to meet. SLSA [1] is a secure software supply chain framework that defines four compliance levels [2] of increasing assurance.

Level 1

The build process must be fully scripted/automated and generate provenance.

• The Adoptium build process is fully scripted/automated and generates an SBOM for provenance.
• Work still needs to be done to add more information to the SBOM to meet provenance requirements

Level 2 Tamper resistance of the build service

Requires using version control and a hosted build service that generates authenticated provenance.

• The Adoptium build and infrastructure source code uses Git for version control and is hosted on Jenkins.

Level 3 Extra resistance to specific threats

The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively

• The Adoptium community is working to apply the SSDF standard that includes guaranteeing the auditability of the source and the integrity of the provenance

Level 4 Highest levels of confidence and trust

Requires two-person review of all changes and a hermetic, reproducible build process.

• Some of the Adoptium projects require two-person reviews for changes
• Work still needs to be done for a hermetic, reproducible build process

[1]
https://slsa.dev/

[2]
https://slsa.dev/spec/v0.1/levels

[sxa]

https://slsa.dev/spec/v0.1/requirements

Categories: Source, build, provenance, common (includes security of machines)

LEVEL 1: Documentation of build process (Unsigned provenance)

ACHIEVED AS WE HAVE SBOMs - POTENTIALLY MORE DETAIL TBD

• Fully scripted/automated and generate provenance e.g. SBOMs

LEVEL 2: Tamper resistance of bld svc (Hosted source/build, signed provenance)

Achieved now that we have GPG signing

Prevents tampering as build service is trusted

• Version controlled
• Uses a build service
• Authenticated provenance (PGP verification)
• Service generated (Signatures generated within jenkins)

LEVEL 3: Extra resistance to threats (Security controls on host, non-falsifiable provenance)

Mostly done - ephermeral environment certainly covered by docker containers, although they are routed via dockerhub

• Verified history - 2FA, who made changes and when etc. in last 18 months
• Build as code
• (SOME) Ephemeral environment (Don't re-use build end, so e.g. docker and no ccache)
• Isolated (Bld cannot access signing key)
  • Build caches, if used, MUST be purely content-addressable to prevent tampering.
• (pipeline PRs?) Non-falsifiable (Keys never accessible to user-defined build steps)

LEVEL 4: Highest level of confidence+trust (Two party reviews + hermetic builds)

Allows reproducibility

• Two person reviews (Not for all repositories yet)
• Parameterless (Yes if you include pipeline scripts) NO NON-DEFAULTS ALLOWED. Release flag?
• [ ]Hermetic
  • Deps declared up front and verified provenance
  • build runs without requiring network access
• Reproducible (?) Or justification as to why it can't be
• Security (Possibly https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf)
• Access (Rare, logged, gated behind approvals)
• Superusers (Small number of admins can override. Must require approval of second admin)
• Dependencies Complete (SBOM)

[sxa]

Ref: https://slsa.dev/blog/2023/02/slsa-v1-rc

SLSA 1.0RC has introduced the concept of "tracks" to make it easier to claim incremental progress. So far the build track has been defined with levels 1-3 which broadly map to 1-3 of the earlier specification version. A build level 4 and source track are expected to follow. Note that the specific wording around ephemeral build environments is no longer present, although the "prevent runs from influencing one another" is still present.

[sxa]

SLSA1.0 is now finalised and has removed some of the more complex requirements such as hermetic builds which were not simple for people to implement. It has also been split into "tracks" for which the only one included in 1.0 is the Build track which currently has three levels (excluding Level zero which is "nothing") with a fourth planned for the future, so there are fewer levels to meet than we had before:

LEVEL 1: Provenance showing how the package was built (Focus on mistakes & documentation)

Package has provenance showing how it was built. Can be used to prevent mistakes but is trivial to bypass or forge.

• Software producer follows a consistent build process so that others can form expectations about what a 'correct' build looks like
• Build platform automatically generated provenance describing how the artifact was built including: what entity built the package, what build process they used, and what the top level input to the build were. (RECOMMENDED predicate for this)
• Software producer distributes provenance to consumers preferable using a convention determined by the package ecosystem. (For tarballs etc. it's in the same github release for us)

LEVEL 2: Signed provenance, generated by a hosted build platform (Focus on preventing tampering after the build)

Forging the provenance or evading verification requires an explicit “attack”, though this may be easy to perform. Deters unsophisticated adversaries or those who face legal or financial risk.

• The build runs on a hosted build platform that generates and signs1 the provenance itself. This may be the original build, an after-the-fact reproducible build, or some equivalent platform that ensures the trustworthiness of the provenance.
• Downstream verification of provenance includes validating the authenticity of the provenance. (See comments later)

LEVEL 3: Hardened build platform (Focus on preventing Tampering during the build)

Forging the provenance or evading verification requires exploiting a vulnerability that is beyond the capabilities of most adversaries. In practice, this means that builds run on a hardened build platform that offers strong tamper protection.

Build platform implements strong controls to:

• prevent runs from influencing one another, even within the same project. (Done for Linux, not necessarily for other platforms)
• prevent secret material used to sign the provenance from being accessible to the user-defined build steps.

We likely meet all of these for our Linux platforms built in docker containers now, although we will need to look in more detail at the provenance requirements. At the moment we do not explicitly record "what entity built the product" We should probably add verification of the provenance by checking the signing after it is pushed to github, perhaps initially by the publish job, but later through a subsequent job that pulls from the API

[sxa]

Downstream verification of provenance is being done under adoptium/temurin-build#3484

[sxa]

From discussion with @netomi today we identified a few potential omissions from the SBOM which we should seek to correct prior to claiming SLSA Build L3 (also captured in the issue mentioned above)

• Reference required to the release artifacts in the SBOM (From previous discussion)
• Add information about the build job that generated the artifacts
• Add details of the build system Done for Linux, not for others, although we can add in the SHA of the latest playbook run from the system logs
• Capture additional tool details - This should include things like CycloneDX download SHAs which are executed within the build environment.

[sxa]

The above have all been completed and after discussions with @netomi and @mbarbero we have agreed that we are now good to go.

Actions required:

• Update the badge on the Temurin project page
• Update https://adoptium.net/docs/slsa with the V1.0 details and the platform limitations related to claiming build L3
• Complete a "point in time" blog post about the level.

[jiekang]

@sxa What else is on the horizon for this issue? Can it be closed as done (with new issues for new tasks)?

[sxa]

@sxa What else is on the horizon for this issue? Can it be closed as done (with new issues for new tasks)?

Windows SLSA3 support would be the obvious current omission. Nothing in this issue restricted it to particular platforms :-)

Ideally Windows can be dealt with under the investigations and solution to adoptium/infrastructure#3286. I'd prefer to have the primary platforms at the same level if possible before closing this.