Many people confuse VEXes with
vulnerability notifications and wonder why there needs to be a VEX format at
all. After all, software suppliers have been providing notifications of new
vulnerabilities to their users for years. These notifications have been
provided in many human-readable forms, including email text, PDF attachments,
web pages, etc. They have also been provided in machine-readable forms,
including the CVRF format[i] and its successor, CSAF[ii] (the general
vulnerability reporting format on which one of the two VEX formats is based).
The VEX concept arose because of
the need to provide negative vulnerability notifications: Instead of
stating that a particular product and version(s) are affected by a particular
vulnerability (CVE), a VEX indicates that the product and version(s) are not
affected by the vulnerability. Is this the difference between a VEX and a
“traditional” vulnerability notification?
The answer is no, for two reasons:
First, A VEX document can provide a positive vulnerability notification, simply
by changing the status designation in a negative statement like “Product X
version Y is not_affected by CVE-2022-12345” to “Product X version Y is affected
by CVE-2022-12345”.
Second, a negative notification
can be provided in the same way as any positive notification is now delivered;
a VEX isn’t required for this. For example, instead of issuing an email stating
that a particular vulnerability is exploitable in their product (and therefore
customers need to apply a patch or upgrade), a supplier can send an email
stating, “None of our products is subject to the Ripple 20 vulnerabilities.” In
fact, it is safe to say there is nothing that a VEX document can do that a
“traditional” vulnerability notification cannot do; why are they both needed?
The difference between a VEX and a
traditional vulnerability notification has nothing to do with their respective
formats. Rather, the difference between the two is due to the fact that a VEX
is designed to address a particular use case: the case in which a software user
has utilized the list of components from an SBOM to find vulnerabilities that
might be exploitable in a software product (or intelligent device) operated by
their organization.
The VEX identifies vulnerabilities
that are a) listed in a vulnerability database as applicable to a component of
the product, yet b) are not exploitable in the product, taken as a whole. A
software tool that ingests SBOMs and VEX documents would utilize the VEX
documents to “trim down” the list of vulnerabilities identified for components
found in the SBOM, so that the only vulnerabilities remaining on the list are
exploitable ones[iii].
Another way that VEX documents
differ from traditional vulnerability notifications is that a VEX only makes
sense if it is “read” by a software tool. This is because, if a software
product just contains a small number of components and the supplier only needs
to notify their users that a few vulnerabilities are not exploitable in the
product, it would be much easier for the supplier to do this in an email.
Under these assumptions, users
could simply maintain a spreadsheet listing all the vulnerabilities identified
(in the NVD or another vulnerability database) for components of the product.
When they receive an email saying a vulnerability isn’t exploitable in the
product, they would simply delete the line in the spreadsheet where that
vulnerability is listed. Therefore, at any point in time, the spreadsheet would
list all the component vulnerabilities currently deemed exploitable.
However, the average software
product contains around 150 components and many products – including some
commonly-used ones – contain thousands of components. Clearly, trying to manage
exploitable component vulnerabilities using emails and spreadsheets will be
impossible when products like these are encountered.
Of course, VEX documents can be
used for other purposes than negative notifications (like the one just
described). For example, a VEX document can be used to notify customers that
one or more versions of a product are vulnerable to a serious vulnerability, as
well as provide a notice of a patch and/or upgrade path to mitigate the
vulnerability. However, given that almost every software supplier already has
some means to notify its customers that a serious vulnerability is exploitable
and a patch is available for it, why would a supplier want to use a VEX to
convey this notification?
While this is speculation, it is
possible that some suppliers will use VEXes for patch notifications like the
above (as well as other positive vulnerability notifications), because they a)
want to provide a machine-readable notification to their users and b) they are
already providing VEXes for “negative vulnerability notification” purposes –
meaning they have some experience with the format. Therefore, they might be
more inclined to experiment with a new use case for a format (VEX) they already
understand, rather than experiment with both a new use case and a new format.
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.
[iii] Of course, this is an aspirational goal. It will require
any supplier that provides SBOMs to their customers also to publish a VEX as
soon as they discover that a vulnerability listed in the NVD for a component
isn’t exploitable in the product. This will place a burden on suppliers and may
dissuade some suppliers from producing SBOMs at all, at least in the near term.
This is why I have proposed “real-time VEX”, as a way to greatly lessen the burden
on suppliers of providing negative vulnerability notifications to their
customers. See this post: https://tomalrichblog.blogspot.com/2022/08/whats-best-sbom-no-sbom-whats-best-vex.html
No comments:
Post a Comment