Dynamic SBOM is the Future of Software Security
In previous posts, we’ve discussed how the Software Bill of Materials (SBOM) concept will make a difference in cybersecurity, and why context is needed to generate the most value from these formal records of the details and supply chain relationships of software components.
As helpful as SBOMs are in tracking the history of software products and their components, most of these documents remain static. That’s not ideal for a scenario in which there is near constant change.
Dynamic SBOM: What is it and Why You Need One
After an SBOM is developed, it needs to be updated whenever changes are made to any of the software components. These changes might include updates of the code, patches for vulnerabilities, the addition of new features, and other modifications that can happen at any time.
Because SBOMs are largely designed to be static documents today, much of the updating is done manually. Given the number and frequency of changes that need to be made, this can be a labor-intensive, costly process for organizations. That’s especially true since changes need to be tracked in real-time in order for SBOMs to be effective.
As organizations’ environments change, they need to create new SBOMs, which means the number of SBOMs keeps growing without real reconciliation. This in turn adds to the maintenance challenge.
How can organizations address these challenges? They need to accept the idea that the creation and maintenance of SBOMs should be a dynamic rather than a static process. And they need to implement technology tools that give them the ability to have a dynamic SBOM that incorporates updates automatically whenever changes occur.
As SBOMs become increasingly common, their future must be dynamic. Otherwise, the administrative burden will become overwhelming for many. The shift to dynamic SBOMs will probably eventually become a requirement, particularly for organizations that build and update many software products on a regular basis.
The SBOMs of the future will also be integrated into the security lifecycle of software products. They will be created automatically at pre-defined stages of code development, which is extremely important given that many software providers don’t have any idea about what vulnerabilities might be present in their products and which of those vulnerabilities is exploitable.
Examples of Why Dynamic SBOMs are Important
A good example of this is the recently discovered vulnerability with Log4j, a Java-based logging utility that’s part of the Apache Logging Services, and one of several Java logging frameworks. Security researchers in December 2021 found a zero-day security vulnerability that involves arbitrary code execution in Log4j.
Experts characterized the flaw as being one of the biggest and most critical vulnerabilities discovered in recent years, and certainly most vulnerabilities have nowhere near this kind of impact. Nevertheless, new software vulnerabilities are constantly emerging, oftentimes without any warning from the companies that develop the software.
Given that vulnerabilities are part of the software development process because errors happen, the ability to identify and address the most serious ones—and document them in SBOMs in a timely manner—is vital. Building security into the development lifecycle has never been more important, and integrating SBOMs into that lifecycle and producing them automatically at various stages of development will become the standard.
