Hello, I was thinking about this a bit more and I had a question,
> 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. It sounds like Debian uses the "ignored" state to mean "this bug does not affect the Debian package". Is there another state that's used to indicate "won't fix"? Can we assume that "ignored" always means "won't fix"? Or can "ignored" mean either thing and we'd have to look in the notes to know for sure? Thanks, - J On Wed, May 22, 2024 at 9:56 AM John Waffle <jwaff...@gmail.com> wrote: > 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 >> >
