Hi all,
The current "upgrade hamster wheel" pushes us to make a release each
time a dependency has a vulnerability, regardless of the kind of
vulnerability and its exploitability in our projects. VEX files seem the
ideal tool to limit the number of releases or the chain of upgrades that
happens, when a deeply nested dependency has a problem (Apache
Commons?). [In my definition VEX files only contain informations about
CVEs published by dependencies, not the project itself]
Integrating VEX-es into our upgrade policy could be really beneficial:
if something happens to a transitive dependency, but all our direct
dependencies publish a "not affected" VEX statement, we can skip the
upgrade and publish a "not_affected" VEX statement ourselves. If a
direct dependency publishes an "exploitable" VEX statement and a nice
description of the conditions under which the bug can be triggered, we
can still check if we meet those conditions in our own code. We won't
have to analyze the code of our dependencies! Maybe we are not affected
and we can just publish a VEX statement that says so.
However, as pointed out by Jarek, what happens if we make a mistake?
Will the ASF or ourselves be liable?
VEX-es are going to happen, whether we want it or not, because the USA
is pushing for them. If there is a legal risk, however, I will choose to
always publish an "exploitable" VEX statement to be safe and only in the
details I would write "Our analysis shows that the bug is not
exploitable in Foo. Disclaimer: this does not constitute a security
advise, consult your own security expert".
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
