feat: "language" parser for .deb control data

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.

GNU General Public License v3.0

1.19k stars 457 forks source link

Expanding out from https://github.com/intel/cve-bin-tool/issues/2621

.debs have a set of control fields which contain a bunch of information that looks awfully like the {vendor, product, version} tuplet we use for NVD lookups:

https://www.debian.org/doc/debian-policy/ch-controlfields.html

I think it should be possible to read these files similar to the way we read package lists.

For NVD lookup, we would want to intentionally build in some special cases for things like python files which are all packaged with the prefix python3- and so on rather than just assuming the name is correct, and maybe trying to do some nice parsing of the url included to see if that can be used to better guess the vendor.

The release-monitoring.org website may help you with names across distros. e.g. https://release-monitoring.org/project/3779/

Anyone working on this:

The language parsers are in the cve_bin_tool/parsers directory.
There's a readme explaining what you need to make a new parser: https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/parsers/README.md
Java Parser for example: https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/parsers/java.py

I've added the hacktoberfest link to this, so here's the cut and paste of info for new contributors:

Short tips for new contributors:

cve-bin-tool's contributor docs
If you've contributed to open source but not this project, you might just want our checklist for a great pull request
cve-bin-tool uses https://www.conventionalcommits.org/ style for commit messages, and we have a test that checks the title of your pull request (PR). A good potential title for this one is in the title of this issue.
You can make an issue auto close by including a comment "fixes #ISSUENUMBER" in your PR comments where ISSUENUMBER is the actual number of the issue. This "links" the issue to the pull request.

Claiming issues:

You do not need to have an issue assigned to you before you work on it. To "claim" an issue either make a linked pull request or comment on the issue saying you'll be working on it.
If someone else has already commented or opened a pull request, assume it is claimed and find another issue to work on.
If it's been more than 1 week without progress, you can ask in a comment if the claimant is still working on it before claiming it yourself (give them at least 3 days to respond before assuming they have moved on).

intel / cve-bin-tool

feat: "language" parser for .deb control data #2917