SBOMs Are Only Truly Useful if They’re Dynamic
The software bill of materials (SBOM) is being widely touted as a way to ensure the security and integrity of software products. This is an accurate assessment, but not all SBOMs are created equal. Specifically, those that are dynamic are far more useful and effective than those that are not.
In fact, SBOMs that are not dynamic—able to easily and automatically account for the constant change swirling around the software landscape—are of minimal use. They’re static entities in the midst of ongoing shifts. It’s the “dynamic” and automation part of these documents that make them true security tools.
The Difference Between Static and Dynamic SBOMs
Static SBOM tools, which include many of the existing products in the market, fail to meet today’s security needs and create too much work for teams. They require manual, single-point-in-time scanning to understand changes in the environment.
These SBOMs create complex outputs that make it difficult to focus, and they are limited in terms of the scope of what they can see. In addition, they are often only available in specific parts of the software stack. Given all these limitations, the result is delay and uncertainty that can result in increased risk.
SBOMs clearly have the potential to give organizations and teams greater visibility into software supply chains, and more accurate information for vulnerability disclosure requirements. Some cybersecurity experts have noted that SBOMs will foster transparency, which in turn will lead to increased security and trust.
Ever since the U.S. federal government mandate calling for the creation of SBOMs to avoid the next major vulnerability resulting in attacks, software providers have been trying to figure out how to build SBOMs that are effective as well as dynamic.
The key to success is to leverage SBOMs that are dynamic. These SBOMs are flexible documents that automatically incorporate updates whenever a change is made to any software component. This includes code updates, vulnerability patches, and new features and any other modifications. If the information is not kept current, an SBOM will lose its value.
A dynamic SBOM also provides context about how software components are used and executed—unlike static SBOMs that simply inform about what’s there. The dynamic runtime context is vital for distinguishing latent components from active exploitable threats, understanding true risk and focusing remediation efforts on the relevant parts of the SBOM.
Why Dynamic SBOMs Will Soon Be a Requirement
Eventually, it will likely become a requirement for organizations to shift to dynamic SBOMs, especially those that develop software on a regular basis. In the future, SBOMs will be integrated into the security lifecycle of software products and generated automatically at predefined stages.
They will be used as security gates as products move from one stage to another, driven by an organization’s security policies. These are significant developments, given that many software providers are not aware of what vulnerabilities exist in their products and which are exploitable.
SBOMs can certainly play a critical role in making software secure and keeping products secure over time—but only if those SBOMs are dynamic.
