Is the SBOM Part of Your Software Security Lifecycle?

The software bill of materials (SBOM) is becoming an increasingly important element in the software development lifecycle (SDLC). In fact, given the rising threats based on software vulnerabilities and the growing use of applications to run or support all kinds of business processes, any organization that’s not using SBOMs is putting itself at real risk.

An SBOM is an extensive list of all the components contained in a given software product. Software vendors typically create these bills to describe their products’ components, and they also include information about the components’ dependencies and their hierarchical relationships.

SBOMs can be useful for teams that develop and secure software, organizations that buy software, and end users who operate the software. For instance, an SBOM enables developers who rely on open source and third-party components to ensure that all components are up to date and can respond to new vulnerabilities.

Why an SBOM is Critical for Software Security

What makes these resources so valuable from a security standpoint are that they are comprehensive and include details on every third-party component with version and license information. They might include open source or proprietary software and can be made widely available to teams.

As noted in a CSO article posted in July 2022, the days of monolithic, proprietary software codebases are over, and modern applications are often built on top of extensive code reuse. In many cases they use open source libraries, and increasingly are broken into smaller, self-contained components of functionality.

While these changes have been a boon for software development and have increased developer productivity, the article says, in many ways they have also created security challenges.

Dynamic SBOMs are especially valuable for organizations, because they are fluid rather than static. The software industry is characterized by constant change.

Once an SBOM is developed, it needs to be maintained and updated whenever a change is made to any application component. Changes might include code updates, vulnerability patches, new features, or any other modifications. These changes can occur at any time, and they need to be tracked in real-time for the SBOM to be effective.

Many SBOMs in use today are static rather than dynamic documents that do not automatically incorporate updates. But the SBOMs of the future must be dynamic. A dynamic SBOM allows teams to build a live inventory of all software components at any point in the SDLC; find vulnerable components across billions of files; and use runtime analysis to know if detected bugs are exploitable in a specific environment.

SBOMs gained a lot of attention, particularly within the government, when the White House in May 2021 announced an Executive Order on Improving the Nation’s Cybersecurity, which directed the U.S. Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the minimum elements for SBOMs.

Since that time, nothing has happened to take away the need for organizations to create and use SBOMs. In reality, they might be even more important given the growing threat of supply chain security attacks made possible by the use of software that contains vulnerabilities.

Is your organization using an SBOM? If not, it should be for software security.