A VEX server

 

In my last post, I pointed out that VEX documents can only achieve their purpose of preventing users from wasting massive amounts of their – and their suppliers’ help desk’s – time at a huge cost: Many suppliers will have to produce and distribute VEX documents (to individual IP addresses) in quantities of tens or hundreds of thousands, and in some cases millions, every day. Clearly, VEX documents are not a sustainable solution to the problem VEX was designed to address, namely identification of the small number of component vulnerabilities that are exploitable in the product itself.

My solution to this problem is for the supplier to maintain a “VEX server” containing the following information. Ultimately, the information needs to be maintained for each version of each of the supplier’s products that is in active use by customers:

1.      Vulnerabilities identified, in a major vulnerability database like the NVD, in components included in the product/version.

2.      The vulnerability database in which the vulnerabilities were identified. Normally, the supplier would only need to search one database, unless the customers require another.

3.      The exploitability status of each vulnerability: “affected”, “not affected”, “under investigation” or “fixed”. These status designations have the same meaning as in the two VEX formats.

4.      For every vulnerability with a status of “affected”, there needs to be a text field describing a mitigation for the vulnerability. Normally, the mitigation will be “apply patch XYZ found at URL.com” or “upgrade to the current version”.

5.      For every vulnerability with a status of "not affected”, there should be a machine-readable “status justification” field. If a supplier determines that the available justifications do not apply in the case of a particular vulnerability in this product/version, they may leave the field blank and instead fill in a text field describing why the vulnerability in question is not exploitable in the product. There are nine “justifications” in CycloneDX VEX, and five “status justifications” in the CSAF VEX profile. The latter are a subset of the former, although they have somewhat different descriptions. For a further discussion of status justifications, see this post.

This information needs to be updated in as close to real time as possible. The server needs to be available for 24/7 remote access by the supplier’s customers (the supplier will be able to control the product(s) for which a customer is provided access). The customers will utilize an API – embedded in SBOM “consumption” tools – to access the server.

In other words, instead of having to produce and distribute huge quantities of VEX documents daily, the supplier will simply need to update the server whenever they know of a change in the status of a vulnerability in a particular product/version - for example, when the exploitability status of a vulnerability in the product/version changes from “under investigation” to “not affected”, or when a new vulnerability appears in a vulnerability database for a component included in the product/version.

The VEX server will not necessarily be operated by the supplier. In fact, I believe that, because of the economies of scale to be achieved by centralizing VEX server operations, third parties will arise that will operate cloud based “VEX server farms” as a service to suppliers. The supplier will be responsible for updating VEX information for each version of each of their products that is being used by customers. However, the remaining maintenance, including maintaining access to the server by software customers of multiple suppliers as well as the suppliers themselves, will be the responsibility of the operator of the VEX server farm.

There is another reason why I believe it is likely that third parties will operate VEX server farms for suppliers: End user organizations are likely to require access to VEX information for many products. If an organization utilizes 500 different software products or intelligent devices from different suppliers, they will much prefer to access a small number of server farms operated by a small number of service providers, rather than 500 separate servers operated by 500 different suppliers.

API access will be authenticated. While access policy is at the supplier’s discretion, normally only a current user of a particular version of a product will be able to access the API information for that product and version. An API session will be initiated by a tool that is operated either by the customer or a third-party service provider acting on their behalf. I believe the API will be developed this year by a major SBOM-related open source project team.

The tool will “follow” versions of software products and intelligent devices that are operated by the user organization, and regularly (most likely daily) use the API to download the current complete set of VEX information for each of those products. At any time, the user will be able to retrieve from the tool (or the third party service provider using a similar tool) an up-to-date set of exploitable component vulnerabilities, perhaps formatted for ingestion by a vulnerability or configuration management tool utilized by the user organization. The user will also be able to download lists of non-exploitable (“not affected") vulnerabilities, as well as those whose status is “fixed” or “under investigation”.

In my opinion, the list of exploitable component vulnerabilities is the Holy Grail of SBOM-based vulnerability management (which I call “component-derived vulnerability management”), since this is the set of vulnerabilities that a user should actually be concerned about. This goal will never be achieved if we have to rely solely on VEX documents being distributed.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.