On Thu, Feb 6, 2025 at 10:53 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> Yes. That's exactly the problem Piotr. We have no "we don't know and we > will likely never tell you". Unless we use "in_triage" for that. I think we can just leave those advisories out of the VEX entirely. > but except some specific cases, I don't see how our VEX's could have > anything else > than "in_triage" for vast majority of CVEs > I also expect the vast majority to remain unspecified. > QUESTION: I wonder what are you all thinking about what should the VEXes be > published about? Should we publish it for all versions released? > When Airflow (for example) has 700+ dependencies and we have about, 50 of > `2.*` airflow packages released + about 90 providers (each with 20 > versions of so) - this is about 2000 vex files to keep updated every time > one of those versions of one of those libraries we publish gets updated > with a new CVE - if we were to publish them for all versions our users can > have in the maintained line. > > So the only way we can do it is to automate generation of those VEXs, > putting "in-triage" everywhere - realistically. But there is absolutely no > way any of those entries will be "not affected" in scale. Maybe there are > few cases where I could have certainty and "know" it's not affected - but > anything else requires a lot of time to even get close to a conclusion > (multiplied by 100s or 1000s of vulnerabilities and potentially multiplied > by all the versions we released). I am almost sure we cannot set > "exploitable" as well with any reasonable certainty. because that requires > manual checking if the problem is exploitable in particular versions. We > could of course put "exploitable" in all cases, but that would miss the > point of having this state informative. > I think we should update the VEX only if we have new exploitability information. > Of course - we could also put only information about those issues someone > ask us for, but in no-time this will be automated by commercial users and > we will get asked about every single CVE published for any of our > dependencies - this will happen a day after those commercial users will be > asked to use those VEX's in their analysis. We will get flooded by > questions 'what is the state of this or that dependency". In no time at all > we will have to put the state for All CVEs in all our dependencies when we > publish VEX. > Yes, users will continue to try and ask us about advisories in dependencies, and we should continue to tell them to do their own research (and maybe contribute to the VEX, though I don't expect that to be common ;) ) - https://security.apache.org/report-dependency/. > If we don't automate it, we have no chance to deal with that - simply > because our current work on analysing those will get multiplied by 10 or 20 > or 700 times, depending on how many dependencies we have. Even if we limit > ourselves to direct dependencies and rely on their VEX's. I am afraid that > will end up with everyone putting stuff to "in_triage' and calling it a day > eventually - I don't see how other open-source projects could do it > differently. > > Of course we can start thinking how to make it more "reasonable" - i.e. > built in the fact that we have volunteers and limited time. > > I can think of one way we could make it manageable - we only publish VEX's > for the last released version in the "maintained" line of a package - that > could give better chances that what is there is "right" - and reject any > requests and questions about past versions - essentially "freeze" VEXs for > previous versions when we release a new one. That seems fine to me. > That **might** have a chance > to work, because in the vast majority of cases the CVES found in 3rd-party > libraries will be for old versions of those that we won't use already in > the last version. That would dramatically drop the exposure for users > asking for state (providing that we automate that and filter out > automatically and reject the questions about past versions - it's pretty > doable). I don't think we need anything too fancy for that, but sure. > We could even - in this case make a dependabot-style automated and > proactive work, whenever a vulnerabilty is detected in a library, we could > see if it is already updated in the "in-progress" version and act > accordingly and automatically publish state in the last VEX "in_triage" for > example, and maybe have a way to manually review and update those (but only > for last released version in the maintained line). I'm not sure that would be useful - users are going to be asking us about those versions anyway, whether we set those or not. I could see us publishing SBOMs for the main branch, so we can easily answer the question of "will this be updated in the next version?", though. > We could allow > indefinite "in triage" in this case if we are not sure, and maybe sometimes > - very rarely we could put "not affected". but that would be a unicorn > IMHO. > > But then - except the few exceptions - there is no real value from having > such VEXs if you ask me. That will become a cargo cult very quickly. > I agree we should keep them minimal. Kind regards, Arnout On Thu, Feb 6, 2025 at 10:02 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> > wrote: > > > Hi Jarek, > > > > On 6.02.2025 09:22, Jarek Potiuk 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) > > > > I think I understand, where the problem lies. Looking only a > > CycloneDX[1] there are two important fields to describe a VEX entry: > > > > * A `state` field with values in: resolved, resolved_with_pedigree, > > exploitable, in_triage, false_positive, not_affected. There is no > > "possibly not affected" state. > > > > * A `detail` field, where we describe the problem to humans, including > > how we did come to a certain conclusion: > > > > ``` > > > > Detailed description of the impact including methods used during > > assessment. If a vulnerability is not exploitable, this field should > > include specific details on why the component or service is not impacted > > by this vulnerability. > > > > ``` > > > > I believe that as long as we fill in this carefully, the risk for the > > Foundation is minimal. The whole point of publishing a VEX statement > > (currently optional) is NOT to use an `exploitable` state and write "We > > did not perform any exploitability analysis, but unit/integration tests > > show that the patched version of `libfoo` is compatible with our > > library. Please upgrade the vulnerable component." > > > > Piotr > > > > [1] https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis > > > > > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
