Open-source code remains a concerning and ongoing source of vulnerability in the software supply chain, as seen in the recent 650% year-over-year 1 increase in attacks directed at exploiting weaknesses in upstream open-source ecosystems - attacks that are increasing in number, scope, and sophistication.
The massive, coordinated effort of the SolarWinds attack, compromising major corporate and government organizations, is only the most prominent example of the widespread visibility and control problems with software vulnerabilities. As a result, key industry stakeholders like the US and EU governments are now accelerating the drive for solutions, including regulatory compliance measures for software provenance.
One significant advance has been the promotion of a software-bill-of-material (SBOM), a metadata record that identifies the open-source dependencies used to build a software product. With this snapshot view, users can identify vulnerabilities and mitigate risk for their own security and for the fast-approaching regulatory obligations.
SBOMs, however, are not a panacea. Vulnerabilities vary so widely in number, scope, and emergent timelines – where even components impervious to attack in one context, are vulnerable in another - that SBOMs are sometimes too static and their communication process too slow for a dynamic open-source environment that never stops evolving.
To help, The National Telecommunications and Information Administration (NTIA) is trying to bridge these gaps with more responsive information by helping develop and promote the adoption of a vulnerability exploitability exchange, or VEX, as a companion document to the SBOM.
As efforts to secure the software supply chain expand, VEX adoption will likely follow suit. But given their novelty, basic questions remain about VEX functions and their relationship to SBOMs.
To help you understand VEX as the latest strategy to reinforce the supply chain, we’ll examine their major differences to SBOMs, how they work together, and common use cases.
An SBOM lets engineering and security teams verify, discover, and track all dependencies and supply chain relationships between components in their software.
While this unique snapshot of software provenance helps producers and vendors identify and convey vulnerabilities to users and asset owners, it is not the most expedient approach to vulnerability management.
To begin with, not all vulnerabilities require action despite their possible presence in an SBOM. Vulnerabilities can exist in a component and be earmarked in an SBOM but will pose no threat if developers have already mitigated them or if they can only be exploited after a specific product feature is activated.
Lacking this information when they receive an SBOM, security teams set off to fix an issue that doesn’t need their attention but wastes time nonetheless. Communicating with vendors and producers to get clarification requires distributing, reading, and responding to messages, alerts, and supporting documentation – all of which, like the SBOM itself, ostensibly function to keep asset owners updated about vulnerabilities but unfold along slower communication lines.
And while an SBOM remains static until components of a software build are updated and the inventory of dependencies changes, vulnerabilities wait for no one. The dynamic nature of open-source code changes quicker than both the “moment-in-time" snapshot that SBOMs provide and the often-sluggish communications between manufacturer, vendor, and user.
Undoubtedly, software bill of materials (SBOMs) are a step in the right direction. Still, without a richer spectrum of timely vulnerability data that reflects the actual fast-moving and fluid relationships of an open code ecosystem, security teams will continue to face challenges accurately assessing risk, prioritizing mitigation efforts, and sharing critical information.
Addressing these issues, a VEX artifact helps software producers and vendors more quickly and efficiently identify, track, and communicate vulnerabilities and their potential to be exploited.
Without waiting for a request to generate and track a new SBOM, suppliers can immediately export new and emerging vulnerability and exploitability data, including mitigation information, into a machine-readable VEX document. Developers or vendors can re-distribute the document any time a dependency changes or a new vulnerability or threat surfaces, updating all stakeholders of “on-the-ground" conditions.
Most importantly, with VEX’s more granular and timely data in hand, asset owners can more easily and accurately access, interpret, and assess the best-known and most current vulnerability status of their software.
Knowing the current exploitability of a dependency (or the existence of a vulnerability that would have remained invisible until the next SBOM was generated) allows asset owners to more efficiently evaluate risk and prioritize mitigation, critical to avoid potential fallout given how fast emerging vulnerabilities emerge or evolve.
While an SBOM is usually static to a given build, the VEX is highly adaptable to any changes in a developer’s or vendor’s real-time vulnerability assessment. The quick transmission of value-added exploitability data streamlines and strengthens the entire security process, from the identification and triage of vulnerabilities to the investigation into root causes, the sharing of workarounds to the prioritization of remediations. VEX accelerates communication, and therefore action, for every stakeholder in the supply chain.
VEXs are not intended to replace SBOMs; rather, they should be maintained separately, but work to support each other. Software operators can merge the component data created by SBOMs with the current vulnerability information from VEXs to paint a more timely, complete, and dynamic understanding of software risks. Using VEXs and SBOMs in tandem creates a more focused and expedient process for security teams to better tame the protean nature of open-source code and its metastasizing vulnerabilities.
To illustrate, let’s look at a typical example: your chief information security officer performing a routine security assessment of your various software assets. They reach out to a vendor and request an SBOM which, after receiving it, reveals that there are hundreds of existing software vulnerabilities, some deemed critical.
Alarmed, the security officer returns to the vendor, only to be informed that only a handful of these vulnerabilities are exploitable but the vast majority don’t have the potential to affect their software. Patches are implemented to mitigate those exploitable few, and everyone involved considers the situation resolved.
Until, of course, a new vulnerability surfaces soon after, starting the same chain of events, all with the same results: panic, back-and-forth communications, wasted time and resources.
Yes, the details in an SBOM helps teams to identify vulnerabilities but, lacking more timely and precise information about which specific vulnerabilities pose greater threats and need to be remediated immediately, they also generate inefficiencies.
With a VEX document, the same vendor can provide the most current and accurate exploitability information about new and ongoing vulnerabilities, alongside their various remediations, without having to generate and distribute SBOMs. Your security officer can now quickly triage vulnerabilities down to a manageable and prioritized list without having to contact vendors or manufacturers. In other words, a VEX provides more than raw data, it provides actionable software supply chain intelligence.
How stakeholders leverage information in a VEX document will depend on their role in the software supply chain, be it as a developer, vendor, service provider, business owner, or a member of security and engineering teams.
However, the use cases for each of these stakeholders all start from the same premise: VEX provides value-added and actionable information about a specific software component’s exploitability and the recommended steps to remediate the vulnerability.
By widening the context for identifying and remediating vulnerabilities, VEX has common advantages for all stakeholders:
• Increases an SBOM’s overall value by reducing the number of false positives
• Triages remediation by surfacing vulnerabilities that cannot be exploited
• Accelerates remediation through vulnerability prioritization, saving time, money, and frustration
• Updates users about the manufacturer’s ongoing mitigation efforts to build trust
• Recommends workarounds and streamlines access to patches or mitigated new versions
• Provides a more comprehensive view of the threat environment to strengthen overall cybersecurity posture
In a threat environment that never rests, it is paramount for the software supply chain to shore up its defenses by amplifying dynamic visibility into the full range of dependencies that comprise a software build.
And with the time-sensitive, value-added information it provides, especially when merged with an SBOM, the VEX document is a critical development in vulnerability management.
Support for VEX is growing, but wider adoption will depend on mainly on two factors: stakeholders learning to trust the accuracy and value of its information; and dismantling barriers to access and ease of use, such as automating and standardizing the VEX process so that compatible formats can be more quickly generated, updated, shared and used.
While the future of VEX is not yet fully mapped out, the rationale behind their development remains the same – without tools that provide better visibility into risk, the software supply chain will always remain vulnerable and at risk.
VEX and SBOM combined provide a comprehensive view of the vulnerabilities present in an organization's software, allowing organizations to prioritize remediation efforts, receive updates on mitigation efforts, and access patches or updated versions. With SBOM Studio, organizations can combine VEX and SBOM at a reduced cost and with minimal manual labor, gaining valuable insights into cybersecurity risk management, compliance, and supply chain optimization. By using VEX, organizations can prioritize vulnerabilities based on immediate risk and receive recommended workarounds and streamlined access to patches. This helps organizations improve their cybersecurity posture and effectively manage risks, providing a more complete understanding of the threat environment. SBOM Studio currently supports VEX in CycloneDX and CSAF format.
Key capabilities of SBOM Studio’s new VEX functionality include:
• Aggregate vulnerabilities for assessment
• Vulnerability disposition workflow
• Real-time security advisory using VEX Artifacts
• VEX Export and Sharing
1. Emerging Tech: A software Bill of Materials is Critical to Software Supply Chain Management by Mark Driver (Gartner Analyst)
September 5, 2023
Unlocking the Potential: How SBOM Practices Revolutionize Tech IndustriesRead More →
August 15, 2023
We recently saw the publication of the National Cybersecurity Strategy Implementation Plan (NCSIP)Read More →
June 1, 2023
Last month I wrote about using a Software Bill of Material (SBOM) as a valuable tool for managing cybersecurity risk.Read More →