The need for SBOM — Part 1

Transparency is the fundamental challenge in securing software with unknown composition, and SBOM, at its core, is attempting to solve this.
March 1, 2023

In 2023, the Software bill of materials (“SBOM”) continues to dominate the conversations related to software disclosure and security. While there are alternate approaches to the software disclosures, SBOM has been vetted by a multistakeholder group run by National Telecommunications and Information Administration (NTIA) in a multi-year process and is therefore considered appropriate and effective for reducing the cybersecurity risks at machine speed. It might be worth going through a double-click to understand how that is so.


Since 1999, MITRE has managed a list of publicly disclosed cybersecurity vulnerabilities using specially designated IDs called Common Vulnerability Enumeration (“CVE”).

CVEs cover a wide variety of hardware, software, and their components, such as CVE-2013–4632: denial of service vulnerability in Huawei Access Router (AR), CVE-2022–30190: remote code execution vulnerability in Microsoft Windows Support Diagnostic Tool (MSDT) and CVE-2022–44054: a potential code-backdoor in d8s-xml PyPI package.

Security researchers continuously look for new vulnerabilities in publicly available software and hardware products and record them with CVE to be patched by the developers building those products.

MITRE’s CVE List includes the National Vulnerability Database (“NVD”), a U.S. government repository of standards-based vulnerability information. NVD is based on and is fully synced with MITRE’s CVE list.

This ecosystem allows any product and version to be checked against NVD for all known vulnerabilities. This product name/version of the vulnerability map has been the foundation of vulnerability management programs for nearly two decades.

But, of course, there is a challenge.

Software Supply Chain

Modern hardware and software are rarely written from scratch. A typical application is composed of pre-built open-source or third-party commercial components. For instance — iPhone 14 includes Samsung’s display panels, Sony’s image sensors, Qualcomm, Broadcom, and Skyworks components, while Solarwinds Network Configuration Manager (NCM) application includes ActiveSkin, UltraToolBars, and Log4Net, among others.


The components can depend on sub-components supplied by another layer of open-source or commercial vendors. Log4Net uses another open-source library, qs, for query parsing.

This commercial or open-source component dependency chain can make vulnerability lookup less effective. Unless SolarWinds NCM composition is known, a lookup by the product name — Network Configuration Manager — will not be able to surface underlying vulnerabilities of qs because of the nested dependencies (NCM includes Log4Net that in turn includes qs).

This is the fundamental challenge in securing software with unknown composition, and SBOM, at its core, is an attempt to solve this.

In Part 2 — How SBOM decomposes and expresses programmable components to accurately assess its compliance and security risks.