Webinar: Why Cloud-Native Applications and APIs Are at Risk

Time for a Dynamic Software Bill of Materials (DBOM)

I recently read this article on DevOps.com, and it got me thinking.

Why is an SBOM not dynamic and updated every time a release happens in your CI/CD pipeline?

To keep up with the speed of DevOps, organizations are scaling back things like QA and SBOM updates to only look at the latest release and not focus on the components that were already part of their application architecture.

Log4Shell shows that secure things don’t always stay that way. You can’t trust a software package to remain secure even though it has always been secure. The time is now for a Dynamic Software Bill of Materials or DSBOM.

What is a DSBOM?

A DSBOM is an SBOM that is dynamically updated every time a release happens.

You can then apply policies, rules, and queries against the newly created DSBOM to understand the current state of the application architecture and if it violates any known or recently discovered vulnerabilities.

Organizations are currently automating many different technologies into their DevOps processes, so it seems logical to me to also dynamically create an SBOM.

How a DSBOM Works

A video is worth a thousand words – so I decided to record a glass board session breaking down exactly how it works.

DSBOM is just the tip of the iceberg

A DSBOM solves many issues, but let’s take it to the next level.

By combining a DSBOM with a complete architectural map of your application, you will have the ability to see not only the application’s bill of materials but also how all the services and technologies communicate with each other.

This combination of a DSBOM with an architectural application map will provide you with a clear path to prioritize what to remediate first based on the currently known risk.

You will also be able to quickly prioritize and remediate the riskiest issues the next time a zero-day vulnerability like Log4Shell is discovered.

DSBOM is the future, and the future is now

The chaos of Log4Shell ongoing further stresses the need for a real-time and dynamically created SBOM. I have spoken with many colleagues across the industry.

They all agree that comparing an outdated SBOM to their current application architecture that is deployed has been a highly complex process.

The next time a new zero-day is discovered, they need to be better prepared. A DSBOM is a massive step in the right direction to understand today’s known vulnerabilities and prepare for the unknown.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

Share on linkedin
Share on twitter
Share on email
Share on facebook

See a Live Demo of the Bionic Platform