Thanks for sharing this here - I was aware, but good to spread that awareness :).
To save some clicking, the actual (draft) document is at https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf. It generally looks pretty reasonable to me. I've collected a couple of points of feedback, but nothing too major: 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 Version Control System (such as a commit hash or the result of 'git describe'). 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 ) 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. 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. Dependency Relationship: This section as written only deals with dependencies that are 'included'/'embedded' into the described artifact. It would be good to also acknowledge 'external'/'dynamic' dependency relationships. This section also talks about components that are derived from other software. For clarity I think it would be good to mention this in a separate section, even if in practice indeed formats may choose to express both derived components and component dependencies using the same technical elements. Timestamp: This definition specifies using the time and date of generation as timestamp when the SBOM Author does not make any changes. In this case it would be helpful to also allow the time and date of creation/publication of the software to be used as a timestamp. Generation Context: In this section you mention three lifecycle phases by name (before build, during build, after build). It might be good to add "e.g." here to clarify that this is not meant as an exhaustive list, as I expect the thinking on what kind of generation context information is valuable to record will still evolve over time. I'm curious if you have any additional thoughts! Kind regards, Arnout On Thu, Aug 28, 2025 at 4:22 AM Craig Russell <apache....@gmail.com> wrote: > Are we aware of and working on this? I don't recall discussions on this > particular topic... > > > https://www.scworld.com/news/cisa-releases-draft-changes-to-sbom-minimum-requirements-for-comment > > > Craig L Russell > c...@apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
