SBOMs, SBOMs Everywhere. But What’s the Best Way to Use Them?

The Software Bill of Materials (SBOM) has moved from relative obscurity to mainstream seemingly overnight, although the concept has been around for a while. As organizations look to ensure that the software they are producing, buying, and using is secure and reliable, the SBOM has become a valuable tool.

Linux Foundation Research surveyed 412 organizations worldwide as part of a study on organizational SBOM readiness and adoption in the third quarter of 2021, and found that a majority (78%) expect to create or use SBOMs this year. That’s up from 66% the previous year, according to the research arm of the Linux Foundation, a nonprofit organization that provides open source products.

Many organizations concerned about application security are making SBOM a cornerstone of their cybersecurity strategies, the Linux Foundation report said.

Other key findings from the survey are that 82% of the respondents are familiar with the term Software Bill of Materials; about three quarters are actively engaged in addressing SBOM needs; and nearly half are currently producing or consuming SBOMs.

The study noted that the top three benefits of SBOMs are that they make it easier for developers to understand dependencies across components in an application; to monitor components for vulnerabilities; and to manage license compliance.

Compare Capabilities to Get the Most Value From Your SBOM

Software developers are not the only beneficiaries, however. Organizations and individuals who buy and use software products can leverage an SBOM to perform vulnerability analyses so they can evaluate the risk a given product presents. Having a formal record of a software product’s history is valuable for organizations in terms of understanding what goes into a product and how it might affect security.

The potential benefits are clear, but the key to success with SBOMs is to use them in the best ways possible. One important component is context.

While SBOMs provide a huge amount of information about the components of software products, this inventory list by itself isn’t enough. In order for SBOMs to be truly impactful, they must include context as well.

For example, not all software products or vulnerabilities are equal in terms of importance and risk level, and that needs to be taken into account. A part particular vulnerability might present a major threat to an organization—or no perceivable threat at all.

Another important consideration with SBOMs is whether they are static or dynamic. Unfortunately, most SBOMs today are static, which doesn’t work in an environment such as software creation and maintenance where there is frequent change.

SBOMs need to be updated whenever changes are made to any of the components within a software product. The changes might be code updates, patches for vulnerabilities, or the addition of new features, and these can occur at any time. It’s easy to see how difficult it can be to keep these documents up-to-date when they are static and revisions are performed manually.

Organizations need to embrace the idea that SBOMs should be dynamic rather than static, and implement technology tools that provide the ability to have a dynamic SBOM that incorporates updates automatically whenever changes occur.

An SBOM can be a powerful part of software security, but only when they are used the right way. (To evaluate sample SBOM capabilities, see Rezilion’s competitive SBOM comparisons page.)