SBOMs & Java Security: Stay Compliant, Stay Protected!
Transcript:
Regulations are cracking down. If an auditor shows up tomorrow, would your software pass the test? If you can't produce a software bill of materials, you could be fined, blocked from contracts, or even forced to halt operations. And here is the real nightmare: companies that scramble to generate an SBOM often find hidden vulnerabilities and back doors that hackers could have been exploiting for years.
So today, I will show you how to generate a software bill of materials and scan your project for vulnerabilities so that you always stay secure, compliant, and in business. Have you ever been to a restaurant and asked what's in a dish only to hear, "I don't know?" Well, that's what running software without a software bill of materials is like. But regulators won't accept "I don't know." A software bill of materials, or an SBOM for short, is, uh, the inventory of all the dependencies used in your project. It contains information about open source and proprietary dependencies. But don't worry-that doesn't mean that you have to disclose the source code. The code may remain confidential.
An SBOM is like a detailed list of ingredients for your project-all the components, all the libraries, both open source and proprietary. And here's the problem: some of these ingredients might be rotten, outdated, or vulnerable, and even legally risky dependencies could be lurking in your software right now. So, in a way, you are between a devil and a deep blue sea: on one hand, there are vulnerabilities that you don't know about, and on the other hand, there is legislation that you have to comply with.
Yes, several laws already demand SBOMs, and the list is growing. For instance, there is the US Executive Order 14028, which states that federal agencies demand SBOMs for procurement. There are the NIST guidelines that define best practices for generating SBOMs. There is also the European Union Cyber Resilience Act. It requires SBOMs for all software sold in the European Union, and even big tech companies now demand SBOMs from vendors before signing contracts. So, no SBOM, no deal-no compliance and legal risks.
In other words, if you fail a compliance audit, your company might be fined or even blocked from operations. If a client asks for an SBOM and you don't have it, you might lose a deal. If a security incident happens, you might spend weeks scrambling to find the vulnerable library that was affected. The stakes are too high.
So, how did an SBOM become such a necessity? Why should you bother with listing all the dependencies in your project? Because there could be hundreds of them. And here's the shocking truth: most projects are 90% based on open source. Well, there's nothing wrong with open source per se-it's great. I personally love open source and don't have anything against it. But the problem is, if you use so many open-source libraries in your project, you have to be able to control what is used in your software. Some open-source libraries might already be abandoned, and you don't know about that. Some of them might not be regularly updated. Some libraries are maintained by one overworked developer, and as a result, an average project contains about 45 known vulnerabilities. Think of it as locking the front door but leaving 45 windows open.
So an SBOM is not just about listing the dependencies; it's about revealing hidden threats before they explode. New vulnerabilities will come up. Some libraries will be abandoned. New tools and solutions will emerge, and your developers will be happy to use them. And do you know how you can have it all under control? There are three key recommendations. Use versioned components and systems that support SBOM generation or even ship with one, like Liberica JDK. Use tools for generating SBOMs for your project. And use vulnerability scanners to analyze the generated SBOMs and identify vulnerabilities. With this unified workflow, you can efficiently control the security of your infrastructure. So, to sum up, with a software bill of materials, you can understand whether you use outdated or fresh dependencies, prevent hidden vulnerabilities, find affected components fast, set up automatic vulnerability scanning, minimize licensing risks, and ensure legislative compliance.
Open-source tools for generating SBOMs-an SBOM must be generated in one of the three standard industry formats: SPDX, CycloneDX, or Software Identification Tag. So, it is important to choose a tool that can generate an SBOM in one of these formats. Let's look at four popular open-source tools for SBOM generation. CycloneDX Generator (CDXGEN) is a command line interface tool. It works with multiple programming languages and project types. It supports various SBOM formats such as CycloneDX, Software as a Service SBOM, and others. This tool also integrates easily with the CI/CD pipeline. It accepts various package formats-for instance, in the case of Java, it accepts Maven pom.xml, Gradle build files, and some others. It also accepts container images, JAR files, OS packages, and many more. It generates a JSON file or an XML file and supports CycloneDX format, with conversion to SPDX possible as well. This tool is optimal for Java because it works with Java build systems and in perfect combination with the OWASP dependency scanner.
Swift is another command line interface tool. It accepts container images, files, and archives. It can generate an SBOM in multiple formats: JSON, XML, human-readable text, columnar tables, or even tag-value formatted reports. It supports CycloneDX, SPDX, and its own format. Also, Swift integrates seamlessly with the Grype security scanner, making it an optimal tool if you need SBOMs for multiple languages. Turn is a tool that can produce a software bill of materials for Docker container images and Dockerfiles. It can generate an SBOM in multiple formats: JSON, HTML, human-readable format, or YAML. It supports CycloneDX and SPDX and is good for Docker images.
Kubernetes BOM is a tool for generating SBOMs for projects running in Kubernetes. It accepts files, Docker images, or Docker archives in the form of tarballs. This tool can generate an SBOM as a JSON file, HTML file, YAML file, or human-readable text. It supports SPDX and is very good for workloads running in Kubernetes. You can find a more detailed description of each tool in a related article; the link is in the description box.
How do you generate an SBOM for a project in the Java ecosystem? It doesn't matter whether you use Java or Kotlin; what matters is that you work in the Java ecosystem, use specific build tools such as Maven or Gradle, and use the relevant artifact repository such as Maven Central. We will look at how to generate an SBOM for a Java project through different scenarios. First, we use a command line interface tool-CycloneDX Generator. Then, we will scan the SBOM for vulnerabilities, generate an SBOM using the Maven plugin, and look into how SBOMs are handled in Spring Boot.
Starting with CycloneDX Generator: I'm using a standard Java application. It is not a Spring Boot project, but it is based on Maven-so there's a pom.xml. First of all, you need to install CDXGEN. You can do that through the npm repository. If you use Windows, you can get it through winget, but I'm using macOS, so I can say brew install cdxgen (I have already installed it). Next, you verify the installation with, for example, cdxgen --version. Then, you run: cdxgen -t java -o file.json. This command specifies the project type (Java) and the output file in JSON format. The SBOM generation may take several minutes depending on the number of dependencies, but for this small project, it was generated quite fast. Here it is, our bom.json file in JSON format-you can browse its contents: the format (CycloneDX), the components, the publisher, the name, authors, and the project dependencies (e.g., a dependency on Google library JSON with its name, version, type, properties, etc.).
Now, we can run the dependency scanner to identify any known vulnerabilities. We are using the OWASP dependency scanner, which you can install via PIP from the Python repository. If you don't have it, install it by running pip install owasp-dep-scan. Then, you point the tool to the SBOM file with appropriate flags (for instance, -b for BOM and -r for the reports directory). The scanning will begin and may take some time. Once complete, the terminal displays output showing that one vulnerability was found in the Jackson databind library-a direct dependency. It also specifies the version where this vulnerability was fixed, the severity, score, and recommendation to fix it. Another file, bom.vdrone, is generated, containing information about the discovered vulnerabilities (e.g., the CVE number, description, recommendation, and affected artifacts). This file is created automatically, and you can then view the reports in an HTML file and a JSON file, which provide detailed data about the vulnerabilities.
We can also generate an SBOM using the Maven or Gradle plugin. Taking the same project, you need to add a plugin for generating an SBOM to your pom.xml. You can copy and paste the code from the article linked in the description. This plugin-CycloneDX Maven plugin-has default settings which you can modify on its GitHub page. Once added to the pom.xml, running mvn clean package will build your project and automatically generate an SBOM in the target folder, available in both JSON and XML formats.
Starting with Spring Boot 3.3, SBOM support is integrated into your projects, allowing you to include the SBOM generator as a Maven or Gradle plugin. For example, in the reference Spring Boot application Pet Clinic, you add the CycloneDX Maven plugin (be careful to use the correct artifact ID) and build the project. The generated SBOM is stored in the classes/META-INF/sbom subdirectory. Additionally, by enabling actuator endpoints (and adding the actuator dependency), you can expose an endpoint that displays all SBOMs generated for your application. Moreover, you can add additional SBOMs-for instance, for your Java runtime (like Liberica JDK)-by specifying their location in the application properties. Spring Boot will automatically detect the type based on the format (e.g., CycloneDX).
SBOMs protect your business, your software, and your customers. Regulators demand them, your clients expect them, and hackers hope you don't have one. So, generate an SBOM before it's too late. Let me know in the comments if you want a deeper dive into security scanning. See you next time.
