The SEI SBOM Framework helps organizations use a software bill of materials (SBOM) for third-party software management. We created it, in part, in response to Executive Order (EO) 14028, Improving the Nation’s Cybersecurity. Released in the wake of the SolarWinds and Apache Log4j supply chain attacks, EO 14028 requires U.S. government agencies to enhance software supply chain security, transparency, and integrity through the use of SBOMs.

If your organization produces or supplies software for the U.S. government, perhaps you have already done your due diligence and complied with EO 14028. You have analyzed your code, extracted the relevant data, composed your SBOM, and made it available. You could declare victory and leave it at that. But consider all the data you have assembled and must maintain—why not make good use of it?

In this SEI Blog post, I will examine ways you can leverage your SBOM data, using the SEI SBOM Framework, to improve your software security and inform your supply chain risk management.

The SBOM Is a Data-Rich Resource

An SBOM is a formal record containing the details and supply chain relationships of various components used in building software. Think of it as an annotated list of ingredients for your software. So far, so good. But when you consider that software is composed of many libraries and modules and other (often open source) components, most of which have been produced by third parties who, in turn, may incorporate components from other third parties further upstream, many of which will have their own SBOMs, you begin to understand that an SBOM can quickly grow into a very massive data repository.

To help baseline SBOM data, in July 2021 the Department of Commerce specified the minimum elements for an SBOM:

• supplier name: the name of an entity that creates, defines, and identifies components
• component name: the designation assigned to a unit of software defined by the original supplier
• version of the component identifier: the identifier used by the supplier to specify a change in software from a previously identified version
• other unique identifiers: other identifiers that are used to identify a component, or serve as a look-up key for relevant databases
• dependency relationship: a characterization of the relationship that an upstream component X is included in software Y
• author of SBOM data: the name of the entity that creates the SBOM data for this component
• timestamp record: the date and time of the SBOM data assembly

As you can see, manually assembling an SBOM for all the components that compose a typical software product would represent a huge undertaking, even if you only collected the minimum information required by the Department of Commerce. However, most SBOMs are produced using software composition analysis (SCA) tools, which scan code to identify and catalog open source software (OSS) components. To facilitate automation, the following machine- and human-readable data formats are available for generating and consuming SBOMs:

• Software Package Data eXchange (SPDX)
• CycloneDX
• Software Identification (SWID) tags

Even with automation, creating SBOMs is a weighty, complicated task. The SEI SBOM Framework compiles a set of leading practices for building and using an SBOM to support cyber risk reduction. This tailored version of our Acquisition Security Framework (ASF) provides a roadmap for integrating SBOM usage into the acquisition and development efforts of an organization to prepare for managing vulnerabilities and risks in third-party software, including commercial-of-the-shelf (COTS) software, government-of-the-shelf (GOTS) software, and open source software (OSS).

The following sections suggest ways organizations can apply the SEI SBOM Framework to manage third-party software and enhance the security of their software development pipelines and products.

Leveraging Your SBOM Data: 2 SEI SBOM Framework Use Cases

In our SEI Blog post introducing the SEI SBOM Framework, we noted five practice areas in which you can use the framework to improve third-party software management (Figure 1). In this post, I’ll sketch use cases for two of these areas: cybersecurity and software supply chain risk management.

These two areas figured prominently in the motivation for the EO 14028 SBOM mandate in the wake of the SolarWinds attack, in which attackers injected malware into SolarWinds products that spread the malware through software updates, and the exploitation of a vulnerability in Apache’s Log4j software library, a software component used by many other downstream applications. Most recently, a vulnerability in MOVEit, a widely used file-transfer component incorporated in many software packages, enabled attackers to steal information from a wide variety of companies and organizations, including the U.S. Department of Energy.

An SBOM Framework goal defines the outcome or objective toward which a program’s effort is directed. Each SBOM goal is supported by a group of practices. Practices describe discrete activities that must be performed to achieve a goal. Practices are framed as questions.

The SEI SBOM Framework structure (Figure 2) is adapted from the SEI Acquisition Security Framework structure, which is designed to help a program coordinate managing engineering and supply-chain risks across system components, including hardware, network interfaces, software interfaces, and mission. An organization can use the SBOM Framework to identify gaps in how it makes use of SBOM data and to analyze what interventions would provide the greatest value for the organization. Under this multilayered framework, multiple practice areas comprise multiple domains, which in turn comprise multiple goals, which in turn comprise multiple practices.

From our analysis of SBOM use cases, we assembled a set of relevant practices, which we then mapped to the acquisition and development lifecycle to identify relevant domains as follows: requirements, planning, build/construct, deploy/use, manage/support, and infrastructure. A domain is focused on a given technical or management topic, such as program planning, risk management, or requirements, and within each domain there are multiple goals supporting it.

USE CASE: Using the SEI SBOM Framework to Improve Cybersecurity by Managing Known Vulnerabilities

In this use case, one important goal relevant to cybersecurity is vulnerability management. For each goal, the SBOM Framework focuses specific practices that are framed as questions to encourage an organization to explore how well they are addressing this practice. The following practice questions were identified in vulnerability management relevant to SBOMs, and the linkage between SBOM data and vulnerability data provides insight as to whether a vulnerable software component is in use at the organization and poses a cybersecurity risk:

1. Are known vulnerabilities and available updates monitored for software components identified in the system’s SBOM? Keeping track of known vulnerabilities and software updates is an essential activity for effective vulnerability management. A well-designed SBOM will contain information about your software or system, all the components it comprises, and the suppliers of those components. However, the current guidance basically says you must track to the first level of component use (e.g., you know what you used, but not necessarily below that level). The secondary and lower dependencies are unknown risks unless an SBOM supplier indicates there are no further dependencies. This information can be paired with vulnerability information, such as that communicated through the Common Vulnerabilities and Exposures (CVE) list maintained by MITRE, to help alert you to any components with known vulnerabilities. Note that the vulnerability information is stored outside of the SBOM (not part of it). Understanding what you have, when it’s been exposed, and recommended mitigations can greatly facilitate your vulnerability management efforts.
2. Are vulnerabilities in SBOM components identified? Here we move from the system level to the component level. Scanning source code and binaries to identify potential vulnerabilities is an option open to each organization. While not all organizations have this expertise readily available, independent service providers can assist. Organizations should automatically scan and mitigate vulnerabilities in the source code they are creating. The owner of the software will need to address the risk mitigation for third-party components.
3. Is the mission risk of each SBOM component assessed? Not all components are equal. A vulnerability in one component could lead to catastrophic consequences if exploited, while a vulnerability in another component might remain unaddressed for months without consequence. From a system perspective, understanding where in the software and system architecture the affected components are located is necessary to evaluate the risk to the system. The software and system architecture information (e.g., implementation) isn’t part of the SBOM information and will take some subject matter expertise (multidisciplinary approach) to map these information sources. Mission threads, which trace the flow of critical mission activities through the technology layers, can assist in identifying the components of high importance. In this way, you can focus your vulnerability management efforts on components most essential to mission success.
4. Are software updates prioritized based on their potential impact to mission risk? For software or systems comprising many third-party components, managing updates for all those components presents a daunting task. Having identified the components most critical to mission success, you should prioritize these components and allocate resources to updating the highest-priority components first. In a perfect world, you would stay 100 percent up to date on all component releases, but in the real world of limited organizational resources and a steady stream of updates for hundreds of components, you need to allocate resources wisely. Using SBOM data to identify and rank components most critical to mission success, you can take care of critical components first and less critical components as time and resources allow.
5. Are software component reviews/updates conducted based on their mission-risk priorities? Just as you prioritized software updates based on the level of mission risk each component poses to your software or system, so too should you prioritize component reviews. Once again, the focus here is on using the information you’ve collected in the SBOM to identify components most critical to mission success and/or those that present the greatest mission risk should they be compromised. Doing so enables you to narrow your focus in the face of an overwhelming amount of data and apply your resources effectively and efficiently.
6. Are vulnerability management status, risks, and priorities tracked for each software component? Your SBOM data provides you information about all the components in your system. Comparing that data with data from a vulnerability list service like CVE enables you to know when one of your components is at risk. Tools will be needed to do this effectively. Once you’ve assessed and prioritized your components based on mission risk, will you know when you last updated a component? Can you easily determine where a given component ranks in terms of mission risk? What if a change to your software or system has elevated the priority of a component you once considered low risk? To make the most effective use of your SBOM data for ongoing vulnerability management, you need to invest in data management systems and practices.

The tasks in this vulnerability management use case, and in risk management more generally, help you identify and prioritize your most valuable assets. In this case, you’re making decisions based on mission risk. These decisions involve tradeoffs. Here, the tradeoff is protecting your most valuable components, and therefore your software and/or system, from serious harm resulting from vulnerabilities while allowing for the possibility of an exploit of a vulnerability in a component with low mission risk. Such a tradeoff is inevitable for software and/or systems with hundreds or thousands of components.

USE CASE: Using the SEI SBOM Framework to Improve Supply Chain Risk Management

The lack of integration among a system’s technology teams, including suppliers, is another source of risk where SBOM information can help reduce risk and improve efficiency. Hardware has received most of the attention in the past with concerns for counterfeits, but the growing impact of software handling functionality requires a focus on both. But teams often work in stovepipes, and the teams who use supplier software and technology services/products may also neglect to engage or oversee those suppliers. Development and support teams often work independently with varying objectives and priorities driven by cost and schedule demands that do not fully consider existing or potential risk.

Another consideration important to the government is foreign ownership, control, or influence (FOC) of organizations supplying the hardware and software. This is also tracked outside of an SBOM but could be integrated using a free-form field.

In this use case, the following practice questions (which, remember, are framed as assessment questions) apply to the goal of Manage/Support. The purpose of this goal is to ensure that accurate, complete, and timely SBOM data is available for system components to effectively manage risk. Connecting the SBOM data with other supplier information available to the organization strengthens the ability to address supply chain risk management. The specific practice questions are as follows:

1. Are the suppliers for system components identified? This information can come from the SBOM. Knowing the suppliers can help you manage bug fixes, integration issues, and other problems more efficiently. Some suppliers may be unknown, such as for open-source components, and this provides an indicator of potential risk.
2. Is supplier data reviewed periodically and updated as needed? Building an SBOM is not a “one-and-done” activity. Over time, information may change. For instance, the company who supplied one of your components in the past fiscal year may have been acquired by a larger company in the current fiscal year. Treat the SBOM as part of the data that needs to be configuration controlled and managed. To ensure your data is useful, you need to establish schedules and processes for keeping supplier data current.
3. Are SBOMs for system components identified, analyzed, and tracked? Third-party organizations producing system components should be producing their own SBOMs for these components. Understanding what’s in these components, what upstream dependencies might exist, what version has been used, and other relevant data is essential when you’re working to resolve issues introduced through third-party component software. Consequently, you should institute practices for identifying SBOMs published for the third-party components used in your software. You should also determine what SBOM information is most relevant to your needs and examine this information to evaluate what, if any, consequences incorporating the component might have on your system’s functionality and security. Be aware that software may have external dependencies (e.g., Dynamic Link Libraries in Windows), which will not be in the SBOM as it is currently defined, since they are runtime dependencies.
4. Are SBOMs managed to ensure they are current? Suppliers and products are continuously changing. Effective supplier management requires knowledge of dependencies so that single points of failure and risks for supplier loss can be proactively managed. The more your data is out of date, the less valuable it becomes. For instance, if your SBOM data tells you you’re using version 2.0 of component X, but you’ve recently updated your system to version 2.4, you might miss a vulnerability alert related to version 2.4, causing pain for your users or customers and risking the reputation of your organization. Relying on the vendors to provide this information can also leave you at risk. You need to develop and implement schedules and practices for keeping your SBOMs up to date that may require participants from across the organization (i.e., acquisition, engineering, and operations).
5. Are the risks related to incomplete or missing SBOM data identified and mitigated? There tend to be a lot of quality issues with SBOMs that are slowly being worked out (e.g., missing or incomplete data, non-compliance with the minimum elements guidance, etc.). The SBOMs need to be validated before being accepted for use (or published). For instance, missing version information, or missing information about an upstream subcomponent of the component you’ve incorporated into your system, can delay or impede efforts to resolve risk in a timely manner. In the case of missing upstream dependency data, you might not even be aware of a supplier problem until it’s too late. You need to ensure you have a system or practice for identifying incomplete or missing data in your SBOMs, collecting that information, and updating your SBOMs. This might mean working with your suppliers to ensure their SBOMs are complete and up to date.
6. Are risks and limitations related to managing and redistributing SBOM information identified and managed? The requirement to make SBOM data available requires consideration of how widely that data will be shared. Many have expressed concern that it can pose problems related to the disclosure of sensitive or classified information. However, the SBOM is only a list of the ingredients and not the detailed description of how they are assembled. If protections are needed, since there will be consolidation of a wide range of information about suppliers, ensuring the information is available to those that need it within the organization and downstream in the supply chain must be a primary consideration.
7. Is the provenance of SBOM data established and maintained? The usefulness of SBOM data rests on the degree to which you can trust the data is accurate and derives from legitimate sources. You need to analyze which data is most important to the security of your system and develop processes to ensure the integrity of the data and the ability to trace the ownership of that data to a verifiable source. These processes must be able to accommodate supplier consolidation, shifts in supplier sources, and other normal acquisition business processes.

Supplier management is a complex but increasingly important area of consideration for every organization as our dependencies through technology increase. Leveraging available SBOM information can establish a focal point for collecting and maintaining this information in a sharable format, but timeliness and integrity of the data is critical.

The SEI SBOM Framework: Making Software Management More Manageable

The mandate for SBOMs articulated in Executive Order 14028 imposed a heavy lift for those who develop and manage software provided to the DoD and U.S. government. One result of all the work that goes into creating an SBOM is even more data to process and manage. The good news is that you can put that data to work to improve your efforts in cybersecurity, supply chain management, software license management, software architecture, and configuration management. The SEI SBOM Framework can help you along your path to organizing, prioritizing, and managing this data to help you target your efforts in these areas and make them more efficient and effective. Certainly, this will involve extra work in the short term, but this work will pay great long-term dividends.