This Meeting Focused on Comments for the CISA SBOM Minimum Elements Proposal for 2025
The comments were as follows:
The comments below are provided by the OpenChain Telco work group. See https://github.com/nokia/Telco-WG
This work group has produced the “OpenChain Telco SBOM Guide” that is available at https://github.com/nokia/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_EN.md
This document defines what is a quality SBOM in the telecommunication industry, but it is generic enough to be used by other industries.
It incorporates the “NTIA Minimum Elements” from 2021. We plan to update this guide to be compatible with the CISA 2025 Minimum Elements document when it is finalized.
Nokia has provided a tool to validate an SBOM against the Guide. It is available at https://pypi.org/project/openchain-telco-sbom-validator/
General comments
To make the document easier to understand, it would be good to include concrete examples.
Also, it would be good to provide in an appendix the mapping of the different elements from appendix A in SPDX 2.3, SPDX 3.0 and CycloneDX 1.6.
The document uses the words “must”, “should” and “may”, but it is not clear what the exact meaning is. Are some fields mandatory and others only recommended but optional? It would be good to use BCP 14 [RFC2119] [RFC8174] to be clear.
Data Fields
Component Name
The document asks for multiple entries.
How should that be represented in SPDX and CycloneDX that allow only one value?
Using a hack like putting the different entries in the same field separated by a semi-colon seems very ugly.
An example of multiple names with justification would be useful here.
Component Version
We do not understand “If the Software Producer does not provide a version, then the SBOM Author may substitute the creation date of the file.”
What is the “creation date of the file”? A component might be composed a multiple files. Where do we find a date?
Also, “to specify a change in software from a previously identified version” does not seem to be a satisfactory definition. It means that the first release would have no version.
Software Identifiers
The documents asks that “if there are multiple software identifiers, (…) the SBOM Author should include all of them”.
This will be difficult to implement. It seems better to stick with one identifier, e.g. PURL (while of course allowing multiple identifiers, but not mandating all of them). Conversion tools exist, like purl2cpe https://github.com/scanoss/purl2cpe
Component Hash
It is unclear whether several hashes with different algorithms are allowed. This should be the case.
Dependency Relationship
It is unclear what “Component A is largely derived from Component B” really means.
Same for “is a descendant of another piece of software”.
Tool Name
If you mandate the tool name, you should mandate the tool version also.
A different version of a tool might give different results.
Timestamp
We consider that an SBOM should not change. The timestamp is the time when it was generated.
If an SBOM is recreated, it is a different one, not an update.
Generation Context
Why do you not refer to the “CISA SBOM Type”? https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf
Here you use a different terminology: “before build, during build, after build”.
Does that mean that the “CISA SBOM Type” document is obsolete?
Automation Support
It is difficult to see what you mean by “deprecated versions” of formats.
Usually, there is some form of compatibility between formats.
You should at least list what you consider as deprecated formats at the time of publishing of the document.
Practices and Processes
Frequency
Again, we do not like the notion of “revised SBOM”. Replace “should issue a revised SBOM” by “should issue a new SBOM”.
Coverage
The notion of depth is unclear. We do not understand what is meant by “There is no minimum depth.”
Does that mean that all transitive dependencies must be provided?
That seems in contradiction with what is discussed in “Known Unknowns”.
Known Unknowns
There is no native way to express this in SPDX.
So, how should that be expressed? Please provide guidance and examples.
Appendix A
There is some inconsistency in the table about fields that can have one or multiple values.
Software Producer
- multiple values
- so that should be “Software Producers (to be consistent with Software Identifiers)
Component Hash
- it is unclear whether several hashes with different algorithms are allowed
License
- multiple values
- that should be “Licenses“
Dependency Relationship
- multiple values
- that should be “Dependency Relationships“
- The relationship(s)
Tool Name
-
- multiple values
- that should be “Tool Names“
- The name(s) of the tool(s)
