search

intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.23k stars 464 forks source link

Discussion: what's next? #2451

Closed terriko closed 6 months ago

terriko commented 1 year ago

Normally we'd chat about this in a monthly meeting but since I'm intending to cancel the one for December I figured I'd bring the discussion here.

The question is: What's on your cve-bin-tool wishlist? I want to know about features, fixes, or even hare brained ideas. Here's a few of mine to get discussion started:

  1. Setting up our own NVD mirror in github and using it by default. (maybe for the other data sources as well?) One of our biggest challenges is somewhat dubious reliability of the NVD servers. I'd like to spend some time setting up our own mirror, letting people configure mirrors, and letting people maintain and use their own mirrors. We need to make some decisions about the data format(s) we provide (it would make tests easier if we provided both parsed and unparsed data) and adjust a lot of code to make it happen.
  2. Triage improvements. I talked about this in #2427
  3. Exporting SBOMs. @anthonyharrison says we should be pretty close on this one.
  4. SBOM quality tools. I've talked a few times about how handy it would be to have tools for improving SBOM data quality: merging with de-duplication, improving meta-info such as {vendor, product} pairs or licenses. I'd originally hoped to make a separate project for these but I think it might make sense to fit it into cve-bin-tool to go with our own SBOM export

And not exactly a wishlist item, but we still have the impending change of NVD API 2.0's complete switchover that will likely necessitate a 4.0 release sooner rather than later.

anthonyharrison commented 1 year ago

@terriko I think 2 is where the tool can start to add some real value if some of this can be automated particulaly if this starts to line up with some of the initiatives which are happenning in this area (CSAF, VEX, ...)

  1. I should have a solution soon - just need to handle multiple instances of the same product but different versions

  2. I already have some tools in work which will help with this, in particular merging SBOMs together; not quite ready for release but pretty close. I don't know whether the tols should be integrated into the tool or used by the tool (as libraries). Something to think about...

5 (New) Add some metrics management so it is possible to see trends of vulnerability scans etc.

6 (New) Provide an API wrapper (maybe as a separate project) so that cve-bin-tool facilities can be accessed programmatically

7 (New) The number of parameters is now a lot. I wonder if there should be a way of automatically creating the config files to be used

terriko commented 1 year ago

2 - Re: triage being a potentially a huge contribution. It's a gap I'm seeing in the tooling we use at work. Some of the tools export SBOM data, but very few have a standardized triage method. Figuring that out for us and getting involved in more of the initiatives continues to be a great idea. (@anthonyharrison is already involved, but I haven't been as much)

5 - Metrics is a good idea. A few things I've been asked in the past few months: What's a "normal" number of vulnerabilities for a minimal linux distribution and how many of those are "real" vs those who have backported fixes. How many cves turn out to be incorrect/spurious? (We have some in our own triage file for cve-bin-tool!) How long does it take for "upstream" to fix issues? How long does it take for us to fix something after a fix is available? How much time do we spend with open High risk items (or low, or medium)?

7 - It would be awfully nice to auto-generate an annotated config the way you can with stuff like bandit and maybe encourage people to use that as their default.

8 (new) Experimenting with scanning large number of github repos and publishing graphs/results highlighting any interesting findings. Maybe quietly helping with automatic pull requests? (This might be more of a gsoc project than a new feature, though)

terriko commented 6 months ago

We've done a lot of these since this discussion! I'm going to go ahead and close this one but we'll probably have a similar discussion sometime soon.