Yes. The SPDX project publishes a Maven plugin whose createSPDX goal writes an SPDX document for the artifacts in your pom. It is a different tool from the CycloneDX plugin, with its own configuration, so running both is a deliberate choice, not a switch.
What the SPDX plugin does
According to its README, the plugin produces SPDX documents for artifacts described in the Maven POM file. The goal createSPDX creates the document and replaces any existing SPDX document. You add the plugin to the build plugins section with that goal, then invoke:
mvn spdx:createSPDX
The output is written under the target directory, in a site folder, as a json file named from the groupId, artifactId and version. Running install includes the SPDX file in the repository distribution artifacts.
How it differs from the CycloneDX plugin
The two plugins come from different projects and have different emphasis.
| Question | CycloneDX Maven plugin | SPDX Maven plugin |
|---|---|---|
| Output standard | CycloneDX, xml and json | SPDX, json |
| Main goals | makeBom, makeAggregateBom, makePackageBom | createSPDX |
| Dependency scopes | Include flags per scope, test off by default | Check the plugin documentation |
| Extra data | Component metadata and external references | SPDX document and package properties, plus file level data with defaults |
The SPDX plugin README says all SPDX document and package properties are supported, some taken from POM properties and others from the configuration section. It also supports file level data with default parameters, and per path overrides for specific files.
Treat the table as a starting point and read each README before relying on a detail, because both projects change.
Do you need both formats?
Often not. Most consumers accept one format, and producing two files doubles what you must validate, store and explain. Reasons to produce both:
- A customer contract names SPDX and your internal tooling expects CycloneDX.
- A regulator or procurement checklist accepts either and you want to match each reader.
- You are migrating from one format to the other and want a transition period.
Reasons not to: you have no stated need, or you cannot yet explain the differences between the two files if a customer asks.
How to run both safely
- Generate both from the same build, in the same CI job, so they describe the same dependency set.
- Name them with the same artifact and version, differing only by format.
- Validate each against its own schema.
- Compare component counts. They need not be identical, since the tools model data differently, but a large gap is worth investigating before you publish.
- Store both with the release record.
An alternative to a second plugin is conversion from one format to the other with a converter tool. Converted output can lose fields that have no equivalent in the target format, so validate it and spot check before sending it anywhere.
Which to choose if you must pick one
Choose by who reads it. If a customer, contract or regulator specifies a format, use that. If nobody does, pick the one your internal tools ingest best. Both are widely supported standards.
Safeguard reads common SBOM formats through its SBOM and dependency scanning, so either file can be scanned and monitored. The free scan is a way to test your own output.
Quick check
Does the SPDX plugin replace the CycloneDX one?
No. They are separate tools from separate projects. Use the one that matches the format your readers need, or both.
Where does the SPDX file land?
Under the target directory in a site folder, as a json file named after the groupId, artifactId and version, per the plugin README.
Sources
Last reviewed: 19 October 2026.
