Also noting from #3605 -- @ffontaine has beenfinding invalid ones in older code. Some of that may be due to CPEs changing over time, some may just be because I trusted submitters too much and didn't double-check every thing manually when I approved the original PR.

We may also want to run the validation script on all of the VENDOR_PRODUCT entries once a week or something and have it open up issues if any of them become invalid.

Quoting from #3363 on the topic of allowing "invalid" checkers: so it's here and easy to read:

If such kind of checkers is kept, it means that the solution designed for #3628 will have to explicitly handle such of kind of checkers.

Moreover, it also means that if for some reason in the future, a CVE is allocated for debianutils but with a different CPE ID that the one that was "randomly" chosen in the checker (e.g. debianutils_project:debianutils instead of debian:debianutils), cve-bin-tool will wrongly report them no CVEs affect debianutils.
So, I would agree to not run those "incomplete" checkers by default even for SBOM generation.

Originally posted by @ffontaine in #3633 (comment)

Hello @terriko , I want to work on this . How should I proceed?

@crazytrain328 I'd probably start by writing a python script that takes a checker *.py file and checks to see if each thing in the VENDOR_PRODUCT list provided has any CVEs associated with it.

So basically, parse out VENDOR_PRODUCT and run something like
SELECT count(*) from cve_range where vendor = % and product = %

with % replaced by each {vendor, product} pair you need to look up.

We don't really have a function for this in the existing cvedb class, so you can pretty much just jam some sql into your new script and tell it to use the same database name.

(eventually you might want to use the cvedb class to make sure the database is there and is up to date, but for a first pass that doesn't need to be in the script)

Hello @terriko ,
I have been reading more about the repo and also have been learning how to set-up github actions for this kind of pre-checker.
I have a doubt.
According to what you said above, I have to take a checker.py and parse out its VENDOR_PRODUCT list. How do I look up the database after that?

@crazytrain328 you might find my experiment script from the version compare investigations useful:

https://github.com/intel/cve-bin-tool/blob/main/experiments/sqlite-experiments.py

I won't say that that particular file is great coding, since it was never intended to be used "in production" as it were, but it should be enough to get you started with a minimal connection to the database and hwo to run a sql query manually

It's got a pretty minimum connection setup:

dbcon = sqlite3.connect("/home/terri/.cache/cve-bin-tool/cve.db")
dbcon.create_function("regexp", 2, lambda x, y: 1 if re.search(x, y) else 0)
cursor = dbcon.cursor()

(You don't need the regexp function if you're not doing regex searches.)

And then the rest of the file is a bunch of select statements that work against the db and output some data. You could copy that file, change out the home directory to match your name instead of mine, and edit one of the cursor.execute lines to contain whatever you actually want to look up.

Hello @terriko
I am having problems regarding setting up the database for cve-bin-tool. I am installing it , and it is always saying server disconnected, I have perfect internet connection but it always same.

@crazytrain328 Are you using an NVD api key or the mirror? I ask because NVD does sometimes just won't connect, especially for folk on windows -- we actually download our cache on linux and copy it to windows for that reason. But the mirror should be more generally available even if NVD is misbehaving.

I got it! I ran the initial script and am able to parse out whether all the vendor_product pairs have associated cves or not .
But it is on my local . How do i get the script to run in the environment of the tool?

Are you asking how to run it in github actions? You can look at our other scripts under the .github/ directory to see how we're doing this for various tools, and github itself has pretty decent documentation of actions.

Parts you'll need off the top of my head:

• grabbing the database from the cache
• something that runs on only new files in checkers/* when they're in PRs
• possibly something that runs weekly or only on main to see if any checkers need updates? likely a separate github actions job.

Are you asking how to run it in github actions? You can look at our other scripts under the .github/ directory to see how we're doing this for various tools, and github itself has pretty decent documentation of actions.

Parts you'll need off the top of my head:

• grabbing the database from the cache
• something that runs on only new files in checkers/* when they're in PRs
• possibly something that runs weekly or only on main to see if any checkers need updates? likely a separate github actions job.

I've already made a PR (#3840). Can you check it once?

@terriko Do we really need to run it weekly? I have added the github actions so that it checks any newly added/modified checker for related CVEs.

There is one thing we cud do to assure completeness. I'll file an issue if someone wants to volunteer to check whether the existing checkers have all related CVEs or not? How does it sound?

Ideally: the version that runs on a PR checks only the files changed in that PR.

The idea behind running it weekly (or monthly or whatever) would be to check existing checkers not in a PR so we'd get some warning if the CPE for a checker was removed from NVD. (which does happen periodically).

the frequency there doesn't matter so much, it's just the idea that "check your PR before merging" and "address technical debt" should probably be different but related github actions.

And yes, I'll get to the PR when I can!