For a long time I was preaching the idea that an SBOM can and should essentially be split into 2 parts.
The first part is static – that is the actual list of all software components with their fixed metadata (version, purl, hashes, etc).
The second part is dynamic – that is things related to vulnerabilities, mainly VDR and VEX.
As time goes by, new vulnerabilities are discovered. Therefore, VDRs and VEXes are constantly updated, while the actual software composition part of SBOM remains fixed. That was essentially my message. It sounds nice and is easy to understand.
But if we zoom in on the details, it turns that calling the first part “static” is a lie. So what’s not so static in the “static” part of the sbom?
- Spelling mistakes – This may seem obvious but can sometimes be very important. In extreme cases, such errors can lead to or be a symptom of a dependency confusion attack.
- Missing or “ghost” components – These are usually due to glitches or misconfiguration in generation tooling, but again may also indicate deeper issues.
- Lifecycle changes – For example, if a component is no longer supported, that information has specific time point when it becomes actual. This also includes lifecycle changes related to the component’s supplier.
- Licensing mistakes and / or changes – It is possible that a license of a component was concluded incorrectly at the time of SBOM creation. Additionally, legal interpretations can evolve, or a vendor might retroactively apply a more permissive license to an older release.
- SBOM format updates and enrichment – As new versions of CycloneDX standard are released, it is natural to be willing to upgrade SBOM to a newer standard version. That same new standard may also require new data or previously unknown data may now become available – i.e. a sub-component or a new hash definition. All of this could justify updating the SBOM.
This list is by no means exhaustive, but it is large enough already to demonstrate why the part of the SBOM I often referred to as “static” is, in fact, subject to change.
One question that becomes clear here is that SBOMs need versioning (which the CycloneDX standard supports). The second question is how to approach the versioning. If we claim that we’ll update the SBOM for every single change, we quickly face a combinatorial explosion problem – too many unorganized versions per SBOM.
How we are solving this with ReARM by Reliza (this logic will become more visible in the next major update):
- We make sure that the original uploaded raw SBOM is preserved and remains intact.
- If the user uploads a new SBOM version, it is accepted as the new latest version, while the previous versions are still preserved.
- Part of the SBOM augmentation and enrichment logic happens dynamically inside the tool. By default, users download latest augmented and enriched SBOM by ReARM / Rebom. However, users also have the option to download the raw SBOM – which must be preserved, at the very least, for auditing and proof of existence.
- Any augmented and enriched SBOM downloaded by the user is also preserved in the system – for reproducibility, auditing and proof of existence.
This understanding that we currently have at Reliza may still evolve, but I believe it provides a solid foundation for addressing the SBOM versioning challenge going forward.