Tom’s note 6/30/2023: While I continue to believe that VEX's future is as a server/API, not as a document format, I no longer think what's described in this post is the right one. Rather, it's what's described in this post.
“Real-time VEX” is an API that
will allow a device on a software user’s network to query a server that resides
on a software supplier’s network (or perhaps is operated by a third party on
the supplier’s behalf). The API allows the user to determine the exploitability
status of a particular vulnerability (CVE) in a version of the supplier’s
product, which is operated by the user.
The use case for real-time VEX is
simple: When a user receives an SBOM for a software product they utilize from
the product’s supplier, they (or a tool or third-party service) will search the
NVD (or another vulnerability database) for vulnerabilities that apply to any
of the components listed in that SBOM. Whenever they discover an open
vulnerability (CVE) for one of those components, the user - or more accurately a
tool operated by the user, or a third-party service provider acting on the user’s
behalf - will assign the default status of “exploitable” to the vulnerability
for that version of the product[ii].
Shortly thereafter, the user’s
system will login to the supplier’s server and provide three pieces of information:
The supplier’s server will send
one of three responses:
- This CVE is
not exploitable in the product and version named.
- The CVE is
exploitable in the product and version named. Please immediately apply the
patch located at…(URL).[v]
- The
exploitability status of this CVE, in the product and version named, is
unknown.
The user or their system (or a
third party service provider) will take one of three steps:
- If the
vulnerability is not exploitable, the CVE will be marked as such in the
list of component vulnerabilities applicable to the version of the product.
Because it is possible the supplier might later change the status of the CVE
to exploitable, the user system will regularly query the supplier’s server
regarding the CVE’s status.
- If the
vulnerability is exploitable, the CVE’s status in the vulnerability list
will be left unchanged, since the default should be “exploitable” anyway. The
organization’s patch management team will be notified to download and
apply the patch to the product. After applying the patch, the CVE’s status
in the vulnerability list will be changed to not exploitable.[vi]
- If the status
of the vulnerability is unknown, the supplier’s server will be queried
regularly (probably multiple times a day) to learn if the status has
changed.
What is the advantage of real-time
VEX vs. relying on the supplier to prepare and transmit a VEX document that
indicates the exploitability status of a CVE? It is time. When a new
vulnerability appears in the NVD for a component included in a supplier’s
product and they subsequently determine that the vulnerability is not
exploitable, the product security team will not normally be inclined to drop
everything they are doing to prepare and distribute a VEX for their customers.
Even for just a few products, this
might happen ten or so times in one day. It would be very disruptive to getting
work done. For that reason, it is likely that most suppliers will batch their
VEX notifications and release them for example every three days. However, changing
the status of the CVE in the real-time VEX server will literally require almost
no time at all.
Why is time so important? As
previously discussed, a component vulnerability should always be considered
exploitable by the user organization when it is first identified. Since a user
has no way of knowing beforehand which CVEs may later be designated “not
affected” in a VEX document, they will need to investigate every one of them, especially
those of higher severity. If a VEX saying the CVE is unexploitable arrives for
example 2-3 days later, the user may already have wasted a lot of time on this;
and if this same situation happens multiple times a week, this will be a
significant problem for the organization. This is why the user organization needs
to learn about non-exploitable vulnerabilities as soon as possible after the
supplier learns about them.
With real-time VEX, the user will
be able to learn about non-exploitable component vulnerabilities almost as soon
as the supplier does – and just as importantly, the supplier will need to
invest almost no time at all in the notification. Upon learning that a vulnerability
is not exploitable, the supplier only needs to update the status of the CVE in
the real-time VEX server (and this will likely be handled by an automatic
update from the system used to determine exploitability of the CVE); the user
will learn about the change the next time they query the server. The supplier
will not have to do any more than this.
It is important to keep in mind
that the supplier itself will benefit as much from real-time VEX as the
customer. Especially for more severe component vulnerabilities, it is likely
that users will not be content to sit back and wait for a supplier to issue a
VEX to inform them that a vulnerability is not exploitable; they are likely to
call or email the help desk regularly about this. The sooner the supplier can
update the status information in the real-time VEX server, the less time their
help desk will waste giving the same answer to caller after caller.
The savings of time and
frustration that could be provided by real-time VEX, on both the user’s and the
supplier’s side, are likely to be substantial. Remember that over 90% of
component vulnerabilities are not exploitable in the full product. This means
it is possible that over 90% of the time and effort required by both the
supplier and end user, in responding to component vulnerabilities revealed by
SBOMs, will be wasted – unless the supplier quickly determines[vii] the exploitability
status of a CVE and communicates this to their customers.
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.
[i] There
are some other problems standing in the way of widespread SBOM use as well. Fortunately,
I think one of the biggest – the “naming
problem” – is at least on the road to being solved (or at least greatly
mitigated). More on that in the next week or two.
[ii] If
the user organization operates multiple versions of a single product, each
version will have its own list of vulnerabilities.
[iii] There
is no reason why a large number of these queries could not be entered at one
time.
[iv] Because
of the “naming problem” discussed earlier, it will not necessarily be clear
what constitutes the product name. Perhaps a CPE name or purl will be required in
lieu of a product name. The desired option will be chosen by the supplier and
will probably vary by supplier and product.
[v] If
the CVE is exploitable, yet there is no patch available, response 3 will be
sent. To announce the CVE is exploitable without a patch being available is of
course to court disaster.
[vi] This
statement is not technically correct. When the patch is applied, the version number
will be incremented, since two different codebases should never have the same
version number. The CVE will still be “exploitable” in the unpatched version,
but it will be “not exploitable” in the patched version.
[vii] Of
course, third parties can also make judgments about exploitability; however,
this is a different
type of exploitability that isn’t applicable to particular products, but
rather to the vulnerability itself. Because exploitability, in the VEX meaning
of the word, requires knowledge of how the software was constructed, the
supplier’s judgment in this matter will carry much more weight than that of a
third party.
However, this is not to say that, if a supplier simply
does not provide VEX documents or real-time VEX notifications to their
customers, there is nothing the customers can do on their own about this
problem. They can certainly scan the product with a vulnerability scanner; if a
component vulnerability does not appear in the list of active vulnerabilities,
this can be taken as evidence that it is not exploitable. But this finding can
never be considered to be as authoritative as the supplier’s statement regarding
the exploitability status of a particular CVE in a particular product and
version number.
No comments:
Post a Comment