feat: added deduplication database table

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.19k stars 457 forks source link

feat: added deduplication database table #4206

Closed inosmeet closed 3 months ago

inosmeet commented 3 months ago

I've disabled the test_language_package_none_found test for FAIL-PKG-INFO because it didn't really make any sense. And python-parser for PKG-INFO or metadata was constructed solely to bypass this test which too didn't make any sense.

Also, adding the table in our existing database (cve.db) makes me wonder if I should add the purl2cpe table into it too. Let me know what you think @terriko @anthonyharrison

terriko commented 3 months ago

Hm, that's a good question. Quick brainstorm on pros and cons:

pro:

don't have to open two separate dbs into memory
might very slightly speed up the queries as a result

con:

cve.db will be that much bigger (though likely tiny compares to sheer volume of cve info)
less easy for someone to load their own custom purl2cpe.db into place for use (would anyone want this?)
does involve changing the code you have a bit

I don't think there's an obvious winner here, but if you think it's worth loading it in to cvedb, the cons seem pretty minimal.

terriko commented 3 months ago

BTW, since I didn't say in my nitpicky code review: this is looking good. I think we can punt on whether we need to add product into the dedupe table for now, but let's remove that test completely and probably not add the unknowns unless there was a reason for doing it that I misunderstood.