Eclipse Temurin Is Enhancing Supply Chain Security With SLSA Build Level 3 Compliance

Supply chain security is table stakes in many industries. In automotive manufacturing, for example, it’s simply a given that manufacturers know where all the parts they’re using came from, how they were tested, and that they won’t fail because of some flaw in their construction. 

The software industry isn’t there yet, but it’s well on its way. Cybersecurity is a dynamic and changing landscape. Cyber resilience and recovery have become a significant part of the conversation, as industries have to plan for the eventuality of a security breach. And the software supply chain has become an important target both for attack and defence. The attack on SolarWinds in 2020 was just one of many that year that showed how vulnerable the supply chain truly is, and how much is at stake if the supply chain is compromised.

We’re pleased to announce that the Eclipse Foundation has taken a significant step forward in that regard. The Eclipse Temurin project just recently achieved compliance level three with the Supply-chain Levels for Software Artifacts (SLSA) framework for its builds, the highest currently available. 

Temurin Was a Logical Starting Point to Enhance Security

This has been a long and ongoing process for the Eclipse Temurin project. The Eclipse Foundation has had its eye on SLSA compliance for its projects for a while. There was some consideration for the Secure Software Development Framework (SSDF) early on, but the Eclipse Foundation ultimately chose to focus on SLSA for its clearer requirements and more in-depth specification. We are progressing activities related to SSDF, however.

This was part of an effort to demonstrate the Eclipse Foundation’s leading role among open source organisations in doing the work necessary to secure its development process. Being able to demonstrate that is becoming increasingly important in the software industry. 

And because Temurin is the project building distribution of the upstream OpenJDK project, we were a logical starting place. Tons of developers use Java, so ensuring the runtime at the bottom of the stack is secure is crucial, otherwise everything else is at risk. And, vice versa, if the runtime is secure, then you can swap out an application higher up in the stack if needed. 

It’s also worth mentioning that the Eclipse Temurin project probably wasn’t the easiest project to reach SLSA level three. It’s a mix of Java and C code, and it’s built on a number of different platforms. But that makes Temurin a really good test case: if we did it, other projects should be able to do it. 

Level Three Makes the Whole Temurin Supply Chain Secure

Build Level 1 of SLSA compliance is fairly basic and straightforward and is mostly about making sure software consumers know what they’re getting. To be precise, your build process must be fully automated or scripted, and it must generate provenance or metadata about how an artifact was built. This includes the build process, top-level source, and any dependencies. 

The second level is more involved. This step requires using version control as well as a hosted build service that can generate authenticated provenances. In essence, it’s about making sure you have the right processes in place around your code, such as where it’s being stored (a Jenkins instance for Eclipse Temurin), as well as providing for the ability to prevent or at least detect tampering after the build. After all, if you aren’t aware of any tampering, it’s hard to correct.

Level three is definitely the most involved. It’s all about making sure you know everything that went into your code and how you built it. Crucially, this means being able to guarantee that anything you didn’t intend to be in there isn’t there, including preventing build runs from influencing one another. But with it in place, we can have confidence that we know what has gone into any of the runtimes coming out of the Eclipse Temurin project and that we can identify those components.

Level Three Is About Preventing Tampering During Build Process

Broadly speaking, there were three major components to achieving level three SLSA compliance. 

The first was that we had to ensure that build runs couldn’t influence one another. Each build run needs to be fully independent, with nothing cached. We achieved that for Linux and MacOS in two different ways. For Linux, we perform all our build runs in Docker containers that are spun up for each build, and shut down once its’s complete. For MacOS, we use MacStadium’s Orka to spin up virtual machines for each build run. In either case, while the method is different, the effect is the same: the machine has a clean birth, is created fresh for each build, and only lasts the length of the build. 

The second step was to ensure we could verify the provenance of software artifacts. Something that was very helpful, though not strictly necessary to that process, was enhancing the Software Bill of Materials (SBoM), which brings together all the ingredients included in the runtime. We already had a basic SBoM in 2022, but we enhanced it to make it suitable for SLSA Level 3. We also created a build verification step that checks the features of the build against the SBoM to ensure they align and that the fields are valid. You can download the current SBoM via the Adoptium API.

Every build is also verified to ensure it has all the features enabled that it should, using a custom AQA test job called smoke tests. 

Finally, we had to ensure user-defined build steps couldn’t access the secret materials to sign the provenance. To avoid that, we contain all the signing jobs within our Jenkins CI system. This way, they exist separate from the build jobs. And we only run the signing jobs after a build job is complete. 

Work Is Ongoing to Further Enhance Supply Chain Security

One small wrinkle in the process was that SLSA had its first v1.0 release in April 2023, just a few short months after we’d completed step two and started on step three. That changed the requirements in the process, adding some but removing others. But the main takeaway is that it expanded the scope of SLSA and broke it into different tracks, the only one of which that is currently defined is the build track. We’ve achieved SLSA level three for the build track, but the expectation is that there will be a level four and that the other tracks will be defined in the future. Both are goals for the project. 

We’re also looking to add support for creating those sterile build run environments for the Windows platform. Obviously, this is one of the most popular platforms out there, but just as it did for Linux and MacOS, it’ll take some doing to make it work. 

The important thing for the community to understand is that software supply chain exploits are no longer theoretical. These are real and relevant issues in the software industry, and while securing your supply chain may not be business-as-usual just yet, it soon will be. If you haven’t thought about how you’re doing that, now’s the time. 

Help Enhance Supply Chain Security by Helping Eclipse Temurin

Of course, there’s more work going on with Eclipse Temurin than simply meeting SLSA qualifications. If that interests you, all our builds are fully reproducible, so feel free to test our SLSA qualification for yourself. 

Apart from other work we’re doing around more secure development processes, there’s plenty going on with Temurin itself. 

If you’re interested in getting involved, consider checking out either the Slack channel or our website.