VEX adds context to software vulnerabilities to better inform risk assessment decisions. Credit: NDAB Creativity / Shutterstock 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. How VEX adds context and clarityHow does VEX solve this challenge? It empowers software suppliers to issue a VEX, which is an assertion about the status of a vulnerability in a specific product. VEX supports four primary status options:Not affected: No remediation is required regarding this vulnerability.Affected: Actions are recommended to remediate or address this vulnerability.Fixed: These product versions contain a fix for the vulnerability.Under investigation: It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.With the SBOM itself as an example, we’re seeing a push toward machine-readable artifacts and documentation, which enables better automation, accuracy and speed. We’re seeing similar trends in the realm of compliance with NIST’s Open Security Controls Assessment Language (OSCAL), which brings traditional paper-based security controls and authorization documents into a machine-readable format.VEX is doing something similar, avoiding the need to email security advisories or details about vulnerabilities and recommendations, and instead bringing that information into a machine-readable format to foster automation and the use of modernized security tooling that moves at a pace much closer to the current thread landscape than humans and manual activities. As the push for software supply chain transparency and security evolve, it isn’t hard to imagine a world where enterprise software inventories are able to be visualized in dashboards and tooling, along with their associated vulnerabilities and the actual exploitability of the vulnerabilities, all empowered by SBOM’s and accompanying VEX data.That’s a stark contrast to the modern ecosystem where most organizations don’t have accurate inventories of the software components they consume and have deployed, nor the vulnerabilities associated with it. This is all despite the reality that modern software is overwhelmingly composed of open-source software (OSS) components, with some estimates reaching as high as 80% to 90%.The guidance also states that while VEXs can be authored by a software supplier, they can also be authored by third parties, leaving users in a position to determine how to use the data. This makes it easy to see scenarios where security researchers and vulnerability vendors may make attempts to produce VEXs for products as part of their own product offering.VEX resourcesThe SBOM initiative moved from NTIA to the U.S. Cybersecurity Infrastructure Security Agency (CISA), coinciding with a move of SBOM evangelist and leader Dr. Allan Friedman. In 2022 CISA has published two additional VEX documents. One is the VEX Use Cases document and the other is the VEX Status Justifications document. The VEX Use Cases document provides minimum data elements of a VEX document, much like NTIA defined the minimum elements for an SBOM (as tied to the cyber EO). In this guidance, it states that a VEX document must include the VEX metadata, product details, vulnerability details and product status. These product status details include status information about the vulnerability in a product and can be not affected, affected, fixed or under investigation.The VEX Status Justifications document subsequently focuses on the requirement for VEX documents to contain a justification statement on why the VEX document creator chose to assert that the product’s status is not affected, if they indeed did make that choice. This allows suppliers to provide justifications for why a product is not affected by a vulnerability. Options include the component or vulnerable code not being present, the vulnerable code not being able to be controlled by an adversary or the code not being in the execution path, and lastly the existence of inline mitigations already being in place in the product.VEX represents a key next step in assisting SBOMs become actionable by providing contextual insights and assertions from product vendors about the exploitability of vulnerabilities present in their products. By using both the minimum elements as defined for VEX documents and their associated not affected justification fields, if applicable, software producers are able to empower software consumers for make risk informed decisions to drive their vulnerability management activities as part of broader cybersecurity programs. Related content how-to Download the SASE and SSE enterprise buyer’s guide From the editors of our sister publication Network World, this enterprise buyer’s guide helps network and security IT staff understand what SASE (Secure Access Service Edge) and SSE (Secure Service Edge) can do for their organizations and how t By Neal Weinberg May 13, 2024 1 min Remote Access Security Network Security Enterprise Buyer’s Guides news IntelBroker steals classified data from the Europol website The agency said core operations remain unaffected even as IntelBroker claimed to possess classified, law enforcement data. By Shweta Sharma May 13, 2024 3 mins Data Breach Hacker Groups feature Ridding your network of NTLM The path to eradicating this ancient protocol and security sinkhole won’t be easy, but the time has come for its complete eradication. By David Strom May 13, 2024 8 mins Authentication Windows Security Network Security news CISA inks 68 tech vendors to secure-by-design pledge — but will it matter? CISA’s pledge drew some big names, but the impact on software security could be limited. Meanwhile the org has extended its comment period on the CIRCIA cyberattack reporting law. By Jon Gold May 10, 2024 4 mins Regulation Technology Industry Security Practices PODCASTS VIDEOS RESOURCES EVENTS SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe