Beyond the Noise: Automating Vulnerability Exploitability with SBOM and VEX

Introduction

In the modern development landscape, open-source components are the building blocks of virtually every enterprise application. However, this reliance on third-party code has created a massive challenge for security teams: the "SCA Flood." Software Composition Analysis (SCA) tools are excellent at identifying vulnerabilities, but they often lack the context to tell you if those vulnerabilities actually matter. In this post, we explore the insights shared by Srinija Kammari and Anusha Penumacha from Splunk on how to move beyond basic scanning to sophisticated, context-aware vulnerability management using SBOM and VEX.

The Shift from Compliance to Context

Executive Order 14028 (issued in May 2021) mandated the use of Software Bill of Materials (SBOM) for federal software vendors. While many saw this as a hurdle for compliance, the security community is increasingly viewing it as a strategic asset. The real value lies in pairing the SBOM—which tells you what is in your software—with the Vulnerability Exploitability eXchange (VEX). VEX provides a machine-readable way to communicate whether a product is actually affected by a vulnerability in one of its components.

As the Splunk team pointed out, their internal data showed that over 26% of vulnerabilities identified by automated tools were either non-exploitable or non-actionable. Without a way to filter these out, security teams suffer from "alert fatigue," and developers lose trust in security tooling.

Technical Architecture for Centralized Scanning

To solve this, Splunk moved from a fragmented 'shift-left' approach to a centralized model. Here is a breakdown of the technical components:

1. Asset Inventory (CTS Portal): A central repository where developers onboard their code repositories and artifacts. This metadata includes owner information, branch targets, and severity thresholds for ticketing.
2. Centralized Scan Platform: A tool-agnostic engine that triggers scans across the inventory, aggregates results from various SCA and SAST tools, and maps them back to the asset owners.
3. Security Central Dashboard: A visualization layer providing high-level metrics (vulnerability distribution, mean time to remediate) and granular search capabilities, such as finding every product in the organization affected by a specific CVE.

Leveraging the Developer Feedback Loop

One of the most innovative parts of the Splunk approach is using the issue tracking system (the developers' natural habitat) as the primary data collection point for VEX. Instead of forcing developers to learn a new security tool, they integrated VEX requirements into the standard ticketing workflow.

Developers cannot close a vulnerability ticket without selecting a VEX status:

• Not Affected: The vulnerable code is not reachable or utilized.
• Affected: The vulnerability exists and requires remediation.
• Fixed: A patch has been applied.
• Under Investigation: The team is still assessing the impact.

This data is then pulled back into the central database to generate VEX-embedded SBOMs automatically. This creates an audit trail and builds "institutional knowledge" that can be used to automate future findings.

Automated Remediation and Context Building

By collecting this remediation data over time, the system builds a context engine. For example, if a specific vulnerability in a common library is marked as a false positive by multiple trusted senior developers across different teams, the system can learn to automatically close that finding for future scans.

Additionally, the system utilizes external context. If a vulnerability is found but no fix is available from the upstream maintainer, the system can automatically adjust the priority or close the ticket with a specific status, preventing developers from wasting time on issues they cannot yet fix.

Conclusion & Key Takeaways

The future of vulnerability management isn't just about finding more bugs; it's about finding the ones that matter. By centralizing scan data and leveraging developer context via SBOM and VEX, organizations can reduce their vulnerability debt by up to 25% or more.

Key Takeaways:

• Centralize Your Data: You cannot manage what you cannot see across the entire product portfolio.
• Use VEX for Communication: Move beyond simple 'vulnerable vs. not vulnerable' binary thinking.
• Meet Developers Where They Are: Integrate security requirements into existing issue trackers to minimize the learning curve.
• Automate with Context: Use previous remediation patterns to filter out future noise.

As we look toward the future, the integration of Agentic AI into this data-rich environment will likely allow for even more precise automated exploitability determinations, further bridging the gap between security and development.