By now, you’ve probably heard the term software bill of materials (SBOM). It’s become the security buzzword of the year. Let’s look a little deeper into what an SBOM is, what it contains, how it is used, and how the industry plans to exchange them.
NTIA definitions
The latest executive order from President Biden has tasked the National Telecommunications and Information Administration (NTIA) and the Commerce Department with defining the minimum elements of a SBOM, considered critical to improving transparency and security in the software supply chain. In this post, I am going to rely on the NTIA definitions and sources since they are the current focal point of the software industry for defining and standardizing SBOM definitions and how they are to be used and exchanged.
The NTIA definition is as follows:
A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software. These components, including libraries and modules, can be open source or proprietary, free or paid, and the data can be widely available or access-restricted.
Source: NTIA SBOM FAQ
The important parts of the definition are “formal record,” “supply chain relationships” and “open source or proprietary.” Formal is important because the SBOM needs to be a precise software development artifact designed to be interchanged with other companies, the government and available for security audits. Supply chain relationships are important because we need to understand where software comes from, is it open source? Commercial? What versions? Lastly, SBOMs apply to more than just open source software as commercial off the shelf (COTS) software may actually be even more important because of hidden risks.
Why SBOMs?
The heightened awareness of supply chain security and SBOMs are a good thing but software organizations might still be questioning their usefulness. They may agree to supply them but fail to see downstream benefits. So why should your organization insist on SBOMs from your software suppliers? Why should you start creating them for your products or the applications you are using today? Consider these benefits:
- Identifying and avoiding vulnerabilities in reused components in your own developed software and software purchased by your organization.
- Managing software supply chain risk to remove and reduce the unknown security risk in reused software. SBOMs provide data for business decisions on software purchases and open source reuse.
- Supply chain qualification to ensure consistency and accountability from suppliers. Suppliers than meet the SBOM requirements during procurement are given preferential treatment.
- Improved security and downstream benefits that come with risk management and mitigation. Avoiding and catching security risks before they become embedded in their product pays huge dividends during development and deployment of your products.
- Common understanding of software assets that comes with a standardized SBOM amongst software developers, suppliers and open source projects. SBOMs become a way to communicate software contents and dependencies within and outside an organization.
What’s in an SBOM?
The NTIA has been tasked to define the minimum requirements of an SBOM and we’ll use that here. Included in this work is not just the data requirement but automation support (i.e. enabling tools support) and associated practices and processes.
- Author Name: The author of the SBOM, usually the organization supplying the software.
- Supplier Name: The name of the software supplier and should include aliases. Supplier and author might be different if the supplier is making a claim on behalf of the author.
- Component Name: The name of the software component and possible aliases.
- Version String: The format of the version information is free form but should follow common industry usage.
- Component Hash: The best way to identify a component is the use of a cryptographic hash that acts like a unique identifier. The specifics of these are usually defined by the interchange formats agreed upon by the industry.
- Unique Identifier: A unique identifier is needed for each component.
- Relationship: The relationship field defines the relationship between the component and the software package. In most cases, this relation is “includes” as in software package X includes component Y.
Going beyond these minimum requirements, software supply chain security platform like GrammaTech CodeSentry include vulnerability information with each component. These include:
- Component Match: This is the degree of confidence from the matching algorithm used by CodeSentry. Since the SBOM is automatically generated from binary code, matching to known components does have some degree of error.
- Security score: Based upon identified components and discovered vulnerabilities ranked by criticality, a secure score is generated to highlight the risk of the software application.
- Path: The file path of the component.
- CVE Distribution: The distribution of discovered vulnerabilities by criticality (critical, high, medium and low.)
CodeSentry creates a vulnerability report as part of the SBOM generation which identifies vulnerabilities in the components. These vulnerabilities are uniquely identified and include descriptive information:
- Severity: The vulnerability severity from its CVE entry based upon CVSS scoring.
- CVSS score: The common vulnerability scoring system value, between 0.0 and 10.0, which is used to prioritize vulnerabilities. The higher the score, the more likely the vulnerability is to be exploitable, have a large impact and inflict damage in a large area of the application or product. Critical vulnerabilities are in the 9.0-10.0 range.
- CVSS version: The CVSS has been updated over time so the version is important when looking at vulnerabilities with the same score.
- CVE ID: The unique identifier for a vulnerability’s entry in the national vulnerabilitiy database.
- Description: The text description provided by the CVE entry.
An example output from CodeSentry is shown below:
A vulnerability report shows the N-day findings from a software package with more details on each vulnerability:
How do we use SBOMs?
The purpose of SBOMs is to share a detailed report of what components and vulnerabilities are in the software with customers, partners and internal stakeholders. Software vendors need to make SBOM production, disclosure and sharing part of their everyday deployment process. Solutions, like CodeSentry, are up to the task of automating the process to integrate it into cybersecurity and risk management processes. Lets’s dig into the sharing process and then the general use cases.
Generation
Automation is key to SBOM generation. With solutions like CodeSentry its now possible to perform software composition analysis on binary objects even when source code isn’t available. SBOM generation should be part of any due diligence process when acquiring software for enterprise use. It should also be part of your software development life cycle (SDLC) if you are developing software for commercial purposes, so that your software products have up-to-date vulnerability disclosures and updates on new n-day weaknesses.
Disclosure
Disclosure of SBOMs might be considered a tricky matter for proprietary software. In the case of open source software, it should be publicly available and updated with each new release. Commercial software vendors might disclose their SBOMs through customer support channels, for example. However, software organizations might be hesitant in making SBOMs public but as the NTIA points out:
…the defensive benefits of transparency far outweigh this common concern as SBOMs serve more as a “roadmap for the defender”. All information is dual-edged, but insufficient software transparency affords attackers asymmetrical advantages.
Source: NTIA SBOM FAQ
Sharing
Once the disclosure mechanism is established the details of sharing the artifact need to be considered. Ideally, it should be packaged with the products whether that is a binary or source format and made available to download via a trusted download site. Sharing between organization implies the need for a standardized format which makes interoperability and tool compatibility easier. There are several emerging standards for SBOM interchange such as Software Identification (SWID), Software Package Data Exchange (SPDX) and CycloneDX.
SBOM Use Cases
The use cases for SBOMs differ slightly depending on the role of the user of the software. SBOMs are also a byproduct of product development so developers are both consumers and producers of SBOMs. Here are some SBOM use cases from the different user perspectives.
Software Developers: Developing software today means reusing third-party and open source software. It’s impossible to understand the risk of the software supply chain without the transparency the SBOM provides. Developers use SBOMs to gain understanding of the reused software and the inherent dependencies of that software. Every component is like an iceberg where most of the dependencies are hidden under the waterline. SBOMs communicate the depth of dependencies and highlight vulnerabilities hidden in there. Developers use SBOMs to understand and mitigate the risk that software reuse brings.
Software developers produce SBOMs as a by-product of development and pass that on to their consumers. They use SBOMs to transparently communicate their supply chain risks to their customers.
Software Consumers: Consumers of software are concerned about the security risk from commercial software they rely on for all functions of the business. Organizations that rely on enterprise platforms, for example, use SBOMs to manage the security risk of procured software. A vulnerability in the platform becomes a potential attack vector that must be addressed. They use SBOMs to be made aware of vulnerabilities in dependencies not immediately apparent in their software stack. They use SBOMs to track suppliers, product versions and vulnerability updates.
Summary
A software bill of materials is a list of components that make up a software product and a whole lot more. They contain the primary list of components for your product but also all the dependencies each of those components bring to the table. SBOMs along with vulnerability reports, provided by solutions like GrammaTech CodeSentry, provide a transparent way to communicate supply chain risk from organization to organization.
Industry standards are coalescing around the work the NTIA is doing in terms of basic elements of the SBOM, use cases and interoperability. Generally improving the software supply chain requires software product suppliers to make SBOMs a standard artifact of software development, integrated into deployment and delivery with standardized formats.
