On Wed, Feb 5, 2025 at 9:41 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
> 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. Jup. > 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] > That is indeed interesting (see also https://cwiki.apache.org/confluence/display/SECURITY/Dealing+with+security+advisories+for+dependencies), though I've seen relatively few projects successfully consume VEXes yet. Of course it's a bit of a chicken-and-egg thing. 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 Possibly (or perhaps doing the update but not rushing a release) > and publish a "not_affected" VEX statement ourselves. In this case, shouldn't downstream projects consume that upstream VEX themselves? I'm not sure we should repeat that information. > 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. > This would be interesting. It would also be nice to be able to accept such statements/descriptions as contributions. > 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". > IANAL, TINLA, but: I don't see a reason to treat this any differently to any of the other 'possibly wrong' things we publish, such as code, documentation, and license information. So we should apply our regular common sense and review/monitoring processes for VEX information just like we do for code and releases, and then publishing a 'not affected' statement (perhaps with a "Disclaimer: this does not constitute a security advice, consult your own security expert" note) should be fine. In the end it is in everyone's interest that we share this information if we have it. Companies that apply our software in particularly-risky areas will still have to do their own due diligence, the same way they don't take our word for "it's Apache 2.0 licensed" but do additional checks there as well. Kind regards, -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
