Hello, America's cybersecurity agency, CISA, have been working on a document describing what they consider the 'minimal' requirements for SBOMs. They have a draft up at https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf which is now in 'Public Comment' phase.
It might be worth highlighting a couple of aspects from a Reproducible Builds perspective. I think both for our own consensus-building and to make sure the most important points don't get lost in the noise, we should avoid responding to "everything we think might be wrong with this document", and focus on the changes that are important to us from the Reproducible Builds perspective. This could be something along the lines of: ===== # Public Comment on 2025 Minimum Elements for a Software Bill of Materials The Reproducible Builds project represents an industry-wide community around creating an independently-verifiable path from source to binary code. As such we have extensive experience with 'Bill of Material' documents - the 'buildinfo' concept initiated in the Reproducible Builds project was an early precursor to SBOM. There are a number of fields in the proposed list that we believe could be improved as follows: ## Component Version In the case Software Producer does not provide a version, this definition allows using the creation date of the (SBOM) file. This does not seem helpful, as the creation date of the SBOM file is largely independent of the version of the software. It would be more helpful to allow the creation/publication date of the software, or a version reference derived from Version Control System (such as a commit hash or the result of 'git describe'). Recommendation: replace "creation date of the file" with "creation date of the SBOM file, creation or publication date of the software, or a version reference derived from the components' public Version Control System (if any)". It would also be helpful to allow not including the component version when it is not relevant, which is the case when including external/dynamic library references in an SBOM. Examples of such references are elements with relation type 'DYNAMIC' in SPDX and references marked as 'external' in the upcoming CycloneDX 1.7 (https://github.com/CycloneDX/specification/blob/1.7-dev/schema/bom-1.7.proto#L168) Recommendation: add: "If the software does not dictate a version for the component artifact, such as may be the case for external/dynamic library references, then the SBOM Author should not include a Component Version" ## Software Identifier This definition allows commit hashes as software identifiers. A commit hash could be _part_ of an organization-specific software identifier, but cannot act as an identifier on its own. Recommendation: remove "commit hash" from the list in the definition ## Component Hash This definition allows not including a component hash when the SBOM does not have access to this hash. It would be helpful to also allow not including the component hash when it is not relevant, which is the case when including external/dynamic library references in an SBOM. Recommendation: after “If the SBOM Author does not have access to the original component artifact,”, add “or when this component describes an external/dynamic library, “. ## Timestamp For the scenario where the SBOM Author does not make any changes to the SBOM after generating it, the time and date of generation is not particularly meaningful. It would be more helpful to allow the creation/publication date of the software. Recommendation: after “the time and date of generation”, add “of the SBOM, or the time and date of the creation or publication of the software component” ===== Do you agree with the comments above? Are there any changes you'd like to see, or additional comments you think would be valuable to relay in the context of reproducible builds? The timeline is relatively strict: if we can get rough consensus before, say, Wednesday, I think we could respond "as the Reproducible Builds project". Kind regards, Arnout
