Home SecurityApplication Security Vulnerability eXploitability Exchange explained: How VEX makes SBOMs actionable

Vulnerability eXploitability Exchange explained: How VEX makes SBOMs actionable

Source Link

The fallout of the SolarWinds cybersecurity incident, coupled with Cybersecurity Executive Order (EO) put the topic of software supply chain security, and by association, software bills of material (SBOM) center stage in the security dialog. Coupled with the Log4j vulnerability and impact that left countless organizations scrambling to determine the impact, SBOMs are now a critical component of modern cybersecurity vulnerability programs. 

Among the benefits of SBOMs, which are essentially a list of components that make up a piece of software, is to identify potentially vulnerable components. Leading SBOM platforms and tools such as Dependency Track do this by tying vulnerabilities associated with components to the attention of those using the SBOM to analyze their software components. Dependency Track and other tools facilitate this process by querying sources such as the National Vulnerability Database (NVD), Sonatype OSS Index, VulnDB or OSV.

However, just because a vulnerability is associated with a component in software does not mean that the component is exploitable. This is where the Vulnerability Exploitability eXchange (VEX) comes into play.

What is the Vulnerability Exploitability eXchange (VEX)?

As defined by guidance from the U.S. National Telecommunications and Information Administration (NTIA), VEX’s primary use case is “to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.”

This is a lengthy way of saying VEX adds context to vulnerabilities to inform risk management activities. Much like other leading SBOM and software supply chain transparency and security guidance, VEX was born out of the NTIA’s Multistakeholder Process for Software Component Transparency. The guidance states that while VEX was developed for a specific SBOM use case, it isn’t limited to use with SBOMs or necessarily required, either.

Again, just because a vulnerability is present does not mean it is exploitable. This is critical information to know because with vulnerability management programs and activities, organizations are performing risk management. In cybersecurity risk management, organizations are looking to identify, analyze, evaluate and address cybersecurity threats based on the organization’s risk tolerance. This leads to the organization prioritizing risks based on likelihood and the severity of the risk materializing. Without knowing if a vulnerability is exploitable, it would be impossible to accurately project its likelihood.

Copyright © 2022 IDG Communications, Inc.

Related Articles

Leave a Comment