SBOMs Become Mandatory in 15 Months. Yours Is Probably Wrong.
On December 11, 2027, the SBOM obligations of the EU Cyber Resilience Act start applying. This means that you will soon need an SBOM if you want to ship software in the EU. It's not just the EU, but a global trend of enforcing supply-chain security with this declarative approach: The US has required SBOMs for federal software vendors since 2021, and CISA/NSA/FBI published updated SBOM minimum elements in July of this year.
Getting an SBOM correct is not easy, and it becomes even harder when you ship installers for your software. What should you do now? Let's take a look.
What is an SBOM anyway?
An SBOM is a machine-readable list of the components a piece of software is made of. There are two formats: CycloneDX, an OWASP project that was started in 2017 and became an Ecma standard in 2024, and SPDX from the Linux Foundation which has been an ISO standard since 2021. Regulators accept either of them.
Inside the SBOM, there are three main pieces of information:
- component identities as Package URLs, e.g.
pkg:maven/org.apache.commons/[email protected] - hashes and licenses
- the dependency graph, showing which component depends on which
SBOMs cannot be reasonably written by hand, they are the output of a tool. A typical Spring Boot app already pulls
in over a hundred transitive dependencies. Your build tool already knows
the full transitive dependency graph, so the SBOM is usually generated by a plugin. On the JVM this is
mostly cyclonedx-gradle-plugin for Gradle and cyclonedx-maven-plugin for Maven.
Why now?
Attacks on supply chains are picking up. Some particularly bad ones: the backdoor in xz-utils in March 2024, a library that nearly everyone ships. The chalk/debug maintainer phish on npm in September 2025 and only one week later, Shai-Hulud, the first self-replicating npm worm that also jumped to Maven Central.
Sonatype logged nearly half a million new malicious packages in 2025 alone. Increasing cyber-offensive capabilities of LLMs will make this worse, and we need to ramp up counter-measures now.
SBOMs are no magic bullet, but they let you check immediately what dependencies a piece of software ships so you can react to external threats with minimal delay.
So why is it hard?
The plugin that builds your SBOM sees the dependency graph at build time. However, that is usually not what you ship, and the SBOM must describe what you actually ship, byte for byte. Any byte-changing transformation after dependency resolution makes this SBOM invalid.
What could these byte-changing transformations be? The simplest example is a fat JAR. The hashes that the SBOM provides for all your dependencies are all wrong after you package them into a single JAR.
But things get messier when you ship installers: Authenticode signing on Windows, Mach-O signing on macOS, JAR shrinking and packing, all of them change the hashes. An SBOM generated at "dependency resolution time" is always wrong for the final artifact.
Even worse, there are invisible components that are added by your installer, that you may not know about at all. For example, the native zlib library included in a Windows launcher or shaded JARs in the installer runtime, all of these are missing from your SBOM.
The zlib example is not theoretical at all, it comes from our own install4j Windows launcher. No standalone executable zlib artifact is distributed because the library is modified and embedded. So it's effectively invisible except to detailed scanning, but still subject to vulnerabilities and something that has to be included in your SBOM.
The last assembler problem
For installed software, the installer is the final step that assembles what the customer receives. If the SBOM is written before or without that step, it does not describe the product, and you are likely in violation of current or soon to be active regulations.
So the "last assembler" is the tool that builds your installers, and it needs to be able to do something about your SBOMs. What it cannot do is to generate the SBOM itself, that is only doable by the build tool which knows about the dependency graph. What it needs to do instead is to at least write an SBOM of its own components. Even better, it should be able to augment an existing SBOM with its own additions, so you can ship it inside the installer.
SBOM functionality in install4j
install4j 13.1 can generate CycloneDX SBOMs in JSON and XML for the install4j runtime components shipped
in each media file. The files can be written externally next to the media file at
<media file>.install4j_runtime.cdx.json / .xml, or embedded at a path in the distribution tree.
If an SBOM already exists at the embedded path (CycloneDX spec versions 1.2 through 1.7 are supported), install4j merges the runtime components and their dependency graph into it instead of replacing it. Also, install4j tracks every byte-changing transformation during compilation (signing, shrinking and packing) and rewrites the hashes, so that the SBOM matches the final signed media file.
Of course, we eat our own cooking: install4j includes a complete SBOM in
lib/install4j.cdx.json. The install4j build itself fails if any JAR in the distribution
is not covered by a SHA-256 hash.
Getting Started
SBOMs are quickly becoming a required deliverable. Regulations are closing in fast and the window to get this right is tight. To do this correctly you need tooling that can do this for you. And this includes your installer builder.
Try out install4j for free at https://www.ej-technologies.com/install4j/download for 90 days, no registration required.