Recent events, such as those affecting SolarWinds and Log4j, demonstrate the scale of cybersecurity disruption that can result from a lack of vigilance when it comes to the management of third-party components in software systems. As systems have become increasingly software intensive and complex, these third-party components have become widespread, and they require an integrated acquisition, engineering, development, and operational focus to ensure sufficient security and resilience. However, a recent report by SecurityScorecard examined more than 230,000 organizations and found that the systems of 98 percent of them have had third-party software components breached within the preceding two years.

In light of these realities, those charged with managing software systems must consider the dependencies and risks of third-party software in new ways and collaborate with business experts to develop new techniques for identifying and managing potential risks. A software bill of materials (SBOM) can facilitate these tasks. This SEI Blog post highlights our work to build on the SEI’s Acquisition Security Framework for supply chain risk management and tailor it for use in third-party software management, which resulted in the SEI SBOM Framework.

Software and Supply Chain Cybersecurity Challenges

Third-party risk is a major challenge for organizations seeking to limit their exposure to cybersecurity risks. Because third-party software has become such an important factor in the security of large, complex systems, managing relationships with third-party vendors is critical for success.

Organizations often have a limited view into the components, sources, and suppliers involved in a system’s development and ongoing operation. An essential aspect of addressing supplier risk is being able to access information about supplier inputs and their relative importance, and then manage mitigations to reduce risk.

However, a program cannot effectively manage cybersecurity risks alone, because security and supplier risk management typically lie outside the program’s scope. Moreover, critical information necessary for cyber risk management is often distributed among many documents, such as a program protection plan (PPP), cybersecurity plan, system development plan (SDP), or supply chain risk management plan. Likewise, many activities critical to managing cyber risks are distributed among units throughout the organization. These units must collaboratively address cyber risk management across the lifecycle and supply chain and integrate this work with program risk management (Figure 1).

SBOMs and Opportunities for Their Use

The U.S. Department of Commerce (DOC) defines an SBOM as follows in its paper The Minimum Elements for a Software Bill of Materials (SBOM):

An SBOM is a formal record containing the details and supply chain relationships of various components used in building software.

Program mangers increasingly rely on SBOM-driven techniques for gathering information about the components, and their sources or suppliers, that comprise software systems. Early efforts to innovate SBOM methods focused on defining data elements and managing known vulnerabilities. As a result, several information and risk management methods have emerged that identify critical data and connect support teams, suppliers, and stakeholders to reduce risk.

The SBOM gained added significance with Executive Order (EO) 14028, Improving the Nation’s Cybersecurity. Issued on May 12, 2021, EO 14028 requires U.S. government agencies to enhance software supply chain security and integrity, with a priority on addressing critical software. A key component to achieving software supply chain security and integrity is transparency, and SBOMs for critical software can help establish this transparency in the software supply chain. This is why EO 14028 calls for standards, procedures, and criteria for providing SBOMs for products directly or publishing them on a public website.

Our survey of SBOM publications and guidance revealed a strong emphasis on defining the content and format of SBOMs. While establishing a standard for SBOM content is important, organizations also need guidance on how to plan for, develop, deploy, and use SBOMs. Consequently, we focused our research activities on the SBOM lifecycle (i.e., the set of activities required to plan for, develop, and use an SBOM). However, SBOMs must also support (1) proactively considering how to best manage risks posed by third parties, and (2) developing effective mitigations as new threats and vulnerabilities emerge.

There is broad support for increasing the utility of SBOMs. A necessary next step is to develop leading practices and supporting processes. Developing more comprehensive and collaborative SBOM practice frameworks will offer techniques for effectively establishing and managing proactive software information and risk management programs. SBOMs can also provide software developers, integrators, and risk managers a unique opportunity to collect information they can analyze, monitor, and act on to manage software components, suppliers, dependencies, provenance, vulnerabilities, and more—the possibilities are endless.

We also recognize that the SBOM lifecycle does not exist in isolation. Rather, it is performed in an organizational context. In addition to the core lifecycle activities, we must consider enabling and supporting other activities, such as those performed by program management, organizational support (e.g., information technology, risk management, and change management), and third parties. Going forward, it is important to look creatively at how SBOM data can be used to manage software risk and efficiency, and how it can provide support to teams that can benefit from collaborative efforts to solve problems.

Building the SBOM Framework

We started developing the SBOM Framework by reviewing published use cases. Based on this review, we developed core SBOM practices, which focused primarily on developing SBOMs and using them to manage known security vulnerabilities and associated risks. We then expanded on this initial set of practices by considering a lifecycle perspective, which identified practices for specifying requirements, developing plans, and allocating resources needed to build and use SBOMs. Finally, we identified practices for activities that enable and support operational use of SBOM data, including management and support practices, third-party practices, and infrastructure practices. The result is an SBOM Framework comprising the following goals (with third-party practices included in the Requirements and Manage/Support goals):

1. Requirements
2. Planning
3. Building/Construction
4. Deployment/Use
5. Management/Support

Our SBOM framework provides a starting point for integrating SBOMs with a program’s security risk management practices. As we collect lessons learned from piloting the framework and feedback from the community, we will update the framework’s goals and practices as appropriate.

Leveraging SBOM Information

SBOMs have been primarily designed to help organizations build more structure into the management of software risks. Management practices must not only identify, but effectively mitigate, security and resilience risks in systems. However, data and information from SBOMs, while a key factor in managing risk, has many other possible uses and innovations.

Achieving effective SBOM results requires planning, tooling to scale, resources trained to do the job, measurement, and/or monitoring. Information gathered from an SBOM can offer insights into the challenges faced by the groups engaged in managing a system. Figure 2 presents some of the support teams that could use and benefit from SBOM information and key questions this information can address to improve software and systems.

Data about software risks and vulnerabilities is rich and extensive. Unfortunately, the risk information that SBOMs contain only adds to an already overwhelming flow of information. Organizing and prioritizing that information is a challenge, but we expect the SBOM Framework to help users with these tasks.

SBOM data analysis can also help visualize hard or, in some cases, unseen relationships and dependencies. These relationships and dependencies can be invaluable to teams who manage software in ever more complex technical environments. That benefit was described in The Minimum Elements for a Software Bill of Materials (SBOM):

An SBOM should contain all primary (top level) components, with all their transitive dependencies listed. At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.

Going further into the graph will provide more information. As organizations begin SBOM, depth beyond the primary components may not be easily available due to existing requirements with subcomponent suppliers. Eventual adoption of SBOM processes will enable access to additional depth through deeper levels of transparency at the subcomponent level.

With this call for improved data visualization in mind, we supplemented our development of the SEI SBOM Framework with a side project aimed at graphing data exported from an SBOM tool. We ingest the data to create the graphical prototypes for further research and analysis (in SDPX format, which is an open standard for communicating SBOM information).

A Framework for Expanding the Utility of SBOMs

SBOMs are becoming crucial in managing software and system risk and resilience. Motivated by EO 14028, multiple efforts are underway to expand their use. More importantly, there is wide and growing recognition that the risks posed by a lack of transparency in software must be addressed to help ensure security and promote system resilience. We believe the practices and processes outlined in our SBOM Framework can provide a starting point to structure for SBOM efforts. This framework addresses the establishment of processes to manage multiple SBOMs and the vast data that they can provide; however, those processes will likely require further tuning as pilot-related activities provide input about improvements and tooling.

We hope our SBOM Framework will help promote the use of SBOMs and establish a more comprehensive set of practices and processes that organizations can leverage as they build their programs. Meanwhile, we will continue communicating broadly about the benefits and potential uses of SBOMs and gather feedback from pilots. We will also continue to explore pilot opportunities. Where adoption of the SBOM Framework has occurred, we will study the lessons learned to help us in making refinements.

For a more comprehensive discussion of the SEI SBOM Framework, we encourage you to read our white paper, Software Bill of Materials Framework: Leveraging SBOMs for Risk Reduction. If you’re interested in piloting the framework or collaborating on future work, contact us at info@sei.cmu.edu.