Software Bill of Materials: Managing Software Cybersecurity Risks

by Tucker Bailey, Justin Greis, Matt Watters, and Josh Welle

Until recently, most companies were unaware of the “ingredients” or code that make up the software that powers their products and enterprise software. This is an issue because third-party code usage is increasing, and the consumption of open-source software (OSS) will accelerate in the years to come.

Companies leverage open source software because it reduces costs and increases the pace of software development. By layering in code that someone else has already built, developers can decrease their time to market and accelerate the feature sets most desired by their business partners. The challenge is that the code in the open source software repository may have embedded malware, bugs, or other vulnerabilities unbeknownst to the developer. Without a robust vetting process for the code in the open source software repository from which their developers are pulling, companies will remain unaware of threats lurking in their products.

To keep pace with the evolving security dynamic, companies need new programs and management techniques to understand the origin and security of the code that underpins their digital products and business operations. Without such a system, companies will remain vulnerable to unwittingly inserting malware that could cause cybersecurity incidents or damage critical applications. While some cyberthreats can be avoided by developing custom code in-house, that process is resource intensive and time-consuming. Moreover, using open source software has benefits such as being able to build quickly in the cloud or increasing developer productivity. In reality, most applications are built using a combination of custom code and open-source components. That is when a delicate balancing act falls on chief technology officers (CTOs), chief information officers (CIOs), and chief information security officers (CISOs) who are sensitive to OSS’s inherent risks.

Related:Google Cloud to Offer Security-Vetted Open Source Software

To keep pace with the evolving security dynamic, companies need new programs and management techniques to understand the origin and security of the code that underpins their digital products and business operations.

A software bill of materials (SBOM) program can help companies protect themselves and their customers by creating a system that vets all incoming code before it can be adopted by developers.

What an SBOM is, and why it helps

An SBOM is like the nutritional label on a cereal box—it lists the ingredients inside, highlighting content that may be harmful to some, such as gluten and peanuts. Specifically, an SBOM is a formal, machine-readable inventory of software components and dependencies (which result from combining various open source software components, third-party code, and code developed in-house), technical information about those components, and the code’s hierarchical relationships (Exhibit 1)).

Image 1 - list software components

Exhibit 1

An SBOM helps developers know the origin of the “code behind the code” so they can make a determination on whether it is secure. It also helps them understand and mitigate known vulnerabilities in code, saving time and costs. SBOMs also help legal and compliance departments identify license history and allowable use cases for a piece of third-party code, which reduces any potential misuse. Furthermore, SBOMs help security and forensic teams identify the impact on software after the discovery of newly identified common vulnerabilities and exposures (CVEs), which improve organizations’ ability to respond and remediate.

Why an SBOM program is necessary

During the past five years, open source software development rose from approximately 35 percent to about 75 percent of organizations’ audited codebase. As a case in point, by 2021, according to OpenUK, nine out of ten United Kingdom–based companies reported using open source software. Organizations use open source software because it helps with cost savings, developer flexibility, and coding speed.

Open source software usage creates opportunity for greater developer collaboration and allows coders to move quickly, because code libraries contain limitless amounts of prebuilt functionality and tooling resources. Having software components available on demand allows developers to leverage other developers’ work. Components are accessible and available from any location, and these elements are independent of individual manufacturers, making them attractive to start-ups and emerging technology players—or essentially to anyone who wants to build software quickly.

Although the benefit of incorporating third-party code is clear, open source software contributes to organizational risk. Open source software is not regulated or overseen by a central authority and is publicly available. It can contain potential vulnerabilities, out-of-date code, and cyber exploits, which can expose organizations to cyberattacks. Most organizations seek to better understand and reduce their cyber and technology risks, but organizations recognize building and maintaining secure code is a vital cornerstone of any cybersecurity strategy.

Organizations no longer question if they will be impacted by a cyberattack, but instead ask when, how, and what the impact will be after the cyberattack occurs. In 2014, 62 percent of organizations reported experiencing a cyberattack. By 2021, that number grew to 86 percent. The cost of cyberattacks is growing rapidly as well. In 2015, the global impact of cybercrime was estimated at $3 trillion, according to Verizon’s Data Breach Investigations Report. By 2021, that number increased to approximately $6 trillion and is expected to grow to about $10 trillion by 2025. Of the thousands of daily cyberattacks, supply chain vulnerabilities are increasingly the cause.

Given the benefits of open source software as well as its inherent risks, companies are finding it increasingly challenging to manage their software supply chains. For example, in December 2020, the Sunburst malware exploit proved to have supply chain origins. The incident impacted about 33,000 users, of which 18,000 had the product infected with the malicious code.

SBOMs enable companies to preserve the benefits of open source software while managing the risks. They help companies ward off issues, as in the Sunburst case, where one company that had SBOM capability was able to determine that it was vulnerable to the tainted code within two hours. Others affected were less fortunate, such as an energy company that determined it had the bad software two and a half months later. For that two and a half months, the company was vulnerable to even more attacks and enterprise compromise.

Software bill of materials’ (SBOM) importance has reached the US government, and it wants to get greater levels of security.

In the wake of incidents that occurred in May 2021, White House Executive Order 14028 outlined the importance of organizations having an SBOM program. The Department of Commerce issued a statement identifying minimum elements of an SBOM for software sales to federal agencies. The National Institute of Standards and Technology (NIST) provides guidance on Cybersecurity Supply Chain Risk Management (C-SCRM) practices, including information on SBOM standards.

The increase in government policy initiatives reflects a multiyear process whereby NIST worked with stakeholders to pilot SBOM concepts, executed proof of concepts in the healthcare industry, and assembled resources to help organizations build SBOM programs. Cybercriminals and other bad actors often employ various methods to launch software supply chain attacks, often targeting the open-source or common third-party code. To that end, in 2018, researchers uncovered 12 malicious Python libraries uploaded on the official Python Package Index (PyPI). Taken together, incidents such as the Sunburst malware case and the Python Package Index compromise have spurred companies to consider quickly developing SBOMs.

How SBOM programs mitigate risks with increased code transparency

Most organizations have applications made up of different subcomponents and pieces, some taken from open source software libraries, others purchased from third parties, and some created and customized by developers. Each source has different limitations associated with it. For example, open source software and third-party software have licenses that change over time or may have usage limitations. A typical SBOM system surveys, identifies, and characterizes these coding elements (Exhibit 2).

Image 2 - clean code development

Exhibit 2

Organizations that struggle to understand vulnerabilities within their code open themselves to security or financial risk. Here are several benefits an organization can experience from creating an SBOM program:

For example, as code is built, developers create an initial SBOM, which lists the dependencies inherent in the software. During testing and packaging, vulnerabilities and additional dependencies are identified and the SBOM is updated as the code is deployed. As vulnerabilities emerge during operations, the SBOM program will alert developers when a patch is required. After patching, the SBOM is updated again.

How to develop an SBOM program: Invest, create, integrate, and design

Realizing the benefits and challenges associated with open source software development, it is clear that SBOM programs are integral to safer coding and a resilient enterprise. To that end, organizations can focus on four key practices when establishing SBOM programs:

Image 3 - program integration

Exhibit 3

Launching an SBOM program

Companies are racing to use third-party code, including open source software, which means creating an SBOM program must follow suit to avoid the challenges befalling many in the business world today. In addition to this article, guidance on creating a program is available at the Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) developer forums. SBOM regulations primarily affect companies delivering services to the government, like aerospace and defense, but they can be helpful guides for all companies looking to mitigate the same issues. Highly regulated industries, like utilities and financial services, often have the same onus to monitor open source software software usage.

Looking ahead, organizations that proactively examine and assess code that enters their ecosystem via a robust SBOM program will be better prepared for impending government regulations on software supply chain and keep their IT infrastructure and customers safer. Strong SBOM programs allow organizations to build secure code in a cost-effective and efficient manner in the face of increasing cyberthreats. The time to act is now.

Tucker Bailey is a partner in McKinsey’s Washington, DC, office; Justin Greis is a partner in the Chicago office; and Matt Watters is an associate partner in the New Jersey office, where Josh Welle is a consultant.

The authors wish to thank Jim Boehm, Dennis Dias, Michael Glynn, Alex Keegan, Charlie Lewis, Lucy Shenton, and Daniel Wallance for their contributions to this article.

View the original article here: Software Bill of Materials: Managing Software Cybersecurity Risks