Add serialNumber requirement

[stevespringett]

This is an enhancement proposal to the CycloneDX specification to add a requirement that every BOM have a serialNumber. The serialNumber will be an attribute of the <bom> element and will be expected to be RFC 4122 complaint.

Example:

<bom xmlns="http://cyclonedx.org/schema/bom/1.0" 
     serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79"
     version="1" >

Every BOM generated must 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 must create random UUID's for every BOM generated.

[stevespringett]

Ideally, the serialNumber would be required for CycloneDX 1.1 BOMs and not required for existing 1.0 BOMs. This is the only change to the specification which prevents a 1.0 BOM from being validated against the 1.1 schema.

XML Schema does not provide this functionality. Others like Schematron do.

I believe the importance of backward compatible validation outweighs the strict requirement for a serialNumber in 1.1.

Therefore, I propose the serialNumber be changed from being required to optional in the schema, and in all official CycloneDX implementations that generate 1.1 BOMs, to include the serialNumber by default.

[stevespringett]

Included in CycloneDX 1.1

[mlinksva]

Idle curiosity question, thus leaving on closed but possibly relevant issue: should a CycloneDX BOM always be pre-build/checked in to a source repo and/or always excluded from build artifact? Possibly relevant because if neither is true, the build artifact can't be bit for bit reproducible.

[stevespringett]

@mlinksva including or excluding with build artifact may or may not be possible depending on the packaging. In Java for example, a jar file is the final packaging and ideally the bom would be included in the jar. However, the bom includes the file hashes of the component, so chicken and egg situation.

It's entirely up to use consumers of the bom and the use cases they're trying to solve concerning best practices on where to put it and how to distribute it. It can be checked into version control if that's what you want to do. In fact, pedigree information will typically always involve version control of some kind. Also if you're concerned about tampering, you can always use XML Signature to sign the boms and the resulting boms will continue to validate.

[mlinksva]

Thanks, this helps me understand the intended flexibility/no prescribed use cases of CycloneDX!

Just to be clear, my possibly relevant issue was not (directly anyway) prevention of tampering, but bit for bit reproducibility of build artifacts a la https://reproducible-builds.org