What should we use for SBOM version?

[vpetersson]

In CycloneDX you have a version field that should be incremented for each version of the SBOM. This is set to 1 by most tools. SPDX does not have the equivalent of this as far as I can tell.

Since this number needs to increment for each build, two approaches was discussed:

• I've used $GITHUB_RUN_NUMBER for this, but this is GitHub specific (GitHub Variables). The drawback with this is that it is GitHub specific (all CI systems may not have an equivalent).
• An alternative solution is to treat .version as the same as .metadata.component.version and set it to a SemVer. This is usually fine, but might potentially create two SBOMs with the same version but different values (if you rebuild the same job).

[douglasdennis]

I'm trying to track the use case here. In CycloneDX, you would only increment the top-level version if you are modifying an existing SBOM. I would not increment the version on each new build. Instead I would assign a new serial number to the new BOM. Here is a relevant discussion and answer from the CycloneDX folks: CycloneDX/specification#363 (comment)

SPDX doesn't have a version field because they solely track identity through an ID field. I believe you would generate a brand new ID for each revision.

[vpetersson]

I'm trying to track the use case here. In CycloneDX, you would only increment the top-level version if you are modifying an existing SBOM. I would not increment the version on each new build. Instead I would assign a new serial number to the new BOM. Here is a relevant discussion and answer from the CycloneDX folks: CycloneDX/specification#363 (comment)

Good discussion. While that advice make sense when you're manually managing SBOMs, it's not really realistic when the CI/CD is building/managing SBOMs. Since each CI/CD run can in theory change components (e.g. dependencies/sub-dependencies get bumped as they're not fully pinned). This is why I would still consider each run a new version and diffing two versions may result in no change, but the alternative is that need a lot of manual work.

SPDX doesn't have a version field because they solely track identity through an ID field. I believe you would generate a brand new ID for each revision.

Yeah, I didn't manage to solve this for SPDX. The lack of version makes it a lot harder to track. I presume you have to resort back to using the date.

[douglasdennis]

While that advice make sense when you're manually managing SBOMs, it's not really realistic when the CI/CD is building/managing SBOMs. Since each CI/CD run can in theory change components (e.g. dependencies/sub-dependencies get bumped as they're not fully pinned). This is why I would still consider each run a new version and diffing two versions may result in no change, but the alternative is that need a lot of manual work.

I would consider each run to be a new BOM and so it would get a new serialNumber. The referencing system in CycloneDX does not allow you to disambiguate between different verisons. If you have a shared serialNumber with incremental versions then you cause an issue where the lower version BOMs can no longer be referenced by other BOM documents.

[vpetersson]

I would consider each run to be a new BOM and so it would get a new serialNumber. The referencing system in CycloneDX does not allow you to disambiguate between different verisons. If you have a shared serialNumber with incremental versions then you cause an issue where the lower version BOMs can no longer be referenced by other BOM documents.

I think I see what you mean. However, most tools that I've played with just use a random UUID as the serialNumber for each run. It's not sequential as per the docs.

Imagine we were to run our single CI/CD run in three different jobs that may trigger by different changes for the sake of argument. You'd then have:

• Application SBOM (with unique version/serial number)
• Container SBOM (with unique version/serial number)
• Top-level SBOM (with unique version/serial number)

If you were to rebuild the container SBOM, that should in turn trigger a rebuild of the top-level SBOM. At this point, we'd have to pull in the lastest SBOM from both the application and container (while only the container changed).

In this case, the version/serial number would change for the top-level SBOM and the container SBOM, but not for the application SBOM. Now, if we have separated version and the metadata.component.version value, this becomes pretty straight forward.

Or maybe I'm overlooking something in your argument.

In SPDX however, this is an entirely different beast, and I'm yet to solve that. It appears that SPDXID is just a UUID, but I haven't spent enough cycles on that yet.

[vpetersson]

After today's meeting, I am reversing my comments. Thank you @idunbarh for clearing up this.

Here's a recap:

• version should be reverted to 1 on each new semver.
• The only use case for version if you need to alter an existing SBOM. In which case it should be done as follows:
  • Reuse the same SerialNumber
  • Bump the version one step
• For all other releases, it should be set to 1 and metadata.component.version should be used to track builds.
  • In the case of CI/CD for multiple releases of the same semver, $SEMVER-$CI_RUN or similar can be used (thanks @dasarpjonam)

[idunbarh]

I think this issue can be closed due to the discussion. @vpetersson let me know if you want this to remain open.

[vpetersson]

I'm happy to keep this closed.