A 'Software Bill of Materials' (SBOM) is a standardized document describing all dependencies of an artifact. This may include compile-time dependencies, or be restricted to run-time/embedded dependencies.

Such a document can then be used by platform-agnostic tooling to report on interesting properties of the dependency tree, such as security advisories.

There are various SBOM formats, such as CycloneDX and SPDX.

Producing SBOMs


Maven projects users can use the https://github.com/CycloneDX/cyclonedx-maven-plugin and https://github.com/spdx/spdx-maven-plugin (already part of the Apache Commons parent pom). These plugins can take care of both generating the SBOM and publishing it alongside the artifact to the Maven Repository.

These plugins do have known limitations:


Gradle projects can use https://github.com/CycloneDX/cyclonedx-gradle-plugin to create an SBOM. Publishing it requires some additional configuration. The plugin appears to generate 'one big' BOM for the whole project, rather than a BOM per artifact.


There exists an sbt-bom sbt plugin, but right now it only generates the SBOM, not publish it.


If you're publising a Docker image, you might want to consider generating an SBOM for the entire Docker image and publishing that to the Docker Registry by adding a linked resource.

Using SBOMs


The Security team has set up an experimental DependencyTrack instance at https://security-tools-ec2-va.apache.org/. If upload SBOMs to this tool, you can use its interface to discover whether there are any current advisories for dependencies of your project. You should be able to log in with your apache.org id (but note this authentication method is experimental). Email engelen@apache.org if you would like further access.

DependencyTrack VEX support

DependencyTrack supports Vulnerability Exploitability Exchange (VEX) data both as input and as output format:

  • as input: allow suppressing warnings about advisories that have been verified to not affect the project
  • as output: allow 'manually' suppressing advisories through the Web UI and exporting that information

At Apache we prefer to use VEX as input to DependencyTrack rather than output: that gives us the opportunity to have the "source of truth" of the VEX information in version control, and use well-known tools to control access, history, reviewing etc.. This information can then be imported into DependencyTrack to make the reports more accurate.


  • No labels