Vulnerability-Exploitability eXchange (VEX) documents as defined by the National Telecommunications and Information Administration (NTIA) “… 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. In many cases , a vulnerability in an upstream component will not be “exploitable” in the final product for various reasons (e.g., the affected code is not loaded by the compiler, or some inline protections exist elsewhere in the software).” (https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf).

SOOS supports exporting your own VEX documents, using the CSAF VEX JSON format as well as the VEX capabilities built into CycloneDX SBOMs as either JSON or XML documents.

Read our article about Generating VEX Documents to learn more about how to produce a VEX report in SOOS.

As a SOOS user generating VEX documents it is important to understand how SOOS issues are mapped to the various VEX statuses for the known vulnerabilities. Some of these mappings are automatic as issues move through various states, and some are manually set if an issue is suppressed.

In general when SOOS identifies a vulnerability, the corresponding VEX entry for the vulnerability will indicate that the vulnerability is present and exploitable. If a vulnerability has (or does not have) fixes available (i.e.: newer versions of a package that are vulnerability free), then the VEX entry for the vulnerability will additionally indicate that a fix is available (supplied by the vendor) or that no fix is available.

If an issue has been pushed to a ticketing system, then the vulnerability will be marked on the VEX report as 'pending' or 'in triage' (depending on the VEX format being used), however the VEX entry will still indicate the vulnerability is present and exploitable. Once a vulnerability has been resolved and SOOS no longer detects the presence of the vulnerable package in your codebase, then the next VEX document produced will no longer list the vulnerability.

In some cases the presence of vulnerabilities does not mean the code is inherently at risk; Perhaps a firewall is mitigating the issue, the vulnerable code is never called, or it’s deemed a false positive. In these cases, issues can be suppressed within the SOOS app, allowing the user to identify why the issue will not be fixed. When suppressing an issue it is important to be as specific as possible when entering information into the Suppress Issue form. The fields in this form map directly to VEX statuses and will be visible by anyone consuming your VEX document. Furthermore, providing accurate details here assures that those consuming your VEX document understand why the vulnerability is not being addressed.