I recently ran an unofficial poll on LinkedIn asking how people found every instance of Log4J in their application portfolio. The options I gave were CMDB (Configuration Management Database), SBOM (Software Bill of Materials), SCA (Software Composition Analysis), and internal detective work.
The overwhelming majority, 54% to be exact, said internal detective work.
These results got me thinking as organizations spend millions of dollars a year on CMDB, SBOM, and SCA technologies. Still, when the s*** hits the fan with a zero-day vulnerability, they go back to good old detective work and abandon the fancy tools they spent so much money on.
For the record, the final breakdown was 54% internal detective work, 0% CMDB, 15% SBOM, and 31% SCA.
As an industry, we can do better. Way better.
So, what does this mean?
Two things stand out:
- Existing security tools (e.g., SCA) are not evolving with aggressive modern CI/CD pipelines
- Security experts remain the only way to scale application security
The one that I am most surprised about is SBOM, with only 15% choosing this option. I thought an SBOM was the de-facto standard in providing an accurate bill of materials for your applications, but I guess not.
SBOMs need to evolve.
Today’s CI/CD release cycles keep getting more aggressive, and foundational technologies like SBOMs have not evolved. They are either part of a threat modeling activity or are too narrow in scope, such as just looking at the open-source packages in an application.
SBOM’s need to evolve to be practical. They need to be continuously updated as part of the CI/CD pipeline and be comprehensive for all dependencies of an application, not just open-source packages (which get all the attention).
Key Challenges with SBOM
- Manually created (diagrams, docs, questionnaire)
- Static (snapshot in time vs. continuous)
- Incomplete (e.g., OSS packages only)
- Unstructured and hard to visualize or query
- Lack of business or application context
Introducing the DBOM Concept
You might have read my previous blog about the concept of a Dynamic SBOM, where an SBOM is updated every time a release goes through your CI/CD pipeline.
After more thought, I concluded that a continuously updated Dynamic SBOM is incredible; it is still just a list of components. Granted, it is up to date based on the application code, but it is still too structured. I give you the concept of a dynamic bill of materials or DBOM.
A DBOM is a continuously updated software bill of materials that reflects precisely what is deployed to dev, staging, or production but with a twist. You can query against it to find the more complicated types of issues that are not available in a structured list format.DBOM is really the way to automate most things we do in security…and in IT as a whole.
Benefits of a DBOM
Think of a DBOM as a living, breathing SBOM that is constantly updated so that you can ask it questions. This should allow security professionals to get basic information on-demand.
Think Amazon Alexa for your application. Let’s use the Log4Shell zero-day as an example. Finding every instance of the vulnerable Log4J versions is one thing, but how do you prioritize what to fix first?
You can query the DBOM and ask for every vulnerable Log4J version and if it touches, PII data or is internet-facing or any other combination of logic you want. Since the DBOM is based on the deployed code and is updated every time a release happens, you have an up-to-date DBOM that can find every edge case you can think of.
Log4Shell is just the beginning
Sometimes it takes a significant zero-day to effect change. I feel that the Log4Shell vulnerability is a massive kick in the butt to evolve the concept of an SBOM.
SBOMs need to be continuously updated based on the code itself and not questionnaires or Visio docs. It also must be queryable to be used as an investigation tool to find the issues that are not easily understood or apparent.
The time for a DBOM is now!