You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just closed #3633 from @ffontaine which would have removed a debianutils checker because it doesn't have any CVEs. On one hand, we're primarily a CVE scanner so it's kind of a waste of cycles to check for a product that doesn't have any CVEs associated with it. But I decided to keep it for two reasons:
It could have CVEs later and we'd want it then.
A number of users have told me that they're using cve-bin-tool to help with software composition analysis, so in that case they'd want to know that debianutils was there even if there are no CVEs associated.
Those of you who've been around this project a while know I have some mixed feelings about using cve-bin-tool for software composition analysis (that is, trying to guess what's in a binary blob), mostly because I don't think we're great at it. But the best tools I know of for this cost $$$ so I've gradually come to accept that maybe we're a useful tool for folk who don't have access to paid tooling. In the past year or so, we've started adding features to make it easier for us to do things like generate SBOM data.
But I'm wondering if we could limit the wasted cycles involved in keeping a checker that doesn't have security issues, so I'm opening this up for discussion: Does anyone have any brilliant ideas about the best way to do this?
To kick off brainstorming, here's some ideas that I don't love but might work:
provide a script that checks CPEs and outputs a config file disabling any checker that doesn't have CPEs associated
provide a default config file with these checkers disabled and a note explaining why
have a way to flag checkers as no-CVE checkers and run them only if someone is generating an sbom or explicitly asks for them
The text was updated successfully, but these errors were encountered:
terriko
added
the
discussion
Discussion thread or meeting minutes that may not have any trivially fixable code issues associated
label
Dec 19, 2023
It is currently the case that most checkers with no CVEs detected also dont' have valid CPE / vendor_product strings. We'll have to make sure any solution for #3628 can handle these appropriately.
That said, if we have some sort of consistent way to represent these such as "leave the vendor_product blank or set it to a specific tuple" then that would make it easier to skip these checkers during normal operation and have them run only when a special flag was set or something.
I just closed #3633 from @ffontaine which would have removed a debianutils checker because it doesn't have any CVEs. On one hand, we're primarily a CVE scanner so it's kind of a waste of cycles to check for a product that doesn't have any CVEs associated with it. But I decided to keep it for two reasons:
Those of you who've been around this project a while know I have some mixed feelings about using cve-bin-tool for software composition analysis (that is, trying to guess what's in a binary blob), mostly because I don't think we're great at it. But the best tools I know of for this cost $$$ so I've gradually come to accept that maybe we're a useful tool for folk who don't have access to paid tooling. In the past year or so, we've started adding features to make it easier for us to do things like generate SBOM data.
But I'm wondering if we could limit the wasted cycles involved in keeping a checker that doesn't have security issues, so I'm opening this up for discussion: Does anyone have any brilliant ideas about the best way to do this?
To kick off brainstorming, here's some ideas that I don't love but might work:
The text was updated successfully, but these errors were encountered: