The software bill of materials (SBOM) has become an important way to understand what organizations need to secure and where potential vulnerabilities lie. This message resonates beyond software engineers and security professionals, also reaching top leaders.

In May 2021, President Biden’s executive order (EO) accelerated efforts worldwide to establish guidelines for creating and distributing SBOMs. The goal was clear: help organizations better secure the software supply chain through increased transparency and information sharing.

This newfound spotlight on the importance of SBOM has arrived at the right time. Attackers often focus on exploiting vulnerable software components that are embedded in large numbers of enterprise applications. The Log4j vulnerability has been one of the most recent reminders of this and many organizations are still struggling to work through it. 

Just as the automotive industry tracks a BOM for every vehicle manufactured so recalls and repairs are fast and accurate if they find a  fault, the software industry has been moving to do the same. The SBOM brings an essential layer of visibility that organizations need into all of the software components that they use and produce. SBOMs are incredibly useful in finding and tracking down vulnerabilities. They are also essential for risk and compliance teams that need to secure the enterprise while keeping pace with the iteration and innovation that powers business. 

But it’s not easy to get an accurate, up-to-date list of all of the components in all the software we build and run. Unlike vehicles, software gets built, deployed, and updated quickly and frequently, often with multiple versions in production at the same time. Additionally, while we manufacture software in development shops, it’s also derived, as most enterprise developers today rely on third-party and open source components as essential building blocks for their applications. Applications are often made up of hundreds of microservices, each automatically scaling on demand and receiving updates multiple times per week. The dependencies of an application similarly change quickly and pull in dependencies of their own. 

Furthermore, not every runtime component goes through the same rigorous build, audit, and deploy process. Enterprise applications in production require additional services, such as monitoring, logging, and security integrations, which run on complex platforms that also change frequently. While it’s easy to create an accurate SBOM for all the code directly built, getting SBOMs for everything else deployed also requires accurate SBOMs from all of those third parties. 

Although maintaining an accurate SBOM for all of applications does have challenges, organizations need to take this step. In fact, recent research from the Linux Foundation found that the use of SBOMs will increase significantly over the next two years. 

While the SBOM certainly helps bring to light if and where vulnerable components are present, are they enough? Some organizations identified dozens of instances of the Log4j vulnerability across their entire cloud and application topology to sift through under immense time pressure. How can security professionals address this mountain of vulnerabilities? How can organizations prioritize which ones to fix first? 

In addition, for teams developing and delivering software derived from a variety of different sources, their code isn’t static. The ingredients lists? Those aren’t static either. Just because a vulnerability isn’t present at the time an SBOM was published, how can organizations verify whether or not this vulnerability is present right now?

As organizations increase their adoption of SBOMs, organizations must also consider adding on a runtime SBOM created from the applications, services, and infrastructure that are running in production.

A dynamic, runtime SBOM adds two essential benefits for enterprise security teams beyond those provided by a standard, static SBOM alone. First, it transforms the traditional SBOM into an actionable, prioritized subset of security issues that are relevant at runtime. The runtime SBOM does this by looking at running processes, containers, and VMs, and identifying where vulnerable components reside within them and whether or not there’s a direct or indirect path an attacker could use to exploit them. We are essentially moving from managing thousands of vulnerabilities to managing a handful of exploits. 

Runtime SBOMs help security leaders better understand vulnerabilities and manage the risk of exploits in production environments by doing the following:

  • Offer a real-time asset inventory. Security teams can’t protect something if they don’t know it's there. Real-time information about each and every component running in production helps improve security.
  • Enumerate the attack surface. An up-to-date list of assets with contextual information about whether vulnerabilities are exploitable can drastically reduce the area needed to defend.
  • Prioritize patching and remediation efforts. With a view of all potential attack paths, security teams can prioritize what to fix first, second, and third based on the relative risk of exploitation. 
  • Support compliance reporting. Compliance is only good if the security team can prove it. Tools that deliver runtime compliance reporting are invaluable to stakeholders across the organization.

Second, a dynamic, runtime SBOM serves as a valuable tool to deliver leading-edge threat detection, making it easier to detect suspicious or malicious activities that indicate attacks are under way. New packages, processes, or activities happening within the infrastructure that weren’t part of a standard SBOM (or even your runtime SBOM), are signs of attacks in progress that need to be inspected and addressed immediately. 

For example, when the Log4j vulnerability was first disclosed, we deployed a vulnerable Log4j application as a honeypot to observe cyberattacks first hand. Using our own security observability tools that provide runtime BOM capabilities, almost immediately we observed a deviation, a process called XMRig, that was executing on one of our nodes, but was not part of our static SBOM.

No cryptominer had previously existed; but at runtime, the Log4j vulnerability in our honeypot was exploited and XMRig was then installed. By looking for deviations in real-time from both the standard and runtime SBOM, we identified that a new, malicious process was running and pinpointed the container it was running on. Using this information, we shut it down.  

Security teams that expand upon the value and utility of the standard SBOM by adopting its dynamic, runtime counterpart will find they have better information for precise and efficient remediation, along with highly-sophisticated threat detection capabilities.  

A runtime SBOM isn’t out of reach. There are tools that collect telemetry at runtime from live production systems that offer runtime BOMs, as well as comprehensive security observability throughout the CI/CD lifecycle–from development through production – helping enterprises visualize and seal of potential attack pathways.

Sandeep Lahane, CEO, Deepfence