What is a Vulnerability-Exploitability eXchange (VEX) Report?

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 sbom export and sbom manager licenses support 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 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 creating issue suppressions & attestations docid\ inbrolrzqnfvkihn08fnd 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 my vulnerability doesn't have a fix available docid\ thil4la2txixpahjdo4kv ) 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 a creating tickets & pull requests docid\ nciuaesesmhdpuaddbfk4 has been created, 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 creating issue suppressions & attestations docid\ inbrolrzqnfvkihn08fnd within the soos app, allowing the user to identify why the issue will not be fixed when attesting an issue it is important to be as specific as possible when entering information about the attestation the fields in the 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