If you are in IT and cybersecurity, you may have heard the term software bill of materials (SBOM) increasingly being used. This may not be a new concept for everyone, but it is for some business and technology professionals.
BOM vs. SBOM
The bill of materials (BOM) has been part of manufacturing for years. It is utilized to track subcomponents for an end product and is applied to the broader supply chain management practice.
As technology organizations look to apply lessons learned from the manufacturing industry, an SBOM can help maximize productivity, standardization, and quality. Much like a manufacturing BOM, an SBOM is a “machine-readable inventory of software components and dependencies, information about those components and their hierarchical relationships”.
SBOM: a machine-readable inventory of software components and dependencies, information about those components and their hierarchical relationships
SBOM: a machine-readable inventory of software components and dependencies, information about those components and their hierarchical relationships
In truth, SBOM has been part of public discourse for over a decade. However, it is getting renewed attention through work by the National Telecommunications and Information Administration (NTIA), the SolarWinds breach, and mentions in the recent “Executive Order on Improving the Nation’s Cybersecurity.” The Executive Order intends to enhance supply chain security, with key provisions providing software purchasers with an SBOM. Whenever federal acquisitions include new requirements in this way, they tend to create cascading impacts on other industries.
Improving the Discovery Process
SBOM provides insight that might otherwise require a lot of manual effort to discover. As new vulnerabilities are disclosed, organizations don’t have a straightforward way to determine if they are impacted or the location of any vulnerable/compromised software. With an SBOM, this discovery process is improved and organizations can quickly begin remediation or mitigation efforts to ensure their organization isn’t harmed. Organizations use a myriad of proprietary software, with more than 90% utilizing open-source software in application development. SBOM provides critical insight into organizational software components, many of which contain critical and unaddressed vulnerabilities.
When developing internal applications, organizations should consider what software they’re selling to customers, purchasing from vendors, and sourcing from the Web. With the push for SBOM in the Cyber Executive Order, not only will government purchasers begin to ask about SBOM’s, but commercial customers will as well. Software vendors are a core part of the software supply chain and third-party risk management; without transparency, there could be a perpetual blind spot. The same can be said for open source projects. Software consumers must evaluate the software they use, which could contain unknown vulnerabilities and introduce risk to the organization.
Not only are software vendors beginning to offer SBOMs due to consumer demand, but the industry is maturing in this regard as well. Another effort underway from NTIA, called the Vulnerability Exploitability Exchange, seeks to provide additional guidance regarding whether a product is impacted by a specific vulnerability included in its components, and if so, what actions can be taken to remediate them.
Final Thoughts
SBOM’s offer critical insight for software producers, consumers, and operators from the perspective of visibility and vulnerability management, as well as benefits like licensing. They also shine the bright light of transparency on a complex ecosystem and supply chain that can have devastating and cascading impacts in countless ways. As it’s sometimes said, transparency increases credibility and accountability.
