Eclipse Temurin Is SLSA Level Two-Compliant

The SLSA framework is important in software development: it fills a gap in cybersecurity guidance and ensures consumers can be confident that the software they’re using hasn’t been tampered with. As open source has become an increasingly dominant force in software development, meeting SLSA framework requirements and achieving higher levels of compliance has also become increasingly relevant. We’ve noted in previous articles the importance of software supply chain security to the Eclipse Foundation, and how SLSA plays an important role in it.

Eclipse Adoptium has been working on SLSA compliance for the Eclipse Temurin project for some time. As of now, Temurin meets levels 1 and 2 of the SLSA v0.1 specification.

Level One Compliances Requires a Fully Scripted and Automated Build Process

Eclipse Temurin has been compliant with level 1 of the SLSA specification for some time. There are two components of level 1 compliance. 

The first requirement is for a fully scripted and automated build process. Our build steps are completely defined by the Jenkins pipelines from the ci-jenkins-pipelines repository and the underlying scripts run on the build machines from the temurin-build repository.

The second requirement is that provenance must be available to consumers of the software in a format they accept. In our case, that means producing and distributing Software Bill of Material (SBOM) documents, which are shipped alongside release builds. To do that, we create an SBOM in OWASP CycloneDX format along with releases that contain all the information about how the builds are produced, which should allow someone to rebuild them if necessary. This includes the:

• Full set of parameters that we use for the makejdk_any_platform.sh script
• Source repository tags (scmRef) that were used by the build process to produce the builds
• Output from the openjdk configure invocation, and various other pieces of information

We are continually evolving the specific details that we include in the SBOM. If you want to join in the discussion on the content, you can find the conversation in temurin-build#3013 or talk to us in the #secure-dev slack channel in the Adoptium workspace. 

Level Two Requires Tamper Resistance

The next level of SLSA compliance requires the addition of tamper resistance to the build process, including version-control for all the code. We achieve this through our use of GitHub for both the OpenJDK product code and the code that runs the build and distribution processes through our Jenkins CI server. These requirements are cumulative with the level 1 requirements.

Here’s how our level 2 compliances break down:

• All our source code is stored in GitHub in the jdkXX repositories, such as jdk17u, which we mirror from the openjdk project. These are version-controlled and have tags for each release that we build from. Contributors are required to agree to the rules of the Eclipse Contributor Agreement (ECA).

• All of the build steps are run using our Jenkins build service (https://ci.adoptopenjdk.net), which is used to perform the builds, generate the SBOMs, and build the installers where applicable. The outputs are then posted into GitHub release repositories. These are named as temurinXX-binaries (e.g. temurin17-binaries) and are also exposed via our API and website. 

• We sign the SBOMs for the latest set of releases to guarantee their authenticity. 

• The GPG signatures for the binary are generated as an integral part of the build process for the binaries and will be done in the same way for the signing of the SBOMs — the current SBOM signing was done retroactively in our Jenkins instance. The Jenkins instance hosts the private keys from the Eclipse Foundation, which are used to perform the signature generation. 

Work Continues for Higher Levels of Compliance

Are we finished? Absolutely not! We are continuing to work towards achieving higher levels of SLSA and have already achieved many of the requirements of those higher levels. But for now, we are proud to be able to claim full compliance with SLSA level 2. 

Meanwhile, we are tracking our progress towards meeting the higher level requirements at adoptium#160. We already meet some of them, though in some cases there are differences in the criteria which we meet on different platforms. For example, we have worked to make our build process reproducible and on Linux, Windows, and MacOS. We are able to produce binary reproducible builds for JDK19+, except for some instances where the class data sharing archive is not identical. 

We are also working towards implementing the other parts of the higher SLSA levels which we do not yet meet. Some of these, such as the Ephemeral environment requirement, may take some time to achieve on all platforms. 

You can follow the current status in the SLSA tracking issue or on the SLSA page on our website.