As the cybersecurity industry has endeavored to reduce the risk of software supply chain security flaws, software bills of materials (SBOMs) have received a ton of attention, and security pundits have been promoting them as a key building block in software supply chain security programs.
But like a tree falling in the forest, does the creation of an SBOM make any noise if there's no one around using it? To benefit from the component and dependency information gathered in SBOMs, security teams must have plans to operationalize them.
Some of the more obvious areas for this include application build governance and ongoing vulnerability management, but security teams can also leverage SBOMs in cybersecurity incident response (IR). Here's why — and how to put SBOMs to work in IR.
[ Learn why you need an SBOM, more | Get a free SBOM and software risk analysis ]
The value of SBOMs in incident response
An SBOM can be valuable for IR and security operations center (SOC) teams, which ideally know not just what devices or processes are running on a network, but also the ins and outs of the software their organization is using to run everything, said Christine Gadsby, Vice President of Product Security for BlackBerry.
"This allows SOC teams to understand contents and monitor a product's ingredients for potential vulnerabilities rather than being dependent on the product vendor to tell them and provide a fix, which is often too late. This is total software transparency and incredibly valuable, but you must build the capability to monitor it."
—Christine Gadsby
Assuming that analyst and response teams can find the right SBOMs quickly, SBOM information can help IR teams speed up their response times for software-related attacks and breaches, said Jeff Williams, Co-Founder and CTO of Contrast Security. The most useful scenarios are when a known vulnerability is targeted in an attack and the team has figured out which library is being affected.
"Then, using an SBOM, the IR team can immediately see whether a vulnerable version of the library is in use in a system. They can accelerate the response by asking the development team for a specific fix in a specific piece of software."
—Jeff Williams
And SBOMs can be useful in responding to attacks on unknown flaws in an application or API.
"A complete SBOM can help IR teams understand how the application/API works, enabling them to put an attack in context. The SBOM may also help them track down the repos and individuals involved in a project, shortening the response time."
—Jeff Williams
SBOMs that contain information about services, such as back-end connections to databases, queues, APIs, and directories, can be helpful in calculating the blast radius of a breach when responders are called to communicate details in the thick of an incident, Williams adds.
The incident response lifecycle: Where to use SBOMs
You can use SBOMs at multiple stages of the IR lifecycle. Here's a breakdown of the role they can play across each of the four stages.
1. Preparation
"In preparation, if you are a vendor and have SBOMs for what you produce as a product and what you consume from other vendors internally, you can create a catalog all of those 'lists of ingredients’ to create a holistic understanding of your entire attack surface – a total supply chain view," Gadsby said.
Walter Haydock, Founder and CEO of StackAware, said SBOMs using the CycloneDX format are particularly well suited for threat modeling. Mature IR teams that perform threat modeling exercises to plan their response activities should find SBOMs extremely useful.
"Since CycloneDX allows for description of data flows, dependencies and other information useful to the practice, security architects can use SBOMs to create machine-readable representations of their networks. This can help them predict attacker movements as well as the business impacts of losing access to certain key dependencies like cloud service providers."
—Walter Haydock
2. Detection and analysis
The detection and analysis phase is the most universally seen as a good fit for SBOM support, said Williams.
"SBOM information is mostly useful during the detection and analysis phase. The visibility into what is in the software provides context and details that inform the analysis. Obtaining this information from binaries or going back to development teams is extremely time consuming. If SBOMs include vulnerability exploitability (VEX) information, this information can be very helpful in the analysis as well."
—Jeff Williams
3. Containment and recovery
IR teams seeking to ensure that they've eradicated similar or related software attack activity across their organizations can use SBOMs to seek out affected components in areas where they may not have initially begun their investigations, Gadbsy said.
"SBOM information is vital to help containment and recovery in incident response. This telemetry lets you query your vendors and third parties to determine their impact, rather than waiting for them to tell you. Shifting this far left in containment and recovery helps identify patching that's needed before exploits happen."
—Christine Gadsby
4. Post-incident response
As responders tie off on recovery efforts, an SBOM can also help with post-incident activities, Gadsby said. For example, SBOM data can help organizations do post-mortem work that informs how they should prioritize fixes in the future:
"You can review attack surface telemetry to understand a better enterprise-level and in-depth risk picture. This will also assist in lessons-learned activities to mitigate future organizational risks of the software consumed or produced."
Tuning the SBOM for IR and SOC consumption
Many organizations today are still stuck in a rut when it comes to operationalizing SBOMs. Creating the SBOMs is the easy part. Figuring out how to use them is trickier because the tooling and processes to support that work are still developing.
"Because SBOMs are incredibly detailed and lengthy documents, having the right tools in place to allow for querying them is vital to operationalizing the concept. Allowing analysts to quickly match components against known vulnerabilities in them, and then determine the resulting level of cyber risk, is absolutely critical."
—Walter Haydock
SBOMs aren't fit for human consumption, Williams said. Instead, IR teams should be notified of their content through automatic notifications, alerts, and tickets based on a policy engine that's tuned to SBOM information and that monitors the open-source tracking system.
"SBOMs should be thought of as a machine-readable format used to communicate between systems like a build pipeline and an open-source tracking system."
—Jeff Williams
Ideally, the IR team should be able to just type in a system name and get a database view of all libraries in use, or do a global search for systems affected by a CVE, Willams said.
Unfortunately, as robust as the tooling is for SBOM generation and quality checking, off-the-shelf options aren’t there yet when it comes to IR tooling integration, Williams and Haydock said. But both expect the market to pick up steam soon, and it's likely that IR teams are building what they need in the interim.
"There are a few systems that will consume SBOMs, but very little tooling that would give IR teams and SOC analysts the information they need quickly. There are surely teams building ChatGPT-style interfaces that would allow analysts to quickly get their questions answered."
—Jeff Williams
[ Learn why you need an SBOM, more | Get a free SBOM and software risk analysis ]
