Add the CycloneDX Maven plugin to your POM and bind its makeAggregateBom goal to the package phase. The build then writes a CycloneDX SBOM listing direct and transitive dependencies, in JSON and XML by default. Review the scope settings, attach the file to your release and store it.
What the plugin produces
The plugin's project page describes it as creating a CycloneDX software bill of materials containing the aggregate of all direct and transitive dependencies of a project. CycloneDX is described there as a full-stack SBOM standard designed for application security and supply chain component analysis.
Setup steps
- Add the plugin to the build section of your POM, with an execution on the package phase.
<plugin>
<groupId>org.cyclonedx</groupId>
<artifactId>cyclonedx-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>makeAggregateBom</goal>
</goals>
</execution>
</executions>
</plugin>
- Pin the plugin version. The project page maps plugin versions to schema versions, so pick one that matches the schema your consumers accept.
- Run mvn package, or your normal CI build.
- Find the output in the target directory. The default name is bom, with both JSON and XML written.
- Attach it to the release. By default the plugin attaches the BOM as an additional artifact with a cyclonedx classifier during install or deploy, which you can turn off with a skipAttach property.
The three goals
| Goal | Result |
|---|---|
| makeBom | A BOM for each Maven module |
| makeAggregateBom | One aggregate BOM at the build root, and optionally one per module |
| makePackageBom | A BOM for each module with war or ear packaging |
For a multi module project, the aggregate goal is the usual choice for a release record.
Defaults worth checking
The documented defaults include library as the project type, and a default schema version of 1.7 in the current readme. Compile, provided, runtime and system scopes are included and test scope is excluded. That last point is usually right for a shipped product, because test libraries do not reach production.
Set the project type to application if you are describing a deployable service rather than a library. You can also exclude modules, for example with the excludeTestProject property for modules with test in their artifact id.
Quality checks before you share it
- Open the file and spot check a few components against your dependency tree.
- Confirm the main component name and version are right.
- Confirm that a shaded or fat jar is still described properly. See detecting vulnerable code in shaded uber jars.
- Validate the file against the schema version it declares.
- Regenerate it on every release build, never by hand.
A Maven SBOM reflects what Maven resolved from your POM. It will not list things you copied in outside the dependency system, so be clear about that when a buyer asks what it covers.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the component list and its direct and transitive grouping, which mirrors the content of a generated SBOM.
Safeguard generates SBOMs and runs dependency scanning for Java projects, and its compliance and evidence automation can keep them with your release records. Free scan: gold.safeguard.sh/scan.
Quick check
Should test dependencies be in the SBOM?
The plugin excludes test scope by default, which suits shipped software. Include them only if your use case needs the build environment described.
Is JSON or XML better?
Both carry the same data. The plugin writes both by default, so publish whichever your consumers can read.
Sources
Last reviewed: 19 October 2026.
