Unclear purpose of UUID in spec

[mlieberman85]

It's not clear to me why a UUID is required or recommended. The spec just says:

Every BOM generated should have a unique serial number, even if
the contents of the BOM being generated have not changed over
time. The process or tool responsible for creating the BOM
should create random UUID's for every BOM generated.

Why is this the case for UUID? Wouldn't we want the ability to run the build across multiple infra and get the same hash for the file?

[stevespringett]

Together, the serialNumber and version form the identity of the BOM. Much like software has a namespace, name, and version, a CycloneDX BOM has a serialNumber and version.

BOM identity is critical for distribution use cases or for cross-referencing a specific BOM from another system. For example, the CycloneDX BOM Repository Server allows organizations to distribute all their BOMs for all the software they produce, allowing consumers to retrieve any BOM for any product, and even obtain prior versions of the same BOM in the event corrections were made after the fact.

For cross-referencing use cases, CycloneDX support BOM as an external reference type. The URI to the BOM could be a URL (location) or a URN (the BOM serial number). There are also cases where a VEX document needs to refer to a specific component in a specific BOM, so it's necessary that the BOM have an identity in order for this to happen.

If none of these use cases are relevant, you can omit the serialNumber. The spec makes it optional, but it is recommended.

[stevespringett]

To answer your last question though...

Wouldn't we want the ability to run the build across multiple infra and get the same hash for the file?

Yes and no. If your goal is reproducible builds, then you'd want to omit the serialNumber and metadata\timestamp. If your goal is audibility or compliance to the executive order, you'll need to supply the timestamp anyway as reproducible builds are incompatible with NTIA minimum elements of an SBOM - so might as well include the serialNumber to. And for 'audibility', keep in mind that most orgs are not as sophisticated as some of the amazing demos you've been showcasing lately. So dynamic information in an SBOM is generally a good thing for most organizations - at least today.

[mlieberman85]

These are good points. Thanks for pointing me in the right direction. I will close the issue