Repository navigation
SBOM format rationale is partly wrong or stale: OWASP Dependency-Check does not ingest CycloneDX, and 1.5 is no longer the tooling default (CR-A16-088) #533
Description
Wave 2 · theme D2-7: Next-release technology updates · highest severity Medium · 3 finding(s) · effort trivial
Summary
A deployer's compliance team picks OWASP Dependency-Check to ingest sbom-*.json because the reference doc lists it. The tool has no SBOM input path, so the team gets no CVE result from the SBOM. Separately, D-22-02's 'default' wording keeps 1.5 locked in as a decision on a premise that no longer holds.
Primary finding
CR-A16-088 — SBOM format rationale is partly wrong or stale: OWASP Dependency-Check does not ingest CycloneDX, and 1.5 is no longer the tooling default
severity Low · reachability default · intent contract-violation · confidence likely · single reviewer · not reproduced (code trace)
What happens. Q2 verdict: no document calls CycloneDX 1.5 the 'current' or 'latest' spec. Every other mention states what is emitted, which is accurate. The 1.5 line is also still maintained upstream (spec release 1.5.1 on 2026-06-02), so 'aging' is overstated and emitting 1.5 is not a defect in itself. Two rationale claims are wrong, though. (1) supply_chain_security.md:14-17 and the TR mirror list 'OWASP Dep-Check' among tools that 'consume CycloneDX 1.5 natively'. Dependency-Check's analyser catalogue has no CycloneDX/SBOM input analyser. It scans archives, assemblies, lock files and the like, so pointing an auditor at it for SBOM ingestion fails. (2) The design doc's D-22-02 (line 787) says 'CycloneDX 1.5 is the open-source-tooling default consumed by Dependency-Track'. The reference Python generator, cyclonedx-py, has defaulted to 1.6 since v6.0.0 (2025-04-24). Spec 1.6 has existed since 2024-04-09 and 1.7 since 2025-10-21, and cyclonedx-python-lib 11.12.0 (installed) emits all three. The upgrade cost is visible: the only 1.6 deprecation the emitter hits is author on the tools component (generate_sbom.py:127).
Where.
docs/reference/supply_chain_security.md:14docs/reference/supply_chain_security.md:17docs/reference/supply_chain_security-tr.md:14docs/reference/supply_chain_security-tr.md:17docs/design/iso27001_soc2_alignment.md:787tools/generate_sbom.py:113tools/generate_sbom.py:127
Evidence.
- GitHub API CycloneDX/specification releases: 1.5 2023-06-26, 1.6 2024-04-09, 1.6.1 2024-11-07, 1.7 2025-10-21, 1.5.1/1.6.2/1.7.1 2026-06-02, 1.7.2 2026-09-17. cyclonedx-python CHANGELOG: v4.2.0 (2024-04-18) 'Support CycloneDX 1.6 output'; v6.0.0 (2025-04-24) 'Spec-version defaults to CycloneDX 1.6'; v7.2.1 (2025-10-29) 'Basic support for CycloneDX 1.7'. DependencyCheck main src/site/markdown/analyzers/index.md (58 lines) and its README (381 lines) contain no 'CycloneDX' or 'SBOM'. Installed Sch…
Recommended fix. Correct the consumer list in EN and TR. Restate D-22-02 without the default claim. When convenient, track a 1.6 emission (replace tools component author with authors/manufacturer).
Other findings with the same root cause
These close with the same fix; update them in the same pull request.
TECH-T12-003 — Supply-chain tooling, network dependencies and vulnerability scanning: CycloneDX 1.5 SBOM format (tools/generate_sbom.py:2,113) (aging)
severity Next release
Item. CycloneDX 1.5 SBOM format (tools/generate_sbom.py:2,113) · verdict: aging · urgency: Next release
State in ForgeLM. tools/generate_sbom.py:113 emits specVersion "1.5" (docstring :2); publish.yml:104 names the step 'Generate SBOM (CycloneDX 1.5)'; '1.5' is advertised in docs/reference/supply_chain_security.md:12, docs/usermanuals/en/operations/supply-chain.md:8,14, docs/design/iso27001_soc2_alignment.md:127,173,239,787, site/features.html:390 and site/compliance.html:253.
State of the ecosystem on 2026-10-01. CycloneDX 1.7 is the current spec (released 2025-10-21; patch 1.7.2 on 2026-09-17; ECMA-424). 1.6.2 and 1.5.1 maintenance patches were issued 2026-06-02, so 1.5 is still maintained. Dependency-Track 4.14.4's CycloneDxValidator maps JSON specVersion 1.2 through 1.7, 1.5 included. BSI TR-03183-2 v2.1.0 (2025-08-20) raised its minimum from CycloneDX 1.5 to 1.6 (SPDX from 2.2.1 to 3.0.1).
Impact. Still valid and consumable, but two minor versions behind and below the BSI TR-03183-2 v2.1.0 floor that CRA-oriented buyers use as a conformance baseline. Code: tools/generate_sbom.py:99-133; docs (EN+TR) and site literals listed above.
Recommendation. Move the emitter to specVersion 1.6 (BSI minimum) or 1.7, validate against the official schema in tests, and update every '1.5' literal (docs EN+TR, site, the publish.yml step name) in the same change.
Sources.
- CycloneDX Specification Overview (current 1.7, ECMA-424) (2025-10-21)
- CycloneDX/specification releases (1.7.2, 1.7.1, 1.6.2, 1.5.1, 1.7) (2026-09-17)
- Dependency-Track 4.14.4 CycloneDxValidator.java (specVersion 1.2-1.7) (2026-09-14)
- Dependency-Track changelog (4.14.4 adds CycloneDX 1.7) (2026-09-14)
- BSI TR-03183-2 v2.1.0 SBOM (document history: CycloneDX min 1.6, SPDX min 3.0.1) (2025-08-20)
DOC-D3B02-038 — docs/usermanuals/en/operations/supply-chain.md: false claim — pip-audit and bandit are "also re-run on every release-tag publish". Bandit runs on "Nightly 03:00 UTC + release tag".
severity Medium · already tracked: KNOWN-OPEN OPS-02|OPS-03|OPS-04|OPS-05|OPS-06|OPS-15|OPS-16|OPS-19 docs/roadmap/phase-16-trust-surface-hardening.md:657-659; docs/roadmap/risks-and-decisions.md:199
Where. docs/usermanuals/en/operations/supply-chain.md:8,16 (Turkish mirror: docs/usermanuals/tr/operations/supply-chain.md:8,16) · type: false claim
The document says. pip-audit and bandit are "also re-run on every release-tag publish". Bandit runs on "Nightly 03:00 UTC + release tag".
What the code does. publish.yml (the v* tag workflow) has no pip-audit or bandit step. bandit runs in ci.yml (push to main / PRs, which tags do not trigger) and nightly.yml. pip-audit runs only nightly.
Code references. .github/workflows/publish.yml:1-136, .github/workflows/ci.yml:3-7, .github/workflows/ci.yml:511-524, .github/workflows/nightly.yml:330-335
User impact. Release-time security evidence that the docs promise does not exist.
Proposed correction. "| Push to main / PR + nightly 03:00 UTC | bandit ... |". Drop "(also re-run on every release-tag publish)".
Turkish mirror. the Turkish page has the same error; fix both in the same PR
Acceptance criteria
- A regression test reproduces the failure scenario and asserts the corrected behaviour.
- Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
- Every finding in this issue is resolved or explicitly closed with a reason.
Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsTodo
Activity