Dynamic SBOM: A Comprehensive Guide
What is a Dynamic SBOM
A Software Bill of Materials (SBOM) is a list of ingredients that make up software components. This includes code updates, vulnerability patches, new features, and any other modifications.
An SBOM is useful in tracking the history of software products and their components. But SBOMs are static, and frequently changes need to be made, which can be labor intensive and costly for organizations.
Enter a dynamic SBOM, which is an SBOM that is updated automatically whenever a release happens or changes occur.
As organizations’ needs change, they will have to create new SBOMs, which means the number of SBOMs keeps growing without real reconciliation. This increases the maintenance challenge.
How is a Dynamic SBOM Different from a Regular SBOM
Unlike a static SBOM, a dynamic SBOM updates those changes automatically.
Changes can happen at any point and for an SBOM to be effective, they need to be tracked in real time. This becomes a difficult process, so it’s important that organizations look for tools that offer the ability to have a dynamic SBOM that can incorporate updates automatically.
Everything within a dynamic SBOM should be auditable, including all version numbers and licenses. They need to come from a reputable source and be verifiable by a third party.
Why is a Dynamic SBOM Important
The chaos created by the ongoing Log4Shell vulnerability further stresses the need for a real-time and dynamically created SBOM. It has wide-ranging implications for software developers and almost an infinite list of impacted applications and libraries. Creating and maintaining a dynamic SBOM can help avoid the potentially massive disruption that a vulnerability like Log4Shell can cause.
The federal government also recognizes the importance of utilizing swift SBOM standards because of the increase in software supply chain attacks. The recent White House Executive Order stipulates that those who operate software should provide SBOMs for their products to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.
Vulnerabilities are part of the software development process because it’s a given that errors will happen. So it’s critical to have the ability to identify and address the most serious ones—and document them in SBOMs in a timely manner. Building security into the development lifecycle has never been more important and including SBOMs that will be automatically produced at various stages of development will become the standard.
How Can I Create and Maintain a Dynamic SBOM
Simply listing the basic ingredients of a software component isn’t enough. That includes not just the top-line components, but the sub-components within each piece of software you use.
To start, consider what the typical elements of an SBOM include:
- All operating systems
- Browsers, buffers, and compression engines
- Open source libraries that an application uses
- Plugins, extensions, or other add-ons that an application depends on
- Custom source code written by internal developers
- Information about the components, such as their versions and licensing and patch status
An SBOM for a Software as a Service (SaaS) application could also include information about APIs or third-party services required to run the SaaS application.
Developers should try to include as much information about licensing and patching status as possible to save customers from having to search for that information.
Organizations need to implement technology tools that give them the ability to have a dynamic SBOM that incorporates updates automatically whenever changes occur.
Dynamic SBOMs will eventually be integrated into a product’s security lifecycle and be produced automatically at predefined stages of code development. This 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.
They will also be interoperable, which will lead to greater adoption.
Think Dynamic: SBOMs are the Future
In conclusion, think dynamic. Because it can be manually-intensive for developers who create SBOMs manually to update their SBOMs with each release, updates may only happen periodically. If the data that goes into an SBOM is automatically generated as part of the software release cycle, this will create a more seamless process every time a dependency or change is added or remove from the version of a component.
This ensures that SBOMs are accurate, and that your customers will know definitively whether they are affected by vulnerabilities or licensing mandates associated with a specific version of the product.
With the incorporation of SBOMs in President Biden’s Executive Order, expect to see SBOMs – with automated capabilities – as a trend in software development in 2022.