Why do we need SBOMs?
Most of an application is code that someone else wrote
Most applications today are built largely from third-party components, often open source. It saves time, but it also means that a vulnerability or an unsuitable licence in a single component comes along into the product.
Log4Shell
Log4j is a logging library for Java that is used in a very large number of applications. In December 2021 the Log4Shell vulnerability was discovered. It allowed an attacker to run their own code on systems that used the library.
What took time for most organisations was not updating the library but finding out where it was. Log4j often came along as a dependency of other libraries, and in purchased products it was not visible from the outside at all. Those who had an SBOM for their systems could search for the component and get an answer straight away.
More examples
- Heartbleed (2014). A vulnerability in the OpenSSL cryptography library that allowed sensitive information to leak from servers.
- Apache Struts (2017). A vulnerability in the Struts web framework was exploited in the breach at the credit reporting agency Equifax, where data on more than a hundred million people was exposed.
- Spring4Shell (2022). A vulnerability in the Spring Framework that made it possible to run code on servers.
What the examples have in common is that the vulnerability was in a component that many used without having it recorded anywhere.
What an SBOM changes
With an SBOM for every version of every product, the question "are we affected?" can be answered with a search. That applies to software you build yourself and to software you buy, provided the supplier delivers an SBOM.
The same record is used to check licences and to meet requirements in regulations such as the Cyber Resilience Act (CRA).