GSoC 2021 idea: Building checkers/mappings for known package lists

[terriko]

Binary scanning is slow, and sometimes people have existing package lists they'd like to use. We accept a list of vendor/package pairs for scanning, but those don't always map to the list people are getting out of say, requirements.txt for python or dpkg for ubuntu or dnf for fedora.

Mappings by themselves aren't a GSoC project, because Google asserts that you have to write code to qualify, so we have to be really careful to make sure that a student proposing for this project has enough actual code planned in their proposal to qualify under google's rules, so here's some possible options that might make a viable GSoC project out of the idea.

1. Build a mapping database for the top 50 packages on pyPI and a parser that reads requirements.txt and uses the mappings to warn you if any of those have CVEs against them (and warns the user if a package doesn't have a mapping and prompts them to maybe provide it)
2. Do the same only with the core packages of a linux distro (e.g. ubuntu, fedora, centos) and whatever it uses as output for package/version listing.
3. Once you've got some core lists from pypi or distros, attempt to make binary scanning signatures for as many of those at the same time so that we can be sure that you're writing enough code to qualify for GSoC.
4. Build a tool that helps prompt users with potential vendor-package pairs if the package isn't found in the mapping.

Edit to add:

5. Find a way to programatically find out what CVE fixes have been backported so that these can be reported as such in CVE-bin-tool's output.

[terriko]

Pinging @PrajwalM2212 -- This has some elements of stuff we discussed last year, and it might be a good base for a proposal this year if you're interested. We really have to focus on the code aspect (and not the mapping aspect) to make this work for GSoC.

[PrajwalM2212]

This look great ! I will look into it.

[terriko]

Finished as part of GSoC 2021