What is an SBOM?
Software Bill of Materials
"A formal record containing the details and supply chain relationships of various components used in building software."
— The Minimum Elements For a Software Bill of Materials (SBOM),
The United States Department of Commerce
The Case for SBOMs
With high-profile supply chain attacks, like the SolarWinds incident in 2020, and Executive Order 14028 that soon followed, there is growing awareness of Software Bill of Materials — or SBOMs and the role they must play in software supply chain security.
Supply Chain Attacks - a Great ROI
Attackers have recently targeted the software supply chain as an effective vector for accessing large numbers of victims via a single target. Rather than attack high-value (and likely well- defended) quarries directly, adversaries are choosing to go after their more lightly defended suppliers. By compromising a software component that is widely used, they can multiply the scope of their intrusion.
| Incident | Direct Target | Indirect Victims | Time Undetected |
|---|---|---|---|
| SolarWinds | 1 | 18,000 Infected ~250 Exploited |
10 Months |
| Dragonfly | 3 | 250-700 | 9 Months |
| Kaseya | 1 | 800-1500 | N/A |
| Codecov | 1 | 23,000 Possible 200 Likely? |
2 Months |
With this type of attack on the rise, it is critical that organizations know all the components that comprise their software — all the 3rd-party code, libraries, OSS, etc.
Regulatory Pressure to Provide SBOMs
The U.S. federal government got busy with regulations in response to this type of attack. SBOMs are now mandatory to do business with the US federal government, as laid out in EO 14028.
More recently, NIST SP 800-161 — Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations — provides further guidance for organizations on identifying, assessing, and mitigating cybersecurity risks throughout the software supply chain.
Increasingly, private industry is expecting the same level of transparency from their providers. Concerns about inherited risk and potential liability from embedded components have prompted industry to demand more transparency from their providers.
A Rapidly Maturing Regulatory Environment
SBOMs for Critical OT Systems
The National Security Memorandum on Improving Cybersecurity for Critical Infrastructure Control Systems (July 2021) specifically focused on “OT” or operational technology (as opposed to “IT” or information technology, which most people are more familiar with). Also referred to as ICS (industrial control systems), these are the systems that underpin modern society: energy, transportation, manufacturing, health, etc. These systems have a different history from IT: there are more suppliers, more operating systems, and more protocols; altogether it is a much more heterogeneous environment.
SBOMs for Legacy OT Systems
When you have decades of products from hundreds of different suppliers (many of whom lost their source code long ago), getting an SBOM for legacy software and firmware can be a challenge. Unfortunately, this is the case across many critical industries where the service life of equipment runs to decades.
As such, vendors often can’t (or sometimes won’t) provide SBOMs for critical OT systems, leaving asset owners to assume all the security risk. There are, however, solutions for obtaining SBOMs for legacy systems.
Binary Composition Analysis (BCA)
Source code is not necessary to analyze software. Binary Composition Analysis (BCA) can produce SBOMs.
BCA is the process of analyzing the composition of binary code — or compiled code, such as executable files or libraries. It can determine the presence of known vulnerabilities, assess the security of the software, and evaluate the risk posed by the software to an organization.
BCA techniques can range from the simple (e.g., checks for known signatures) to the complex (e.g., methods that dynamically analyze files and components to uncover new or previously unknown vulnerabilities). SBOMs produced via BCA can be used to prioritize remediation efforts and help organizations improve the security of their software systems.
How to Use SBOMs
SBOMs are becoming increasingly available from OT suppliers, but the question has arisen: can asset owners actually use SBOMs to improve security or are SBOMs just bureaucratic paperweights?
SBOMs are a critical first step to improve visibility into your software supply chain: your suppliers, their software, and the components they embed in their products. But without the proper tools, security analysts will find it taxing to use SBOMs effectively.
SBOMs Provide Transparency, Not Risk Analysis
An SBOM can provide a list of ingredients — but it can’t tell you if those ingredients are good for you.
Once you have an SBOM that reveals all the components within your software, you still need to determine which of those components may be introducing risk to your facility:
- Does the component contain vulnerabilities?
- Is the component from a black-listed vendor or country?
- Is the component signed with a fraudulent signature?
- Does the component contain malware or ransomware?
Vulnerability Management
Typically, the primary use of an SBOM is to reveal subcomponents within a product that may contain vulnerabilities. Because vulnerabilities are constantly being uncovered and disclosed via multiple mechanisms, vulnerability research is a continuous process.
The usual first place to begin vulnerability research is the National Vulnerability Database (NVD) — the U.S. federal government repository of vulnerability management data. The NVD is intended to enable vulnerability management, security measurement, and compliance automation.
Unfortunately, relying solely on the NVD is problematic for critical OT/ICS systems:
- The NVD is incomplete; over 75% of ICS vulnerabilities are estimated to be missing.
- The NVD rarely maps component vulnerabilities back to the products that contain those components.
- The vendor name that appears on a product in a facility is frequently different from the vendor name you’ll see in the NVD details or the CPE listing.
Even for seasoned security professionals, manually trying to match vulnerabilities against actual installed products (or the other way around) is inefficient, error-prone, expensive, and beyond boring. As a result, organizations face surprising challenges when they actually try to associate data in an SBOM to real world vulnerability databases like the NVD.
Making SBOMs a Part of an Overall Cybersecurity Program
SBOMs on their own have limited value; the important thing is how you use them and how they inform other systems in your cybersecurity program. Whether supplied by a vendor or generated from BCA, SBOMs enrich your asset management systems to provide a detail vision of all the software present in your environment.
© 2023 SBOM.com