DependencyTrack / DependencyTrack/dependency-track

Support CISA 2026 SBOM Minimum Elements in CycloneDX exports

Open
#6,852 1 comment 4 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
4.2k
Forks
811
Avg merge
8h 39m
Merged PRs (30d)
237

Description

## Current Behavior

On July 29, 2026, CISA and 17 partner agencies (incl. BSI, ANSSI, ACN, METI) published the
**2026 Minimum Elements for a Software Bill of Materials**, replacing the 2021 NTIA elements:
https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom

v5 already covers most of the 17 data fields (and the `?version=` export parameter resolves
the old v4 spec-version limitation). Remaining gaps in `GET /api/v1/bom/cyclonedx/project/{uuid}`:

| 2026 Element | Gap | Code reference |
|---|---|---|
| SBOM Generation Context (new) | `metadata.lifecycles` (CDX ≥1.5) is never populated. | `ModelConverter#createMetadata` |
| SBOM Version (new) | `serialNumber` is a fresh `UUID.randomUUID()` per export and `version` is hardcoded to `1`, so no export indicates a relationship to earlier iterations. | `CycloneDXExporter#create` |
| SBOM Author (major update) | Export uses `Metadata#setManufacture` — deprecated since CDX 1.6 in favor of `manufacturer`. There is also no instance-level "SBOM authoring organization" setting; author identity must be maintained per project. | `ModelConverter#createMetadata` |
| SBOM Author Signature (new) | No signing support in the export path. | — |
| Explicitly Identifying Unknown Information (major update) | Components without `supplier`, `hashes`, or `licenses` have those fields silently omitted. The 2026 practice requires explicitly distinguishing unknown from withheld (e.g. unknown-provenance marker for supplier, `NOASSERTION` for licenses). | `ModelConverter#convert(Component)` |
| Coverage (major update) | Ingestion de-duplicates by `ComponentIdentity` (purl/cpe/swid/group/name/version), collapsing multiple instances of a component that differ only in other metadata (hashes, licenses, scope). The 2026 Coverage element requires listing such instances separately with their own dependency relationships. Data is lost at ingest and cannot be reconstructed on export. | `ImportBomActivity` ("One identity can point to multiple BOM refs, due to component and service de-duplication.") |

## Proposed Behavior

- [ ] Populate `metadata.lifecycles` on export (configurable; sensible default `post-build`/`operations` for an inventory export).
- [ ] Emit `metadata.manufacturer` instead of deprecated `manufacture` when exporting CDX ≥1.6.
- [ ] Optional instance-level SBOM authoring organization, injected as `metadata.authors`/`metadata.manufacturer` on export.
- [ ] Export version lineage: stable per-project `serialNumber` and an incrementing `version` when exported content changed.
- [ ] Opt-in "explicit unknowns" export mode: unknown-provenance supplier marker, `NOASSERTION` licenses, hash-unknown property for components lacking those fields.
- [ ] (Design discussion) Preserve or represent duplicate component instances whose metadata differs, per the Coverage element.
- [ ] (Stretch) Optional enveloped JSF signing of exports with a configured key, or a documented hook for external signing.

## Rationale

Joint guidance from CISA/NSA/FBI + 17 international agencies (BSI co-authored) will shape SBOM
procurement expectations the way the 2021 NTIA elements did, and converges with EU CRA /
BSI TR-03183-2. Closing these gaps lets DT exports serve directly as conformant deliverables
instead of requiring external post-processing. Most items are small; the lifecycles,
manufacturer-field, and authoring-org changes are localized to `ModelConverter#createMetadata`.

Happy to split into separate issues and/or contribute PRs for the smaller items.

Contributor guide

Open the contributing guide

Research direction

Start at GET /api/v1/bom/cyclonedx/project/{uuid}, then read ModelConverter#createMetadata, CycloneDXExporter#create, ModelConverter#convert(Component), and the referenced ImportBomActivity behavior. First separate the localized export gaps from the ingestion and signing design questions. Done should mean an agreed, testable subset of the checklist is implemented without silently losing the specified SBOM information.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.