We (as a company) are publishing VEX (in CSAF) statements and we think about them as we do about any other piece of code that enters our codebase: Every statement needs a review by a second person.
I know that not every ASF project follows a review-then-commit workflow. Personally I'd say a PMC vote is too much but a review process makes sense to me. We looked at dozens of tools and couldn't find one to support such a workflow so we engaged with an open-source project and got it implemented there: https://github.com/MaibornWolff/SecObserve On Thu, Feb 6, 2025 at 9:39 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > Also - should we vote on VEX's publishing/release with that information > and have 3 +1 PMC votes? This is what we do with code we release with > fixes, and this is the legal act of foundation. > > On Thu, Feb 6, 2025 at 9:37 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > And let me explain the difference vs. when we talk about "our" code. > > > > * When we release a fix to CVE in our code, the code we release is covered > > by the ASF 2,0 licence. Clearly and plainly. No responsibility whatsoever. > > * What happens when we release a statement about others code? If we add > > ASF 2.0 licence to VEX file - does it cover the liability ? it's not the > > code we are releasing, we are releasing metadata about other's code. Is it > > covered by ASF 2.0 licence we attach to the VEX? I am not sure.IANAL. But > > at least we - as a Foundation with legal and our board eventually should > > discuss this and agree what is our interpretation. Or maybe come up with a > > different licence, or amendment to the existing licence. > > > > I am just not at all sure that the current licence is good for that case. > > > > J. > > > > > > On Thu, Feb 6, 2025 at 9:22 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > >> > I don't see how VEX introduces a new risk here. > >> > >> It really depends on whether the VEX entry states: "Not affected" or > >> "Possibly not affected". As you see in my responses - those are exactly > >> what I am explaining in my responses is exactly what you explained. In one > >> of those issues I responded to the user that "we do not use that affected > >> functionally, so likely we are not affected". But yet the user demanded, > >> and expected and was very persistent about it, to have 100% certainty and > >> an authoritative answer. > >> > >> I am absolutely fine in putting in VEX: > >> > >> * don't know, did not check (when we did not want to spend days > >> investigating it and it's difficult) > >> * possibly not affected (when we think we are not affected) > >> * affected, please upgrade (when we know) > >> > >> All those are fine, and if in the VEX we will be able to do it and be > >> very clear that this is the meaning, I am perfectly fine with it. > >> > >> But I would - under any circumstances - never put "Certainly not > >> affected" there. And this is what all commercial users will be expecting. > >> None of the above answers (except affected) is satisfying to the consumer > >> of VEX if you ask me and it's pretty useless. > >> > >> > >> J. > >> > >> > >> On Thu, Feb 6, 2025 at 9: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 > >>> > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
