What is an SBOM?

SBOMs have been part of the open-source community for more than a decade, but they’ve grabbed more attention in cybersecurity circles since the wave of software supply-chain attacks on U.S. companies and government agencies in 2020 and 2021.

The SolarWinds hack, in particular—where federal agencies including the Department of Homeland Security and the Treasury Department had unwittingly deployed a trojanized component that enabled the attackers to gain access to victims’ computer systems—prompted an executive order in May 2021 requiring that any vendor selling software to the federal government detail its components in an SBOM.

Due to the intricacy of the software supply chain, a single software component can have an outsized impact on its security. But users have minimal visibility into the components nested in their most business-critical apps. Having a list of product “ingredients” can give them a better idea of their security risks and provides a roadmap for tracking down vulnerabilities before they create a crisis.

Know all your software supply chain vulnerabilities. In seconds.

What is the origin of SBOM?

The new emphasis on SBOMs came from President Biden’s Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, which charges the National Institute of Standards and Technology (NIST) and other federal agencies with enhancing cybersecurity through a variety of initiatives related to the security and integrity of the software supply chain, in order to better protect federal government networks.

The EO was largely a response to the surge of cyberattacks on U.S. companies and the U.S. government in 2020 and ’21. Attacks during that period were more frequent and more severe, with two of the most detrimental—SolarWinds and the Colonial Pipeline ransomware attack—spurring the EO.

In the SolarWinds attack, a single trojanized component in the Texas-based company’s Orion software, which is used to monitor and manage IT networks and infrastructure, allowed hackers to access the systems of thousands of organizations, including Fortune 500 companies, multiple federal government agencies, and even the U.S. cybersecurity firm that eventually detected the breach. Up to 18,000 private- and public-sector victims downloaded the infected software, though fewer were subsequently compromised.

The Colonial Pipeline ransomware attack targeted a single organization but had a far-reaching impact on the country’s infrastructure. When the company, which supplies about 45 percent of the East Coast’s fuel, discovered the attack, it was forced to take critical computer systems offline to contain the threat, effectively shutting down its operations. The resulting fuel shortages caused a rush of panic-buying and a spike in gas prices.

[Read also: What the Biden executive order means for tech executives]

The EO reflects lessons learned from these and other security incidents and seeks to foster public and private-sector collaboration to mitigate increasingly sophisticated cyberattacks. Specifically, it outlines several objectives:

• Enhance information sharing—The EO directs that any contractual barriers to threat information sharing between the government and the private sector be removed and requires that IT service providers share information about threats, vulnerabilities, and incidents that could potentially impact the federal government.
• Modernize government cybersecurity—The EO charges the federal government with instituting stronger cybersecurity standards and best practices. These include adopting secure cloud services, employing a zero-trust security model, and implementing multifactor authentication (MFA) and encryption routines.
• Strengthen software supply chain security—The government is to establish baseline software development security standards for the software it procures from contractors. The Commerce Department and the National Telecommunications and Information Administration (NTIA) must publish elements for a software bill of materials that lists and details the individual components that make up a software product.
• Establish a cybersecurity safety review board—The government will create a board to be co-chaired by government and private sector experts that will convene following a significant cybersecurity incident to analyze what happened and to make recommendations for security improvements.

[Read also: The U.S. government’s battle plan to fortify supply chains]

• Create an incident response playbook—Government IT leaders must develop a standard playbook for responding to security incidents to ensure all federal agencies can effectively respond to cyberattacks and remediate their damage.
• Improve incident detection—The EO requires that a government-wide endpoint detection and response (EDR) system be implemented and that information sharing within the federal government be improved for better detection of cybersecurity incidents.
• Improve investigation and remediation—The government will create cybersecurity event log requirements for all federal agencies to improve the investigation and remediation of cybersecurity incidents on federal government networks.

The EO laid out immediate objectives for several government agencies to meet, but it is having a cascading effect throughout the federal contracting supply chain. Specifically, the EO impacts three groups:

• Federal executive agencies—Top-level government agencies are charged with modernizing their technology environment and security practices.
• Federal contractors—Contractors doing business with the U.S. government, including commercial-off-the-shelf (COTS) software providers, can expect new cybersecurity standards built into contract terms. They are also required to share more information about cyber incidents.
• Private businesses—Private businesses will be subject to new cybersecurity legislation and heightened enforcement of existing laws and policies, with a greater focus on software supply chain security and the reporting of cyber incidents. There is also a greater emphasis on transparency through proposed consumer security labeling on software and internet of things (IoT) devices, resulting in new security requirements and assessment standards for these providers.

Why are SBOMs important today?

SBOMs are important because they can help organizations identify and fix any vulnerabilities that may exist in their software and its dependencies. Modern applications are developed using a supply chain of software components that’s just as intricate as those used by manufacturers of physical goods. A typical app is built from dozens of components using a mix of proprietary code and reusable third-party components. While a developer can vet any code they’ve written for errors and mistakes, they have less visibility into third-party code. Attackers understand and exploit this, targeting third-party components knowing they’ll likely evade detection.

When a vulnerability is discovered or disclosed, SBOMs can help determine where that software version is being used in the organization.

Besides the now infamous SolarWinds incident, a series of supply chain attacks over the last few years has highlighted the devastating effects this scenario can have. Attackers exploited a critical vulnerability in the open-source Apache Log4j software, a nearly ubiquitous logging library that records activities in millions of Java-based applications. Hackers also took advantage of four separate zero-day vulnerabilities in Microsoft Exchange Server to gain access to the networks of 30,000 U.S. organizations.

An SBOM can help an enterprise better protect against these types of supply chain attacks and prioritize its risk management. For example, it can use SBOMs to first eliminate the use of libraries with known vulnerabilities, then to ensure it’s using the latest version of each open-source library. When a vulnerability is discovered or disclosed, SBOMs can help determine where that software version is being used in the organization. More generally, SBOMs allow organizations to make better-informed decisions about the software they use and encourage software providers to produce more-secure products.

What are the components of an SBOM?

In July 2021, the NTIA released “The Minimum Elements For a Software Bill of Materials,” outlining the federal government’s requirements for an SBOM. It divides baseline components of an SBOM into three categories: data fields, automation support, and practices and processes. Here’s a closer look at each.

Data fields
Data fields should effectively identify each component so that it can be monitored over the software supply chain and referenced against vulnerability and license databases. NTIA specifies seven data fields:

• Supplier name: The name of the organization that creates and identifies the component.
• Component name: The name assigned to a software unit by the original supplier.
• Version of the component: The build and version details of the component used in a software product.
• Other unique identifiers: Look-up keys and other information, such as an identifier from NIST’s CPE Dictionary, that can be used to identify a component.
• Dependency relationship: A description of the dependencies between the component and other software. For example, component A is included in software B.
• Author of SBOM data: The name of the organization that created the component’s SBOM data.
• Timestamp: The date and time that SBOM data was compiled.

Automation support
Because it isn’t feasible for security professionals to manually search for compromised components in every SBOM, NTIA requires that every SBOM support automation through one of three machine-readable formats:

• Cyclone DX
• Software Package Data Exchange (SPDX )
• Software Identification (SWID) Tags

[Read also: Here’s your security automation playbook for 2023]

Practices and processes
Practices and processes ensure an SBOM document’s accuracy throughout a software product’s life cycle. NTIA outlines several minimum elements to be addressed, including:

• Frequency: Whenever a software component is updated with a new build or release, a new SBOM must be generated to reflect the new version of the software. This includes software builds to integrate an updated component or dependency. Similarly, if the supplier wants to correct an error or update information in the existing SBOM data, it should issue a new, revised SBOM.
• Depth: An SBOM should include all top-level components and list their dependencies.
• Known unknowns: Sometimes developers recognize that they don’t know all the dependency relationships about a component. In these cases, the SBOM should make clear that the data is incomplete and explain where relationships may exist.

[Read also: You’ve assessed your known unknowns? Nice but don’t stop there—it pays for leaders to imagine “unknown unknowns,” too]

• Distribution and delivery: SBOMs should be available to those who need them in a timely fashion and have appropriate access permissions and roles in place.
• Access control: Organizations that wish to keep SBOM data private must specify the terms, including allowances and accommodations for users to integrate SBOM data into their security tools.
• Accommodation of mistakes: Because management of SBOM data is an evolving practice, users should be tolerant of incidental errors. Suppliers should offer updated data as issues are identified in past SBOMs, and users should welcome these updates and corrections without penalty to encourage continued improvement.

SBOM requirements will likely continue to grow and evolve. More data fields and the addition of security scores, vulnerability lists, and other information may come with updated guidelines. While organizations are only obligated to meet the minimum requirements of an SBOM, including additional relevant information about a software product will show a strong commitment to transparency and security.

What is the SBOM development life cycle?

Ideally, SBOMs should be automatically generated whenever software is deployed and include as complete an inventory as possible. The SBOM life cycle helps facilitate this by providing a process for identifying applications, creating SBOMs, and making them available to end users.

SBOMs should be automatically generated whenever software is deployed and include as complete an inventory as possible.

It consists of the following five stages:

• Asset discovery—The first stage is to find the application you need to provide an SBOM for. It’s preferred to use an asset discovery tool to ensure complete visibility into all your apps.
• Application data analysis—The application data required for the SBOM is collected.
• SBOM creation—The SBOM file is created, including all the relevant application data. This should be done every time there’s a new release of the app to ensure the SBOM always matches the software’s current state.
• SBOM storage—SBOMs need to be centrally and securely stored using encryption.
• SBOM searchability—The final stage is to ensure search functionality for the SBOM so that the end user can look up any potential vulnerabilities.

What SBOM standards are there?

An SBOM standard is a schema for detailing the composition of software in a machine-readable file that can be consumed by other tools such as vulnerability scanners and software license trackers. Currently, there are three main standards for generating SBOMs and sharing them with end users:

• SPDX—The SPDX (Software Package Data Exchange) standard, developed by the Linux Foundation, is a widely adopted format for communicating SBOM data such as an app’s components, licenses, copyrights, and security information in multiple file formats.
• CycloneDX—CycloneDX is another open standard, developed by the OWASP community. It is based on the SPDX standard but has been streamlined for easier implementation and use
• SWID—SWID, short for Software Identification Tags, are a type of metadata that can be automatically generated by many applications to describe and contextualize the software’s components.

NTIA selected these three SBOM standards as acceptable because, in addition to being human-readable, they are also machine-readable and can support automation to make it easier for end users to use and scale SBOMs across their organization.

[Read also: The future of risk management is all about automation]

What are the challenges with creating and using an SBOM?

As with any new system, creating and using an SBOM comes with some challenges.

A primary obstacle is the lack of standardization. SBOMs are likely to be most effective when the entire supply chain adheres to the same standards, processes, and tooling. However, in these early days there is little consensus on any of these, and a lack of uniformity across software suppliers and end users is inevitable. That can lead to extra time spent dissecting and adapting SBOMs to order.

SBOMs are likely to be most effective when the entire supply chain adheres to the same standards, processes, and tooling. However, in these early days there is little consensus on any of these.

Another challenge is the need to continually adapt SBOMs. Every time there’s a new release of an app, it must include a new SBOM that reflects the app’s current state. That makes it critical to adopt SBOM management tools that can integrate SBOM generation into the software-development life cycle.

Scaling SBOMs as you take on more supply chain partners can also be an issue if you’re using traditional methods to generate them, such as spreadsheets and email. Further, these manual methods are time-consuming, prone to error, and can make it difficult to track hierarchical relationships between components.

What are some best practices for creating an effective SBOM?

The following best practices can help you create effective SBOMs:

• Use a consistent format—It’s important to follow a standard format when structuring SBOM data. SPDX, CycloneDX, and SWID are the most popular, but ultimately your choice of format matters less than using it consistently.
• Automate SBOM creation—Automatically generating SBOMs as part of your software delivery pipeline has several benefits. Primarily, it will save developers time as they won’t have to build each SBOM manually. It also makes it more likely that SBOMs become a regular part of your software delivery cycle. Finally, it allows you to meet the requirements set by the Biden EO for providing IT services to the federal government.
• Update SBOMs with each release—An SBOM must be specific to each software release, including whenever an application is updated. Automation is key here; if developers have to manually update their SBOM with every app update, it’s far less likely to happen.
• Include complete metadata—Although there’s no universal SBOM standards, you should make it a practice to include as much metadata in each SBOM as possible. This will reduce how much information your end users will have to look up manually and demonstrate your commitment to security and transparency. It also makes it easier to update.

More resources

• • What Is Software Supply Chain Security?
  • Managing Software Supply Chain Risk Starts with Visibility
  • Supply Chain Security Is Tough. So What Should Good Look Like?