Public comments on SBOM Document Quality Guide: regulatory scope, lifecycle, and quality requirements

[KoukiHama]

Context

This issue collects public-review comments and questions on the SBOM Document Quality Guide, based on comments provided by Ibrahim Haddad. The items below are intended for triage by the working group: some may require text changes, some may require clarification of scope, and some may be better handled as out-of-scope explanations or future-work notes.

Source:
https://lists.openchainproject.org/g/sbom/message/111

Questions / comments to triage

No.	Topic	Relevant clause(s)	Comment / question
1	CRA retention obligations	6.1	The retention obligations are not addressed. The CRA mandates ten years or the product support period, whichever is longer.
2	Relationship between CRA vulnerability reporting timelines and SBOM quality	6.1; possibly Chapter 3	The CRA's vulnerability reporting timelines (24h, 72h, 14 days, one month) should be connected to SBOM quality requirements, as the SBOM is the instrument that enables compliance with those timelines.
3	Status of CISA 2025 guidance	6.3	The CISA 2025 guidance is presented with mandatory SHALL language without disclosing whether it has been finalized or remains a draft.
4	China's Cybersecurity Law and traceability obligations	6.0	China's Cybersecurity Law and associated regulations impose SBOM-aligned traceability obligations on critical infrastructure operators and are not addressed in the guide.
5	Scope of US EO 14028	6.2	The scope of the US EO 14028 should be clarified; it is limited to US federal procurement and carries no direct enforcement mechanism for the broader private sector.
6	SBOM lifecycle management	Chapter 3	The guide covers SBOM document quality at the moment of exchange but does not address lifecycle management: verification, update cadence, sign-off, distribution controls, and retention. These are critical phases in the lifecycle of the SBOM covered in my report.
7	Regenerating SBOMs for software updates	3.4	The obligation to generate a new SBOM with every software update is not mentioned. Section 3.4 covers initial delivery timing only.
8	Organizational accountability	3.1	Organizational accountability is treated only as a document field problem. I believe the guide should address or provide guidance on which function owns the SBOM process, not just which fields to populate.
9	Confidentiality and redistribution restrictions	3.7	The confidentiality guidance in section 3.7 prohibits redistribution restrictions, which conflict with the security practice of controlling access to component inventories that reveal unpatched vulnerabilities.
10	Verification methods	3.6	Verification methods in section 3.6 are limited to digital signatures. However, other methods exist, such as build-system integration, hash comparison, and binary analysis, which are established techniques that should be mentioned or included.
11	Phased adoption guidance	Chapter 2	The guide does not offer a phased adoption path or prioritization guidance. Organizations at different maturity levels have no way to identify where to start. I believe there will be high value in providing guidance on the adoption path.
12	Transitive dependency coverage	3.3	Transitive dependency coverage is a SHOULD. Given that major vulnerabilities consistently originate in transitive dependencies, this should be a SHALL with explicit depth guidance.
13	VEX	Chapter 3	VEX is not mentioned. It is an established complement to SBOM for vulnerability management and is natively supported in CycloneDX 1.4 and later.
14	SBOM composition and merging	Chapter 3	The guide does not address the topic of SBOM composition and merging. This is a common challenge in multi-tier / complex software supply chains and a potential practical gap for the intended audience. A merged SBOM should be validated after composition to confirm that no data was lost, no relationships were broken, and no duplicate components were introduced. The guide's quality criteria in section 3 apply to individual SBOM documents but are not explicitly extended to cover the output of a merge operation.
15	Hash algorithm strength	3.2; 6.2	I suggest that the hash algorithm strength guidance be mentioned in section 3, not in a table (section 6.2 in the table under Component Hash). I believe guidance in section 3.2 should be strengthened to name the minimum acceptable algorithm explicitly, and should state that MD5 and SHA-1 are not acceptable.
16	AI-generated and AI-assisted code	Chapter 3	AI-generated and AI-assisted code introduces license ambiguity and traceability challenges. These topics are not addressed anywhere in the guide, and given the landscape of AI-assisted coding today, this topic might be worth its own section.
17	SWID scope and guidance	1.2	On SWID: the guide implies SWID is a recognized data format in scope, but provides no quality guidance for it and does not include it in the compliance framework. Organizations producing SWID-based SBOMs receive no actionable guidance from this document. I suggest either explicitly stating that the guide covers only SPDX and CycloneDX as data formats or extending the guidance to cover SWID.