Tracking: SBOM output against the 2026 Minimum Elements — 6 of 12 fields met

[richardmhope]

Umbrella for the assessment of our CycloneDX output against CISA's 2026 Minimum Elements for an SBOM, published 2026-07-29 with NSA, FBI and international partners, and relayed by the ACSC. It replaces the 2021 NTIA baseline outright.

Full write-up: docs/cisa-sbom-minimum-elements-2026.md, on branch claude/tool-sbom-requirements-assessment-jkudvt.

Sourcing caveat, carried from the assessment. Neither cyber.gov.au nor cisa.gov was reachable from the environment this was produced in — 403 on both, and on the regulations.gov copies of the PDF. The requirement set is reconstructed from CISA's 2025 draft, which the 2026 document finalises, plus published analysis of the final. The shape of the requirements is well attested; exact field wording, and anything added or dropped between draft and final, should be checked against the PDF before this is quoted externally. Every gap below is also a gap under the 2021 baseline or under both, so none of the conclusions depend on the 2026 text alone.

Status

Six of twelve data fields met, three partial, six not met. The document is schema-valid, correctly identified by purl, and unusually honest about resolution confidence — but carries none of the four fields the 2026 revision added, and no producer or licence data at all.

#	Element	Status	Tracked by
1	SBOM Author	Partial	#28 (tool), open question on an authoring entity
2	Software Producer	Not met	#27, and #21 for the primary component
3	Component Name	Met	—
4	Component Version	Met, caveat	—
5	Software Identifiers	Met (components)	#29 (document identity), #21
6	Component Hash (new)	Not met	#26
7	License (new)	Not met	#12
8	Dependency Relationship / Coverage	Partial + defect	#24, #25
9	Known Unknowns	Not met in SBOM	#25
10	Timestamp	Met	—
11	Tool Name (new)	Met, caveat	#28
12	Generation Context (new)	Not met	#28
—	Automation support	Met	—
—	Frequency	Met	—
—	Distribution, delivery, access control	Out of scope	#20, #22
—	Accommodation of updates	Not met	#29

Nothing in the repository claims CISA or NTIA conformance, so there is no over-claim to correct. The gap is capability — with one exception.

Start with #24

#24 is the only item that is a defect rather than a missing feature: _dependency_graph emits dependsOn: [] for components whose parentage was never recorded, and CycloneDX defines that as a positive claim of dependency-free. It is an unearned clean result in the one output format built for machine consumption, and it contradicts the function's own docstring. It should go first regardless of what happens to the rest of this list.

#25 is next on the same grounds: an icebergsca sbom run silently drops dev and test dependencies with nothing in the document saying so.

Suggested order

1. CycloneDX dependsOn: [] claims a component has no dependencies when we never learned its parentage #24 — the defect. compositions lands here.
2. The SBOM does not disclose what the JSON report discloses about its own coverage #25 — coverage disclosure. Shares compositions with CycloneDX dependsOn: [] claims a component has no dependencies when we never learned its parentage #24; read together.
3. Generation Context: say that these SBOMs are pre-build source analysis, and stop inventing a tool version #28 — lifecycles and the 0.0.0 tool-version fallback. One function, no new data.
4. Component Hash: retain the digests five parsers already read and discard #26 — Component Hash. Free for five of seven ecosystems; the digests are already parsed and discarded.
5. Report declared licences, and emit CycloneDX licenses #12 + No Software Producer on any component, and no way to say we do not know #27 — licences and producers. Same registry fetch, same cache namespace, same --offline question; doing them separately pays that cost twice.
6. A revised SBOM is indistinguishable from the original — but #20 argues against the fix #29 — needs a decision first, and depends on The SBOM does not say which source it describes #21 for something stable to derive from.

Items 1–4 need no network access and take the document from six fields to ten.

Out of scope, recorded so it is not re-derived

• AI and SaaS. The 2026 document extends transparency considerations to both, with AI SBOM minimum elements as supplemental guidance covering models, datasets, performance indicators and AI-specific infrastructure. Additive to the general minimum elements rather than part of them, and not in scope for a package-manifest scanner. The honest statement is the limitation: a project depending on model weights or datasets has those dependencies invisible to this tool, and Generation Context: say that these SBOMs are pre-build source analysis, and stop inventing a tool version #28 is where that gets said.
• SPDX output. The guidance names SPDX and CycloneDX as the acceptable formats and discourages SWID; one satisfies the requirement. CycloneDX was chosen for native VEX. Worth revisiting only if a consumer demands SPDX. (tests/schemas/spdx.schema.json is the licence-ID sibling the CycloneDX schema $refs, not SPDX support.)
• Signing and attestation. Argued out in Deterministic output, so an SBOM can be attested by digest #20; that reasoning stands.
• CPE identifiers. Deriving them from purls is guesswork and a wrong CPE is worse than none. Better documented as a deliberate omission than attempted.
• SBOM ingest. Ingest an existing SBOM and check it against OSV #23. Matters more under the 2026 framing than the 2021 one, since the revision is oriented toward real-time vulnerability management, and a tool that emits SBOMs but cannot consume one covers half that loop.

One caution for all of the above

Every field here adds a place where absence can be misread as absolution. An unknown licence rendered blank reads as unencumbered; a missing hash reads as unverified-but-fine; "unknown provenance" reads as trusted once it is one row among many. The existing safeguards — None distinct from empty, suppressed findings that stay in the report, tests asserting the absence of reassuring strings — are the pattern to extend. Each new field wants its negative test before it wants a renderer.