This is the first in a two-part series about VEX. Currently, VEX is going nowhere fast. I now know of just one organization – Cisco - that has even announced they’re producing VEXes for their products, although the only examples they linked to in their announcement were the same CSAF examples that appeared in CISA’s VEX Use Cases document, published in April 2022 (which also had CycloneDX VEX examples).
Another organization that was
producing documents that they called “VEX” – Red Hat – has changed their mind
about whether they are really VEXes, and has changed their name back to their
original name: security
advisories. They explained this to the SBOM Forum in a presentation more
than a month ago, but they also stated they will be putting out a new type of
document soon that they are calling a VEX (and since the only published VEX
definition – near the beginning of the same Use Cases document – essentially
just says a VEX makes statements about vulnerabilities, it doesn’t make sense
now to even debate what is or isn’t a VEX. If the author calls it a VEX, it’s a
VEX. End of story).
I want to point out that I don’t blame Red Hat for any of
this, since they have always been a leader in producing machine readable
vulnerability notifications (you’ll notice that the notifications on the page I
referenced above go back to 2001), as well as doing lots of work of benefit to
the software vulnerability management community. For instance, they sit on the
boards of both the OASIS CSAF group and CVE.org.
Moreover, they are one of a handful of Root CVE Numbering
Authorities (CNA) and are available to help open source software projects report
their own vulnerabilities, as well as proactively reporting vulnerabilities in
their own products. Pete Allor, Director of Product Security for Red Hat (and
an active member of the SBOM Forum), told me once that Red Hat almost considers
this their duty, because of their unique relationship with the open source
community.
But other than Red Hat and Cisco, I know of no organization that
has made any public announcement about producing VEX documents, and I have seen
no other VEX documents from any source, except for a few demonstration
documents.[i]
One of the biggest problems with VEX is that proving that a
vulnerability has “not affected” status (which is, of course, the main reason
that VEX was developed) often requires proving a negative. For example, if the
supplier believes there is no “code path” that would allow an attacker to reach
the vulnerable code (in order to exploit it), they would literally need to be
able to show that none of the perhaps thousands of paths an attacker might
utilize to reach that code will allow them to reach it, in order to “prove” the
vulnerability isn’t exploitable in the product.
However, the five “status
justifications” offer a way out of this problem. Whenever the status of a
vulnerability in VEX is “not affected”, a status justification needs to be provided
to justify the “not affected” status. Note that these are called “justifications”
in CycloneDX VEX, and there are nine of them, vs. five in CSAF. The CDX
justifications are a superset of the CSAF status justifications and were
developed almost two years before the CSAF ones.
While three of the status justifications suffer from the
need to prove a negative (they are “Vulnerable_code_cannot_be_controlled_by_adversary”,
“Vulnerable_code_not_in_execute_path”, and “Inline_mitigations_already_exist”),
two of them do not. They are “Component_not_present” (meaning that the
vulnerable component that appeared in the SBOM isn’t actually in the product)
and “Vulnerable_code_not_present” (meaning that, even though the component is
present in the product, in this case the vulnerable code has been removed from
the component).
Neither of the latter two status justifications requires
proving a negative. If someone is skeptical about either justification, it
won’t be hard for the supplier to prove it is valid. If a supplier asserts that
either one of these is the reason why they used “not affected” status, they
aren’t likely to be questioned.
Therefore, a way to “tighten up” the use of “not affected”
in VEX would be to require that it only be used in a case where the reason for
the “not affected” designation is either “Component_not_present” or
“Vulnerable_code_not_present”. In all other cases, every vulnerability should be
given the status of “affected”.
Of course, there may be some suppliers who aren’t bothered
by the fact that three of the status justifications require proving a negative
– plus some of their customers may be quite happy to accept all five status
justifications as valid.
In this case, there wouldn’t need to be any change from what
is now assumed in VEX: that all five of the status justifications are valid. In
fact, when there is tooling available to utilize VEX information, there could
be a simple software option: Those software users (e.g. hospitals, electric
utilities, and military contractors) that believe they require a higher
assurance level can choose the first option described, in which there are only
two valid status justifications. Those users that are comfortable with the
“looser” standard can accept all five status justifications, which will
probably be the default option when and if VEX “consumption” tooling appears.
How about the nine “justifications” in CycloneDX? They are:
- code_not_present =
the code has been removed or tree-shaked.
- code_not_reachable =
the vulnerable code is not invoked at runtime.
- requires_configuration =
exploitability requires a configurable option to be set/unset.
- requires_dependency = exploitability
requires a dependency that is not present.
- requires_environment =
exploitability requires a certain environment which is not present.
- protected_by_compiler =
exploitability requires a compiler flag to be set/unset.
- protected_at_runtime =
exploits are prevented at runtime.
- protected_at_perimeter =
attacks are blocked at physical, logical, or network perimeter.
- protected_by_mitigating_control =
preventative measures have been implemented that reduce the likelihood
and/or impact of the vulnerability
The CDX equivalent of “component not present” is “requires
dependency”. The CDX equivalent of “vulnerable code not present” is “code not
present”. High-assurance users might want to require that only these two
justifications be allowed to accompany a “not affected” status, while the other
seven justifications would require “affected” status.
How should these two options be positioned – i.e., the high
assurance and “normal assurance” VEX options? When and if end user VEX
“consumption” tooling appears, it should offer both options, although in
general it would be better to make the “normal” configuration (i.e., all five
status justifications are acceptable for “not affected” status) the default,
with the “high assurance” option (i.e., only the “component not present” and
“vulnerable code not present” justifications are acceptable for “not affected”
status) available for organizations that believe they need that.
Perhaps the best aspect of this tooling flexibility is that it
places no burden on the supplier. As long as they provide one of the standard
five CSAF status justifications (or one of the nine CDX justifications) whenever
the status of a vulnerability is listed as “not affected”, the end user will
make the decision, through their tooling choice, of how it will be interpreted.
I feel that uncertainty regarding questions like the above is inhibiting production of VEX documents by suppliers; what I’m suggesting here may somewhat alleviate that uncertainty, although it is hardly the only problem with VEX. In the exciting Part II of this series, I’ll tell you about another important development affecting VEX, which may also help to make VEX more palatable to suppliers.
[i] You may have heard of OpenVEX, which is sometimes pointed to as a third VEX format. I think it’s a good format, but it’s for a different use case than VEX was originally developed for: clarifying for software uses which component vulnerabilities they learn about through an SBOM should not be a cause for concern.
OpenVEX addresses the use case of software scanners that throw off false positive vulnerability findings; it allows a supplier to list – in a machine readable format - typical false positive results for their products. A scanner vendor can consume these documents regularly, and thus not show those false positives in their scan results. That’s a great use case and I imagine OpenVEX does it well, but it has nothing to do with SBOMs.
OpenVEX can be used for the “original” VEX purpose as
well, but it’s limited for that because it doesn’t treat version numbers
independently of the product names. Instead, it creates synthetic “products”
that combine the product name and the version number. This makes it impossible
to create version ranges, which are essential for the original VEX use case (I explained
that limitation in this post).
But since, as I just said, there’s no specific definition of what a VEX is, I’m
fine if OpenVEX keeps using the name for their product.
No comments:
Post a Comment