Four Steps to Mix SBOMs—Softwares’ Recipe—Into Risk Management

Organizations from startups to government agencies use opaque software code that could put them at risk of executing malicious programs. This code largely comes from open-source repositories without sufficient security processes.

A software bill of materials, or SBOM, plugs that gap by acting as an evolving list of ingredients for software, increasing transparency into the components at the beginning of a program’s lifecycle and serving as the basis for continued vulnerability monitoring. SBOMs can help governments and businesses manage risk, but only if they know how to use them.

There are four key steps that every organization must take to use this tool to improve security.

SBOM Development

The US government, industry, and academics have worked together over the past five years to develop guidance on how to generate and exchange SBOMs between vendors and their customers.

After the December 2020 revelations about a years-long Russian cyber espionage campaign that penetrated US government agencies by compromising software provider SolarWinds, the White House kicked this collaboration into high gear in May 2021.

This included tasking the National Telecommunications and Information Administration with developing a standard for the minimum elements SBOMs should include, and the National Institute of Standards and Technology with providing guidance on how to secure the software supply chain by using SBOMs.

After completing this task, NIST also published updated guidance on supply chain risk management, which noted that SBOMs can help manage organizational risk by improving the transparency of software assets.

These standards and guidelines have clarified what information SBOMs should provide to customers and how software companies can implement processes to ensure the security of their code during its development process.

Fallout From Log4j

In the meantime, however, researchers discovered what US cyber chief Jen Easterly called likely the “most serious” software vulnerability she had ever seen, embedded in hundreds of millions of devices around the world. The Log4j vulnerability underscored the urgency of SBOMs which would inform users if their products contained it, she explained.

And earlier this spring, private cybersecurity firms discovered yet another software supply chain compromise—this time by North Korea—likely affecting hundreds of thousands of multinational corporations.

While the public-private collaboration is popularizing the idea of SBOMs and answering important questions around standardizing their creation and distribution, the guidance fails to answer some of the most important questions around SBOM use:

• How should recipients of SBOMs consume and integrate them into their existing business processes?
• With a software ingredient list in hand, how can organizations effectively use SBOM to improve their security?

While the details of the process will vary by company, there are ultimately just four steps every recipient of an SBOM needs to do to make effective use of this tool.

Step One: Validate SBOM

After receiving an SBOM for a custom-made software, the first thing an organization should do is validate that the SBOM they received contains the information they asked for in the contract with the software supplier.

For example, a contract could specify that SBOMs must use a specific naming convention for identifying software components. The company receiving the SBOM must first confirm the vendor actually did as instructed.

Part of this first step should also be a confirmation of the SBOM’s integrity through a chain-of-custody-like process.

Organizations might also receive SBOMs when purchasing commercial, off-the-shelf software. In that case, the organization can’t make specific demands of the seller.

When purchasing a Sony television from Best Buy, the standard instruction manual is all the buyer gets. In those scenarios, step one may include adapting or modifying the SBOM so that it matches and can easily feed into the organization’s existing systems.

Step 2: Analyze Vulnerabilities Before Deployment

Next, organizations must review what the SBOM reveals about the software’s components. The SBOM will indicate the number of known vulnerabilities contained in the software, the percent that is open-source code, and the history of maintenance of the various components. The SBOM will also reveal whether there are any critical pieces that were developed by foreign entities.

There is no such thing as risk-free software. The question the organization will need to consider is whether—using pre-established criteria—the risks are acceptable. If yes, and only if yes, the company will add the software to its systems.

Step 3: Ongoing Risk Assessments

Cyber risks are not static. New vulnerabilities are discovered, and malicious actors develop exploits for those vulnerabilities every day. Nor is software static. Developers regularly add new features and patch uncovered vulnerabilities.

SBOMs are living, evolving documents after their generation. Therefore, once the company deploys the software, it should incorporate the SBOM into a central repository where it can be updated and analyzed on an ongoing basis.

While a company assesses the risk level of the software before deployment, after implementing the software, companies must conduct ongoing assessments to ensure the SBOM contains updated, accurate information and to determine if the risk level is still tolerable.

In a nutshell, this is SBOM management, and many private companies like Cybeats, Ion Channel, Manifest Cyber, and Finite State have built tools to do this work.

Step 4: Integrate Into Business Processes

The fourth and most important step is to feed the information gleaned from the SBOM into business processes like risk management, asset management, vulnerability management, and network defense.

This fourth step is the bridge between the central repository and a company’s pre-existing processes and the people responsible for them.

After validating, analyzing, and depositing an SBOM, a company must ensure it gets the information from the SBOM into the hands of the people who can use it.

Receiving an SBOM is pointless if it does not improve supply chain risk management and contribute to the overall security of companies. Understanding SBOMs is not as simple as reading a list of ingredients, but with clear, pre-established processes, companies can use SBOMs to their full potential.

Dr. Georgianna Shea is the chief technologist of the Center on Cyber and Technology Innovation (CCTI) at the Foundation for Defense of Democracies (FDD). Logan Weber is a CCTI research analyst at FDD. FDD is a Washington, DC-based, nonpartisan research institute focusing on national security and foreign policy.