Today’s software is extremely complex – and with the pervasive use of third-party components, it’s become extremely difficult for anyone to keep track of all the external code in their systems.

Pieces of code that aren’t written by your own developers.

These components are assembled by engineers and can potentially make up the majority of the software we build every day. For everyone outside the engineering organization? They may not even know what these third-party components are – or that they are even being used. This lack of visibility into what these components are and where they come from can become a huge risk.

Enter the Software Bill of Materials – or SBOM – a document or collection of documents which can provide an extensive inventory of all the components and their dependencies in our systems and software we build. They can enable organizations to identify security vulnerabilities, ensure compliance with licensing or contractual requirements, and manage risks associated with third-party components.

Not only do we produce software, but we also consume it from our vendors and suppliers. In this light, SBOMs can help organizations understand what we are purchasing from vendors and during a security review, we can infer tech debt and hygiene, and understand the risk we take on by purchasing software and rolling it out in our ecosystems – and we can also take proactive measures to mitigate those risks.

There’s been so much conversation about the supply chain and Software Bill of Materials that it can seem overwhelming. How do we create them, how do we ask our vendors for them, what do we do with these things once we get them? Why are there so many types of BOMs?

What I’m looking for is answers and although I think we’re on the right track, I’m not convinced that SBOMs – along with other variations such as SaaSBOMs, xBOMs, *BOMs, or even daBOMs are leading us in the right direction.

Maybe we’re just over complicating things?