What goes in the CycloneDX group, name and version fields?

In CycloneDX, name is the short name of the component, group is the namespace or producer that scopes it, and version is the release string as the producer wrote it. Only name is required. Keep each value clean, without spaces or extra decoration, because other fields and lookups build on them.

The three fields as the spec defines them

The 1.6 JSON reference describes group as the grouping name or identifier, often a shortened name of the company or project that produced the component, or the source package or domain name. It says whitespace and special characters should be avoided and gives examples such as apache, org.apache.commons and apache.org.

name is described as the name of the component, often a shortened single name. The examples are commons-lang3 and jquery.

version is a string of up to 1024 characters. The spec says it should ideally follow semantic versioning, but nothing enforces that.

Putting it together

A well-formed component for a well known Java library looks like this.

{
  "type": "library",
  "group": "org.apache.commons",
  "name": "commons-lang3",
  "version": "3.14.0",
  "purl": "pkg:maven/org.apache.commons/commons-lang3@3.14.0"
}

Notice the pieces repeat. Group, name and version are the human-readable view. The purl is the machine-readable identity that vulnerability matching usually keys on. If the two disagree, a reader cannot tell which one is right.

Mistakes that cause trouble

Stuffing the group into the name. Writing org.apache.commons:commons-lang3 in name leaves group empty and breaks tools that expect the split.

Adding decoration to the version. A prefix such as v or a trailing build label may be how the producer wrote it, in which case keep it. Do not invent one, and do not strip one to make it look neat. The spec's own examples show strings like v1.33.7 and 2.0pre1 as acceptable.

Using a display name. A marketing name with spaces, such as a product title, is not the package name. Use what the package manager calls it.

Different group per tool. When two scanners run over the same repo and one fills group while the other does not, comparing outputs shows false differences. Pick one convention and enforce it in review.

A review habit that works

When you read an SBOM, pick five components and check each against the package manager page or lockfile. Does the name match exactly? Is the group the namespace the registry shows? Does the version match the lockfile entry? Five spot checks catch most generator problems in minutes.

Safeguard can generate SBOMs and run dependency scanning across your repositories, so the fields discussed here are checked on real projects instead of by hand. You can try the free scan at gold.safeguard.sh/scan.

Try it yourself

Open the demo, click through the component list, and look at how each package is identified and what is missing.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CycloneDX 1.6 JSON reference

Last reviewed: 19 October 2026.