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 don't think there is any expectation on how long "in triage" will be, 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 can set "in_triage" - even automatically for all CVEs in all 700 dependencies - that could be easily automated for volunteer driven projects with many dependencies. If that would be our approach - fine (exploitable etc we can also set it in case we have log4j). we can set "false_positive" (also automatically) for all the dependencies that are "accidentally" in our SBOM (though I'd rather fix SBOM in this case). And yes, we can even play around that automation to make it manageable and maybe even "sometimes" set a different stage there. But there are some caveats/ 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. 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. 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 **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). 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). 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. J. 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 > >
