VEX documents are designed to alleviate this problem . A VEX essentially states , in a machinereadable format , “ Even though this vulnerability ( e . g ., CVE-2021-12345 ) has been identified in one of the components of our product A , it is not in fact exploitable in product A itself .” 5
There are currently ( as of June 2022 ) two VEX formats , both machine-readable . One is based on the OASIS CSAF vulnerability notification format . 6 The other is based on the OWASP CycloneDX SBOM format . 7
Today , two types of SBOMs are regularly developed , although they are not typically distinguished one from the other . One type is for user-managed software products – i . e ., software that is intended to be installed on a standard hardware platform such as an Intel™ X86-type server 8 operated under the control of a standard operating system , such as Microsoft Windows™ or Linux . The decision about what user-managed software to install on a particular server or workstation and when it will be installed is almost always left up to the user organization . By the same token , the user organization is required to perform all maintenance on the software , including patching .
The other type of SBOM is for the software and firmware installed in a device , typically an IoT or IIoT device . A device differs from a user-managed software product , primarily because all software necessary for the operation of the device is pre-installed by the manufacturer . The device is usually provided as a sealed box that cannot be opened by the end user . Patches and other updates to the software are usually remotely applied by the supplier , often without being subject to any control by the user .
The manufacturer of a device often does not manufacture the hardware or develop the software included in the device . Instead , they put the pieces together to achieve the purpose of the device . While the software products installed on a device are usually developed , sold and supported by different suppliers , legally and practically the manufacturer of the device is solely responsible for choosing , installing , patching and updating those software products .
5
The VEX document can be used to make almost any notification about vulnerabilities , not just a notification that a particular vulnerability is not exploitable in a product . However , unlike most “ traditional ” vulnerability notifications , the VEX is machine-readable and the data it contains can be incorporated into many automated processes .
8
For the purposes of this discussion , it makes no difference whether the server is physical or virtual . Journal of Innovation 73