Hello, I got a response from trivy, https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531
> Helllo @superlazyname <https://github.com/superlazyname> > Thanks for your report! > As you can see - we marked this vulnerability as "Status": "will_not_fix", . > We use will_not_fix for vulnerabilities with ignored State. > We can't parse State description, because it deoesn't have format. > [bookworm] - zlib (contrib/minizip not built and producing binary packages) > It seems that debian chose wrong state. not_affected looks more correct. ------------------------------ > Trivy supports VEX <https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>. > You can create VEX file to ignore this CVE. > Regards, Dmitriy I'll call out these particular points, > We can't parse State description, because it doesn't have format. > It seems that debian chose wrong state. not_affected looks more correct. It sounds like this is some kind of incompatibility between how trivy conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology problem on the meaning of "ignored" (won't fix vs is not affected) - Would you consider marking the vulnerability as "not_affected" instead of "ignored"? Or does the Debian CVE tracking system not support that? - I would agree that " [bookworm] - zlib (contrib/minizip not built and producing binary packages)" doesn't have a standard format, but is there no other viable way for a scanner to pick up on the CVE being ignored? - Do you have docs to show what method should be used to properly handle this issue being marked as "ignored"? Do you have any sample code / script snippets you can share with me? Maybe I can submit a PR? Maybe there is some way for trivy to notice that the issue is "ignored" and then, for only Debian, interpret that as not_affected. - John On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso <car...@debian.org> wrote: > Hi John, > > On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote: > > This report came from a free tool, trivy, I filed a Github discussion > about > > it here: https://github.com/aquasecurity/trivy/discussions/6722 > > Thanks a lot for bringing that upstream. > > So to add some additional datapoint: The issue araises here by maybe > thinking zlib refers to the binary package produced. It is correct, > for the binary package zlib then indeed you would not be vulnerable. > > Let me as well elaborate on the "ingored". This comes as the binary > packages built from the *vulnerable* source, there is no point to > force an update in bookworm and older. > > I hope this all get a better picture now on the CVE. If you still have > questions feel free to ask. > > Regards, > Salvatore >
