Emit the newest CycloneDX schema version that every system reading your SBOM can parse. If you do not know what your consumers accept, use the generator's default and ask. Newer is not automatically better: a version your customer's tooling rejects is worse than an older one it reads.
Why the version matters at all
An SBOM file declares a spec version, such as 1.6, in its header. A parser built for 1.5 may refuse a 1.7 file or silently ignore fields it does not know. Build plugins let you choose the version, so the choice is yours to make deliberately instead of by accident.
Think of it as a contract with the reader. Your CI gate, your internal platform, a customer's intake tool and an auditor's viewer may all read the same file. The oldest reader sets the ceiling.
What the common generators default to
The projects document their defaults in their READMEs, and they differ.
| Build system | Generator | Default schema | Other versions |
|---|---|---|---|
| Maven | CycloneDX Maven plugin | 1.7 for plugin line 2.10.x | Older plugin lines emit 1.6, 1.5, 1.4 and earlier |
| Gradle | CycloneDX Gradle plugin 3.x | 1.6 | 1.7 by setting schemaVersion |
| npm | CycloneDX npm tool | 1.6 | 1.2 to 1.5 |
| Go | CycloneDX gomod tool | Up to 1.6 | Convert with a separate CLI |
For Maven the schema is tied to the plugin version. The plugin README publishes a table mapping each plugin line to a schema, and tells you to use the latest plugin version compatible with the schema your target system supports. So in Maven, "choose a schema" really means "choose a plugin version".
How to decide in four steps
- List every consumer of the file: internal platform, CI gate, customers, auditors.
- Find the highest spec version each one documents. If the documentation is silent, send a sample file and ask.
- Take the lowest of those maxima as your target.
- Pin the setting in the build so an upgrade of the plugin cannot change the output without a review.
Step 4 is the one teams skip. A plugin bump that moves the default from 1.6 to 1.7 will change every SBOM you publish. Pinning keeps that change visible in a pull request.
When to move up
Move up when a field you need only exists in the newer version, or when all your readers have confirmed support. Do not move up merely because a release exists. When you do, generate one SBOM in the old version and one in the new, and diff what your downstream tools show. If a finding count, a license field or a dependency edge changes, find out why before you publish.
A conversion step can bridge a gap. The Go tool's README points to a separate CycloneDX command line tool that converts between spec versions, which is useful when one tool is stuck behind the others. Treat conversion output as something to validate, not to trust.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the inventory is built from the dependency data, then ask what your own readers would do with each field.
Safeguard reads dependency files and SBOMs in common formats through its SBOM and dependency scanning, and you can try a free scan to see how a file of yours is read.
Quick check
Is a newer CycloneDX version always safer to publish?
No. The version describes the file format, not its security. Publish the newest version all your readers can parse.
Can I send two versions of the same SBOM?
Yes, if a consumer needs an older one. Generate both from the same build so they describe the same release, and label them clearly.
Sources
- CycloneDX Maven plugin README
- CycloneDX Gradle plugin README
- CycloneDX npm tool README
- CycloneDX gomod README
Last reviewed: 19 October 2026.
