SerialNumber of SBOMs are not unique

[MeikelVielhauer]

The CycloneDX Maven Plugin is currently generating deterministic serialNumber for SBOMs, which conflicts with the CycloneDX specification's recommendation for unique serialNumber.
According to the CycloneDX specification, every SBOM generated should have a unique serial number, even if its contents have not changed over time.

We had an issue because several SBOMs generated with the Plugin did not change its serialNumber since the SBOM itself did not change at all.
Now, looking at the coding of the Plugin I see that the generateSerialNumber function generates reproducable serialNumber.

cyclonedx-maven-plugin/src/main/java/org/cyclonedx/maven/BaseCycloneDxMojo.java

Lines 425 to 438 in ad5624e

	private String generateSerialNumber(List<Property> properties) {
	String gav = String.format("%s:%s:%s", project.getGroupId(), project.getArtifactId(), project.getVersion());
	StringBuilder sb = new StringBuilder(gav);
	if (properties != null) {
	for(Property prop: properties) {
	sb.append(';');
	sb.append(prop.getName());
	sb.append('=');
	sb.append(prop.getValue());
	}
	}
	UUID uuid = UUID.nameUUIDFromBytes(sb.toString().getBytes(StandardCharsets.UTF_8));
	return String.format("urn:uuid:%s", uuid);
	}

Could you please generate the serialNumber to not be deterministic to conform with the CycloneDX specification?

[ppkarwasz]

@MeikelVielhauer,

Could you explain more your use case? Why do you need several SBOMs for exactly the same Maven artifact?

According to the CycloneDX specification, every SBOM generated should have a unique serial number, even if its contents have not changed over time.

The specification also has a version property, which is defined as:

Whenever an existing BOM is modified, either manually or through automated processes, the version of the BOM SHOULD be incremented by 1. When a system is presented with multiple BOMs with identical serial numbers, the system SHOULD use the most recent version of the BOM. The default version is '1'.

The reason behind the deterministic algorithm to compute a serial number is reproducibility: this allows users to verify that the published SBOM is identical to one generated from source.

[chrsch-dev]

Hi, the SBOMs are created in our CI/CD pipeline. With every build also a SBOM is generated using this plugin and the pipeline doesn't have any information about previously created SBOMs.

Since we have some projects which don't increase their version with every pipeline run your implementation of generating the serial number leads to the same SBOM serial number and the same version.

Regarding your reproducibility use case: Why not use the purl of the built component from the metadata part of the SBOM? This would be for me the indicator whether it is an SBOM describing exactly the same artifact.

[stevespringett]

Not sure when random uuids were removed, but the above code violates the spec for most people. That code would likely produce the same serial number for every SNAPSHOT build. Please keep in mind that the authors of the NTIA framing document were not favorable towards reproducibility as the practice typically sacrifices critical data at the expense of reproducibility. To some, it’s an anti-pattern.

If a CI doesn’t have a record of prior builds of the same version (and most won’t), then the serialNumber should be unique between builds. Perhaps this is an enhancement to the docs in the spec.

I would recommend making this a configurable option. For the folks that want predictability, they can misuse the spec by enabling this functionality.

[ppkarwasz]

Not sure when random uuids were removed

This behavior was introduced to solve #420, since the previous behavior was to skip serialNumber entirely (see #226).

I would recommend making this a configurable option. For the folks that want predictability, they can misuse the spec by enabling this functionality.

Should the option support all three behaviors (i.e. deterministic, random or no serialNumber)?

Personally I am not strongly opinionated regarding the reproducibility of SBOMs, but reproducibility allows to perform some basic quality checks on the released SBOMs. I have seen multiple SBOMs with invalid checksums, because the release manager didn't clean his diaper (i.e., ~/.m2/repository) before the release.
Recently I introduced an independent <checksum> check to my SBOM Enforcer plugin, so reproducibility might no longer be necessary.