As I become increasingly involved in SBOM generation and management, I plan to publish a series of posts exploring the current state of SBOMs, the key challenges, and how we at Reliza are addressing them.
This is the first post in these series where I would like to discuss just how many SBOMs we actually need.
I Why we do SBOMs
Reasoning as to how many SBOMs we need should start with goal setting – why do we need them in the first place? Here are the most common goals for using SBOMs overall:
- Describe all software dependencies for internal continuous vulnerability and violation analysis. SBOM in this case can be thought of as a snapshot of a software project captured at specific point in time.
- Audit requirements – this is when we need to “go back in time” and request SBOM for a specific older version of our project capturing older states. This may happen for any reason, in example, European CRA is going to make this a legal requirement.
- Sharing dependency data with clients or partners. This assumes they would do dependency analysis on their side. This usually happens for marketing, contractual, compliance reasons or some combination of those.
II Level of Detail
The important observation here is that every option requires different level of detail.
In example, for the purposes of internal analysis we may want to consider all dependencies, including those that are only used in internal tests. This likely would not be the case for the audit requirements. Even less detail is usually needed when sharing SBOMs with partners or clients – frequently only Top Level Dependencies are required in this case – in example, for US Executive Order 14028.
This essentially gives us first split criteria – namely, level of detail.
III Scope
Another observation I made in practice – when using common tools, you are frequently not getting the same result when generating an SBOM from the source code vs generating it from a container image built on top of the source code.
So a practical choice would be to build a bill of materials from the source code and another one from container. It is further possible to split the source code SBOM into several parts – for example, one including test dependencies and the one without those.
Look at this visualization for one of related proposals in the Python community. This is just one of the proposals how the scope split may look like.
IV Different Branches, Releases, Versions
Finally, any code base is perpetually changing. So every software component at any point of time has its own bill of materials. And then there are combinations of components.
It is pretty obvious that we need different SBOMs for all those various versions.
V Management and Aggregation
I hope I showed above that there is a real need to have several SBOMs to represent a single software release, let alone a software project or product – where thousands or even millions of documents may sometimes be required.
Now, let me briefly go over the modern tooling ecosystem:
- I personally support and advocate for CycloneDX JSON format, which can be generated with
cdxgenand several other tools. cyclonedx-cliprovides an option to merge different bills of materials from the command line.- OWASP Dependency-Track provides ingestion and analytics capability. However, it does not store raw SBOMs.
What is missing – ability to store everything in one place, including raw documents, and quickly pull required SBOM for any version of any product with required level of detail and aggregation.
At Reliza, we are currently launching a closed Beta of our new product which does just that. Stay tuned and keep following this blog for more details or contact me on any social platform to participate in the beta.