It’s a day like any other. We pick up our smartphones, tap “Download” on a new app, and launch it moments later. We take for granted that millions of lines of code are seamlessly working together behind the scenes to make this happen safely. Yet, to trust these digital services, a backend IT infrastructure is required that is not only high-performing and high-quality but above all, secure and transparent.

A large part of the global software infrastructure is built on the Java programming language. According to current indices like RedMonk, TIOBE, or PYPL, Java consistently ranks among the most popular used programming languages worldwide. To uphold the highest security standards, active engagement with the open-source community is essential. A key contributor to this effort is the Eclipse Foundation.

Eclipse Adoptium – Where Java Distributions are born

The Eclipse Foundation is a non-profit organization that manages open-source projects. Within this community, the Adoptium working group ensures the provision of high-quality Java runtimes.

Their flagship product is Eclipse Temurin, a free distribution with over 800 million downloads, serving as the foundation for countless applications.

But simply using software isn’t enough. It is crucial to know exactly what’s inside.

After all, nobody would eat soup from a stranger without checking the ingredients. Here, two crucial concepts for digital trust come into play: SBOMs (Software Bill of Materials) and Reproducible Builds.

SBOMs – The Digital Ingredient List

Much like packaged food listing its ingredients, software can be made transparent with a list of its components. This is called a Software Bill of Materials (SBOM). It outlines the components, metadata, and dependencies of a software product.

SBOMs are essential for security, transparency, and compliance. If a vulnerability or malware is discovered in a specific library, the SBOM allows us to quickly determine whether our software is affected.

Reproducible Builds – Trust Through Verifiability

An ingredient list alone, however, does not guarantee that the final product is safe. We need absolute certainty that the binary was exactly built from the stated source code and dependencies.

What if a compilation error occurred, or worse, a third party injected malicious code?

This is where Reproducible Builds come in. They ensure that the same source code, compiled in different environments, produces bit-for-bit identical results. This allows independent parties to repeat the build on their own machines. If the results match, the software can be trusted.

Figure 1 illustrates how the build recipe from the initial build (Build A) is used to replicate the process on a completely different machine (Build B). Comparing the two resulting JDK binaries lets anyone independently verify that the software hasn’t been tampered with.

Our Contribution – The Recipe for Software

Until now, the Temurin SBOM was missing a crucial detail: how the software was built.

To close this gap, we contributed to Eclipse Adoptium Security by expanding the SBOM to include a “Build Recipe.”

Just like a cooking recipe ensures the soup tastes the same regardless of which stove or pot is used, this digital recipe details the exact steps required to recreate the software.

Technically, we implemented this using the OWASP CycloneDX standard. Our approach integrates directly into the build process, automatically extracting the necessary data and writing it into the SBOM via Bash scripts and Java tools.

Example of a Build Recipe

To give a clearer picture, the code block below shows a real build recipe, i.e. the exact commands used to create the Temurin binary:

{
  "bom-ref" : "formula_temurin_build_script_21.0.10-beta+7-202602021320",
  "workflows" : [
    {
      "bom-ref" : "workflow_temurin_build_script_21.0.10-beta+7-202602021320",
      "uid" : "workflow_temurin_build_script_21.0.10-beta+7-202602021320",
      "name" : "temurin build script 21.0.10-beta+7-202602021320",
      "taskTypes" : [
        "clone",
        "build"
      ],
      "steps" : [
        {
          "name" : "clone repo",
          "description" : "clone repository",
          "commands" : [
            {
              "executed" : "git clone https://github.com/Lukisorisch/temurin-build.git"
            }
          ]
        },
        {
          "name" : "cd into repository",
          "description" : "cd into temurin-build and checkout commit",
          "commands" : [
            {
              "executed" : "cd temurin-build"
            },
            {
              "executed" : "git checkout 9da35a209f8ecdb3a908633e2286db31a7deaa46"
            }
          ]
        },
        {
          "name" : "makejdk",
          "description" : "execute makejdk-any-platform.sh",
          "commands" : [
            {
              "executed" : "bash ./makejdk-any-platform.sh --build-reproducible-date '2026-02-02 13:20:07' --clean-git-repo 
              --jdk-boot-dir download --configure-args ' --disable-warnings-as-errors --enable-dtrace' --target-file-name 
              OpenJDK21U-jdk_x64_linux_hotspot_2026-02-02-13-12.tar.gz --create-source-archive --create-jre-image 
              --create-sbom --use-adoptium-devkit gcc-11.3.0-Centos7.9.2009-b04 --use-jep319-certs --create-debug-image 
              --build-variant temurin jdk21u"
            }
          ]
        }
      ]
    }
  ]
}

With these commands, anyone can clone the repository, run the script, and produce exactly the same binary. The precise timestamp (--build-reproducible-date '2026-02-02 13:20:07') ties the result securely to the specified date. Conclusion

Our approach provides a standardized guide that guarantees reproducibility. This not only strengthens the overall software security but benefits everyone relying on Adoptium’s OpenJDK. Digital trust thrives on transparent and verifiable processes