Securing Java for the Community

Introduction

Eclipse Adoptium is securing Java for the community.  This is a journey and it is important to establish that the title says “securing” not “secured”.  We are in unprecedented times where there is pressure on all software developers to secure the software supply chain due in part to an increasing wave of creative software attacks and also with new mandates to protect against the growing threat of attacks.

To restate what everyone already knows, Java is everywhere.  Java is the “write once, run everywhere” language.  It continues to share its position in the list with a handful of other top programming languages and arguably is the most pervasive choice for enterprise software for many reasons, including its stability, portability, ease of learning, affordability and community support.  

This post covers our motivation at Eclipse Adoptium and shares the steps we have taken as well as our next steps in the secure software development journey.  It is also a call to the community for feedback, input and action to join the on-going effort to ensure Java is the safest and most trusted choice for enterprise software.

Large Install Base

Eclipse Temurin is the Adoptium distribution of OpenJDK.  You may know it by its former name, AdoptOpenJDK.  It is the most popular distribution of OpenJDK in production and with that comes a great sense of responsibility.  So, given the Temurin distribution is everywhere, running banking software on mainframe servers, on millions of phones, in the software in your car or your beer fridge, we arrive at one of our fundamental needs and motivation. 

Ensure Temurin is secure in order to secure the world around us.  We want to protect our consumers from someone hacking into their fridges resulting in tepid beer (which will serve as a running analogy, as you can extrapolate, of any other critical infrastructure attacks).

False Sense of Security

So, we are all now duly scared.  No one wants room-temperature beer. 

Does this drive everyone away from open-source software?  The answer is no, instead of the old model of trusting a vendor to build a secure thing behind its veiled corporate wall, the world has changed.  Open and transparent development using a model that comes with ways to verify the output continues to be the preferred direction of travel.  Philosophically, instead of trying to figure out how to trust, the world is figuring out how to ‘trust but verify’.

Secure Development Activities

How we started

Knowing all of this, our efforts at Adoptium started years ago and are now ramping up at a more rapid pace.  Some of our visible efforts began as an Outreachy project called Project RASPberry, to improve the Reproducibility, Auditability, Security, and Presentability (RASP) of our product builds through enhancing our approach to tracking dependencies and the automated creation of a Software Bill of Materials (SBOM) as part of our build process.  This work also led us to further engage with different security experts, get involved in the OWASP CycloneDX community and learn by doing.

Guidelines for Secure Software Development

There are plenty of resources to help projects and organizations on this journey.  When we began, we assessed many existing security frameworks available and selected the Secure Software Development Framework (SSDF), the US government based NIST framework as a model to follow, since it outlined a thorough and rigorous set of criteria to ensure secure software development.  We have also added the Supply-chain Levels for Software Artifacts (SLSA) framework to our toolkit.  While we have covered these frameworks in other posts and presentations, it is useful to summarize them here.

SSDF

The checklist provided by the SSDF framework encompasses many activities that we had already done, or have initiated at the project.  Much of the effort at Adoptium, under this tracker issue, includes assessment, documentation and identifying whether there are any gaps that we need to fill. 

SSDF practices are divided into 4 groups.

These SSDF practices and our effort to ensure we meet all of the criteria further stabilizes our project and is a step along our path of continuously improving how we build, test, and deliver software.

SLSA

When we began our work and assessed frameworks, SLSA v0.1 was available.  Since that initial assessment, SLSA v0.2 has arrived and the Eclipse Foundation has selected SLSA to guide Eclipse projects in Software Supply Chain best practices. Given this, we additionally utilize the SLSA framework to guide our efforts and rate our progress.

At the time of writing, Temurin is at SLSA Level 2 and marching quickly towards the SLSA Level 3 badge.

SBOMs

Both SSDF and SLSA require the collection, safeguarding, maintenance, and sharing of provenance data in the form of a software bill of materials (SBOM).  An SBOM is a complete, formally structured list of components, libraries and modules that are required to build a given piece of software and the supply chain relationships between them.  That is the long way of saying that an SBOM is a list of ingredients.

As per the helpful SBOM explainer video from NTIAGov, the list of ingredients needs to include the atomic parts.  In their granola bar example, compound parts like caramel are broken into atomic components like cream and sugar.

For our Temurin builds of OpenJDK, we currently produce and offer up SBOMs with both our general availability builds and our nightly early access builds.  We are in the process of refining the contents of our SBOMs, to ensure that we break all compound parts down into the atomic parts.

SBOMs contain the list of ingredients, those atomic parts that went into producing the binary and help answer many questions that consumers may have about their supply chain.  When used to scan for vulnerabilities in the security context, they help answer the question “Am I at risk?”.  Used informationally for dependency tracking and identifying most used components, they could help answer “Do I invest?” or “Do I change suppliers?”.  For the reproducibility use case, where we want to use the SBOM not just as a list of ingredients, but also as a recipe for reproducible builds, the question answered might be “Can I accurately reproduce this build?”.

Reproducible Builds

Remember that promise of ‘trust but verify’?  Reproducible builds are the ‘verify’ piece.  Of course, you can just ‘trust us’ when we say that the contents of the SBOM accurately describe the binary you just downloaded, but it would be even better if you and others could verify it for yourselves.  

Why is it the mechanism for providing ‘evidence’?

The Adoptium releases can be rebuilt within multiple secure environments each with stringent bill of material checks, and then the binaries compared to ensure byte for byte identical output. If the builds from the multiple secure environments are identical to the one from the open-source projects, the likelihood of malicious tampering would be extremely low.

Reproducible Builds at Eclipse Adoptium Andrew Leonard

The Adoptium project has done extensive work to find and resolve non-deterministic code and processes and push changes upstream to the OpenJDK project.  Through this effort, and with Temurin’s supporting changes to build scripts, reproducible builds are now possible in JDK 19+ and back-ported to JDK 17.

More enhancements are underway for verifying and rating reproducible builds and to improve the tooling at the project.  We want to accommodate industry adoption of the ‘trust but verify’ model.

SBOM refinements

Depth

As mentioned, we are currently working on refining our SBOM contents, ensuring that all atomic parts are included in this provenance data.  What this means in practice is that we are running the strace tool to see everything that touches the final product during production, and ensuring it is all accounted for in the SBOM.  The goal is to have all atomic components with all transitive dependencies and known-unknowns declared.

Specification Updates

Specifications are evolving quickly.  In the first incarnation of our automated SBOM generation, the CycloneDX specification did not support a type that was quite suitable to describe components of runtime environments, like Temurin.  We started off as type:application, currently are type:framework, and in CycloneDX v1.5, we may shift to type:platform.  In order to progress, we will choose to work with the CycloneDX team and supply the best options we have at the time.

"component" : {
      "name" : "Eclipse Temurin",
      "version" : "17.0.4.1+1",
      "description" : "Temurin JDK Component",
      "type" : "framework"
    },

We are now providing feedback on the proposed CycloneDX formulation enhancement, which offers a way to describe more than the list of ingredients, but how to assemble them into a recipe.  These updates are expected to be available later in 2023.

VEX

While working on the automated creation of release notes, the question arose around how to capture the list of Common Vulnerabilities and Exposures (CVEs) fixes that are in the product being released and also, how can we share this information in a useful manner to the community.  In the course of that discussion, we identified the Vulnerability Exploitability Exchange (VEX) which is a part of CycloneDX specification.

We plan to explore generating a VEX BOM that can be linked from the Temurin SBOM.  This deep-linking capability supported by CycloneDX is referred to as BOM-Link and promises to be an adaptable approach to communicating on security advisories.  This may facilitate better automation for consumers when they want to verify vulnerabilities and patches.

Use Case Documentation

We will be developing documentation and common user stories for sharing.  One example for developers may be when they are creating and shipping an application that may contain Temurin, like a native image created with jlink.

Call for Participation from the Community

We would love to hear what you are doing to secure your software supply chains.

What challenges are you facing that we should understand better in order to be more useful and relevant?

Even while we are refining the contents of the Temurin SBOM, do you already envision integrating it into your secure supply chain process?  You can already pull the signed Temurin SBOM from the Adoptium API alongside the Temurin binaries it describes.  

You can generate your own queries using api.adoptium.net/q/swagger-ui/#/Binary/getBinary and changing image_type to sbom.  For convenience, here are some example API queries for SBOMs for various versions, platforms and release types.

Summary

Whether it is in response to the Cyber Resilience Act (CRA), the Presidential Executive Order 14028 or some other sweeping mandate, we understand the need to increase our pace and deliver on our goals.  Whether it is your beer fridge, your bank account or your fuel pipeline, our project serves to protect it.  Please collaborate with Adoptium in any way you can, joining the conversation in the Adoptium Slack workspace, sharing requirements by raising Github issues, active development on some of our ‘next step’ features, or early adoption and use of our SBOMs.  We want your help.  

“Securing” not “secured”.  This is an on-going and ever-improving effort and we encourage you to join us to help secure Java and ‘keep the beer cold’.

Author: Shelley Lambert

Shelley serves on the Project Management Committee (PMC) and Steering Committee Member at Eclipse Adoptium, as a Committer Member of Eclipse Foundation Board of Directors, and as Director of Forêt Capitale Forest, a non-profit with a mission for improving biodiversity and tree canopy in urban settings.

Twitter LinkedIn Github