Developer using computer to write code showing SBOMs and software security

SBOMs Are Not Set It and Forget It

Software Bill of Materials (SBOMs) are catching on as companies seek better visibility in software supply chains and need accurate information for vulnerability disclosure requirements. But maintaining an accurate SBOM isn’t a quick and easy task. Here’s what to keep in mind when building an SBOM.

Consider software security much like the movement and desire to eat cleaner and healthier. In our efforts to do this, we want to know where our food comes from. We want a clear list of the ingredients.

Increasingly, this is also the criteria for using software in a business environment. Business and IT leaders want to know the “ingredients” they are working with to make their systems run. Enter the Software Bill of Materials – or SBOM.

SBOMs are useful for teams that develop software, organizations that purchase software, and end users who actually run the software. For instance, an SBOM allows developers who rely on open source and third-party components to ensure that the components are up-to-date. Software buyers and users can utilize SBOMs to conduct a vulnerability analysis to determine the level of risk of a product.

The idea of an SBOM isn’t new. The Cyber Supply Chain Management and Transparency Act of 2014, which did not pass Congress, proposed to require U.S. government agencies to obtain SBOMs for any new software products they purchase.

But these documentations—lists of the components in a given piece of software—have been garnering lots of attention lately – particularly since being included among the requirements of the executive order on improving the nation’s cybersecurity, announced by the White House in May 2021. That order, largely spurred by the attention given to the SolarWinds breach at the end of 2020, brought software dependencies into sharp focus as multiple organizations were impacted after hackers added malicious code into the Orion system, which then led to widespread sharing of the bad code.

Now, because of the recent executive order, organizations that provide software products to the government need to provide an SBOM for each product directly or by publishing it on a public website, according to the order. This mandate is seen as a step toward ensuring the security of software products and hopefully provide more visibility into a software supply chain.

SBOM ingredients can eventually rot

Meeting SBOM mandates can be quite a difficult undertaking for those companies that need to comply with the requirements, because building and maintaining an SBOM can be a challenge. Why? SBOMs are formal records that include the minute details and supply chain relationships of all the different components organizations use to create software products. For some applications or operating systems this can be a complex endeavor. The building of this kind of record takes time, given the sheer volume of information that needs to be provided, and the multiple sources providing inputs.

Once an SBOM is developed, the task is far from over. An SBOM needs to be updated whenever a change is made to any of the software components. This includes code updates, vulnerability patches, new features, and any other modifications. The so-called ingredients of an SBOM will go stale if you don’t ensure they are kept up to date.

Because information integrity is so important, everything included in an SBOM has to be auditable. That includes all of the version numbers and licenses. The data needs to be provided by a reputable source and be verifiable by a third party.

Currently these updates are typically done manually. And because changes can occur at any time, it’s a continuous, labor-intensive process. In addition, because changes need to be tracked in real-time for the SBOM to be effective, it’s even more challenging.

Adding to the complexity is the fact that there are no definitive standards yet in place for SBOMs. As an organization’s environment changes, it needs to create new SBOMs. That means the number of SBOMs in place keeps growing without real reconciliation. And this, in turn, increases the maintenance challenge.

Dynamic SBOMs keep things fresh

The key to addressing these challenges is to grasp the idea that SBOM creation and maintenance needs to be a dynamic process. In order to keep those SBOM ingredients fresh – and relevant – businesses must deploy technology tools that provide the ability to have a dynamic SBOM that can incorporate updates automatically whenever changes occur.

In general, today’s SBOMs are static documents that do not automatically incorporate updates. But the SBOMs of tomorrow will be dynamic. In fact, this shift to dynamic SBOMs will eventually become a requirement, especially for those organizations that build and update many software products on a regular basis. Those who build an SBOM and fail to address this much-needed dynamic component of an SBOM will not succeed. The tool will be essentially useless if it is not updated

The SBOMs of the future will also be integrated into software products’ security lifecycle and be produced automatically at pre-defined stages of development. This is extremely important, given that many software providers do not even know what vulnerabilities might be in their software products and which of those are exploitable.

A dynamic SBOM can keep you ahead of threats

Consider the recent situation with Log4j, a Java-based logging utility that is part of the Apache Logging Services and one of several Java logging frameworks. In December 2021, security researchers discovered a zero-day security vulnerability involving arbitrary code execution in Log4j. It was characterized as one of the biggest and most critical vulnerabilities of recent years.

Software vulnerabilities are constantly being discovered, sometimes to the dismay of the companies that develop the products. With any luck, they are discovered by penetration testers or ethical hackers who take steps to disclose the flaws to the software developer, rather than by a cybercriminal who exploits the vulnerability in the wild.

Considering that vulnerabilities are a fact of life with software development, it’s virtually impossible to identify and address all the vulnerabilities in a timely manner. That’s why building security into the development lifecycle is so vital, as is integrating SBOMs into the development lifecycle and producing them automatically at various stages of development.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA), part of the Department of Homeland Security that leads national efforts to manage and reduce risk to the cyber and physical infrastructure, said the SBOM has emerged as a key building block for software security and software supply chain risk management.

Anyone who’s involved in the software supply chain—producers, buyers, operators—needs to understand the concept of SBOMs and how to build and maintain these resources to maximize the time and investment in the tool.