Writing software or software components from scratch is rare in modern software development. Pre-existing libraries and frameworks provide the base for developing new features and functionalities, and this new product can become the base for another product.
However, this layering of software and components can create blindspots for the developer and consumers. In Part-1, we discussed how layering creates a challenge in identifying zero-day vulnerabilities (experienced worldwide with log4shell).
Other risks are associated with the software of unknown composition, including:
- the risk of including components with a restrictive license
- end-of-life components, or
- components influenced by nation-state actors.
Manufacturing has dealt with similar concerns in supply chain and inventory management by building Build of Materials (BOM), Obsolescence Management, Product change notification (PCN), and End-of-life (EOL) management.
SBOM is bringing that learning and practices to software development.
At its core, SBOM is a document describing the components of the software, their suppliers, and component relationships (layering), along with some metadata to make sense of it all.
CISA recommends building SBOM to existing specifications:
These specifications are very flexible, and therefore, CISA has also recommended minimum elements for an SBOM to ensure that generated SBOM can be used to address the risks mentioned above.
A complete SBOM can help solve the following problems:
1. Component Inventory A complete SBOM includes all of the components, including the nested components, and therefore can build component inventory for the product.
2. License Inventory A complete SBOM includes all of the licenses associated with each component and, therefore, can be used to build and monitor license inventory. This is a critical part of managing risks associated with open-source licenses.
3. Vulnerability Management A well-described component in an SBOM follows widely used component naming conventions such as CPE, PURL, or SWID tag. An exact component name can be used for vulnerability lookups from databases such as NVD and OSV. Because SBOM supports nested relationships (and many more types of relationships), this solves the vulnerability lookup problem described in Part-1.
4. Obsolescence and End-of-life Management As the product ages, building component inventory enables SBOM to track obsolete or EOL components.
5. Vulnerability Exploitability Disclosure SBOM can be combined with VEX to communicate the status of vulnerabilities associated with the product. This helps reduce noise in cases where software composition analysis tools scan a product. An introduction to vulnerability exploitability disclosure is here.
SBOM potential has been clear to organizations building them. However, several use cases described above include phrases.: complete SBOM , well-described component and exact component name .
Building a complete SBOM or using an exact name for a component is a real challenge. These challenges may frustrate early adopters or create disingenuous push-back against SBOM.
In Part 3 — How SBOM Challenges are Opportunities and not Risks.
