I'm with MarkT on this one. We publish CVE all the time that may state "Apache Foo 1.0 was affected, fixed in 1.1, 2.0 was not affected". And we sometimes get that wrong, if 1.1 didn't fix the CVE or 2.0 was affected we issue a new and different CVE. The act of publishing a new CVE is the call to action and is designed to ensure any automation or downstream statements propagate the right info.
We also make statements about big issues all the time that don't affect various components in non-machine readable format, and also case by case by email to our users questions. VEX is a dynamic document and designed to have the state change, so making a mistake is simply corrected by an update. I'd see no problems with us issuing VEX and making 'not affected' statements. (I've not looked at VEX in much detail, but I did work to implement OVAL at Red Hat which had a similar machine readable version list, and VEX has replaced: https://www.redhat.com/en/blog/vulnerability-exploitability-exchange-vex-beta-files-now-available ) Regards, Mark J Cox ASF Security On Thu, Feb 6, 2025 at 8:10 AM Mark Thomas <ma...@apache.org> wrote: > On 05/02/2025 14:53, Jarek Potiuk wrote: > >> If this is true, then I don't see how anyone, ever, would issue a > > "not affected" statement as mentioned by Arnout. > > > > Yep. I don't see it either. I would not do it for sure if I knew what > legal > > implications it brings. > > > > This is why my response to those questions are like this: > > > https://github.com/apache/airflow/discussions/44865#discussioncomment-11656354 > > and this https://github.com/apache/airflow/discussions/40590 and I would > > never, ever respond differently. > > > > It makes some of our users angry, but I don't see how I can answer > > differently currently without putting ASF and myself at risk. Not until > we > > have clarity on how to do it at least. > > I think risk of the scenario outlined a couple of messages earlier in > this thread (and shown below) happening is very low. > > The statement that Apache ABC is "not affected" by a CVE is no different > to the statement that the CVE "is mitigated" in Apache ABC by doing X. > > We (and everybody else writing software) have been doing the latter for > years. Sometimes we get it wrong, and the result is simply a new CVE > with the updated (hopefully complete) mitigation. > > I don't see how VEX introduces a new risk here. > > Statements around CVEs have always had the implied caveats of "To the > best of our knowledge...", "As as as we are aware..." etc and I don't > see why VEX statements should be any different. > > I certainly doesn't hurt to be more explicit about stating these caveats > and I think there are benefits to being explicit. But I don't think > there is a big new risk here. > > Mark > > > > J. > > > > > > On Wed, Feb 5, 2025 at 3:44 PM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > >> Hi. > >> > >> Le mer. 5 févr. 2025 à 13:51, Jarek Potiuk <ja...@potiuk.com> a écrit : > >>> > >>> And let me repeat what I wrote on slack today: > >>> > >>> For ASF the legal risk is huge. If someone gets billions of dollars in > >>> damage because they trusted we told them "we are not vulnerable to this > >>> 3rd-party vulnerability" - they might sue ASF and demand all our > >> trademarks > >>> as compensation (not the money we have in the bank). This is is a HUGE > >> risk > >>> for ASF and the whole open-source community if you ask me. > >> > >> If this is true, then I don't see how anyone, ever, would issue a > >> "not affected" statement as mentioned by Arnout. > >> > >> Regards, > >> Gilles > >> > >>>> [...] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > security-discuss-unsubscr...@community.apache.org > >> For additional commands, e-mail: > >> security-discuss-h...@community.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > >
