CycloneDX / CycloneDX/specification

[2.0]: Definitions registry and multi-product inventory refactor

Open
#1,072 2 comments 0 reactions 1 assignee Claimed by @stevespringett View on GitHub
breaking-changes proposed core enhancement request for comment RFC notice sent
Dominant language
XSLT
Stars
547
Forks
93
Avg merge
7h 11m
Merged PRs (30d)
37

Description

## Objective

CycloneDX 2.0 restructures how documents declare *what exists* versus *what is asserted*. Reusable objects, including components, parties, licenses, profiles, release notes, and certifications, can be declared once in `/definitions` and referenced from anywhere in the document. A reference always denotes an identical object; anything that varies by usage is declared inline where it is used.

Product inventory becomes an explicit, self-contained statement: each entry names its subject and lists what that subject contains, so a single document can describe the contents of one product or many, with shared components declared once.

## Why this refactor is necessary

Every other assertion in the specification is self-contained and names its own subject: declarations name their targets, vulnerabilities name what they affect, compositions name their assemblies, and threats name their scope. Inventory is the one assertion that instead relies on an implicit convention, where the root `components` array represents the inventory of `metadata.component` by rule rather than by reference.

That convention is a leftover from when CycloneDX was a BOM-only format, which has not been true since v1.4. A CycloneDX document may be a VEX, an attestation, a threat model, or any combination of capabilities, yet inventory declaration still assumes one document, one BOM, one subject. This refactor brings inventory in line with how everything else in the specification already works, and removes the single-subject assumption in the process.

Goals:

- One way to declare a product's contents, whether the document covers one product or fifty.
- Eliminate duplication of repeated objects such as licenses, suppliers, and shared components.
- Consistent reference behavior across the specification, applied by the same rules in future versions.

## Related issues addressed in whole or in part

- [ ] #734 Inconsistent use of mediaType, mimeType, and contentType
- [ ] #263 Dedicated node for licenses

Part of the CycloneDX 2.0 effort tracked in #631

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.