Wow, it has been a while since I posted an update about our progress on getting CVE reporting. Sorry about that!
@Lucus at Serokell has mostly finished making a program that downloads the National Vulnerability Database in a incremental way and loads it into a sqlite database for querying. He also worked on making it efficient to query if a version has CVEs associated with it, which is not trivial because CVEs can support multiple matching styles like exact matches and range matches.
Today, I made the basic CVE report that tries to match the Repology project name with the CVE project id, and I’m now running nixpkgs-update with this. Hopefully we’ll see some actual reports soon.
Here’s an example of how a report would have looked for a recently updated package that someone noticed had a CVE:
./result/bin/nixpkgs-update check-vulnerable bird 2.0.5 2.0.6
Experimental: CVE security report (click to expand)
CVEs resolved by this update:
CVEs introduced by this update:
CVEs present in both versions:
I’ve noticed that many of the CVE reports are obviously wrong, like the CVE report for
tor is reporting CVEs for
tor-browser. I’m noting wrong ones I find so we can go back and address them.
Which leads into the main issue left to address, which is the mapping of nixpkgs derivation/package to a Common Platform Enumeration (CPE). This is tricky to do automatically since different projects make use of different fields within the CPE. We will need to maintain a curated mapping from attrpaths to fix these issues. It would probably make sense to eventually incorporate this into the
meta derivation information once we find a stable format.
There are also issues to resolve around the ordering of versions. There are a lot of different ways that projects represent release candidates and some projects change versioning schemes as they go, both of which make it hard to see where a version falls within a CVE version range match.
Please let me know if you have any feedback on our work!