GSoC 2022 Ideas / Brainstorming thread - Githubissues

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.23k stars 464 forks source link

GSoC 2022 Ideas / Brainstorming thread #1379

Closed terriko closed 2 years ago

terriko commented 3 years ago

GSoC 2022 has now been announced!

This thread is open for brainstorming ideas for GSoC 2022 projects. They can be either 175hr or 350hr ideas. GSoC is open to anyone over 18 now, not only students,, and the timing is more flexible than it used to be.

Note that this is a brainstorming thread so it's going to include even things that are infeasible, low priority, or have potentially blocking issues. The point is to have a pool of ideas we can combine to maybe make some reasonable projects; they can be narrowed down further in January or so. When ideas have gotten past the brainstorming stage to "maybe this is a doable project?" stage we'll try to break them out into separate issues.

UI for CVE-Bin-Tool -- currently we're all command line
Windows package manager data (the way we handle linux/python package lists)
Other package managers: npm, rust, java -- some of these exist, maybe calling existing software to get results?
Training package: training people to use/develop CVE Binary Tool (note: needs to have enough code to qualify for google summer of code, but we could look in to participating in season of docs or outreachy instead)
Internationalization: but only if we can find some users interested in using/testing the translations
Improve code coverage. See #1525

terriko commented 3 years ago

cve-bin-tool as a service (what would that even mean?)
other formats and integrations (e.g. with Tern, with AboutCode, others?)

terriko commented 3 years ago

improve type checking (and integrate automatic tools in CI for this)

anthonyharrison commented 3 years ago

Use additional or alternative vulnerability databases e.g https://osv.dev/

ashok-arora commented 2 years ago

cve-bin-tool as a service (what would that even mean?)

@terriko How about a website (written in Flask and HTML/CSS) where the user can upload the binary and then the report is displayed (with options to download in a specific format)?

terriko commented 2 years ago

@ashok-arora I don't think that'll work for GSoC. A service like that requires pretty extensive security validation, testing, and an ongoing maintenance commitment if I wanted to release it following Intel's security guidelines. We're looking for more self-contained features that can be handled in a 10-week commitment!

terriko commented 2 years ago

From @anthonyharrison

doing something appropriate if we find something and don't have a checker.
improved information on how to fix -- already have the available fix tool, but might be able to get information from the cve links as well.

terriko commented 2 years ago

Came up in a private conversation: Date-based vulnerability information. Right now, we basically don't do anything but print information if a checker gives a version as UNKNOWN. But in theory, we could combine the timestamp on the file, the vendor/product that we partially found, and then list out vulnerabilities that have been found since that time in that product.

Note that while CVEs have date information attached, I don't think we currently store that, so it would require a database change. I'm not sure how useful it would be in practice, but for folk scanning older software where our signatures aren't as good, this could potentially generate some interesting results if we had it as an option recommended when an UNKNOWN is found?

terriko commented 2 years ago

more brainstorming:

improving windows support (e.g. handling DLLs)
adding macos support (now supported by Github Actions so we could have CI for this)
report improvements? full reports (including all descriptions),
HTML report improvements: updating js libraries, improving tests
mapping which applications include code that needs to be rebuilt.
triage enhancements?

ashok-arora commented 2 years ago

adding macos support (now supported by Github Actions so we could have CI for this)

I would love to work on adding macOS support. Could you expand a bit more on the work required for it?

terriko commented 2 years ago

I can't really because I haven't investigated it (taht's why this is in a brainstorming file and not a complete idea) but here's some guesses:

Checking to make sure that utilities like 'file' behave the same as they do on linux. MacOS is BSD-based so the utilities are pretty similar but often have slightly different flags/output
Finding appropriate replacements for anything not typically installed by default (e.g. is there a cabextract equivalent? what's the preferred zip extraction libraries?)
Testing testing testing. Adding additional tests for any codepath that's different on macos (e.g. because a flag is different)
Setting up tests in CI (GitHub Actions) for supported versions of Python
updating docs with setup instructions and information for macos users
potentially adding code for dealing with typical macos packages (they're... sort of directories but sort of not if I remember correctly)

Basically, pip install cve-bin-tool and see what breaks, then put together a proposal to fix anything you find, I guess? I don't have a modern macos machine handy at the moment but last time I tried it basically just worked, so there may not be enough to make a 175hr project here. I don't actually know.

terriko commented 2 years ago

I'm going to go ahead and close this now that GSoC is underway. Some of the ideas may still be useful in future, but there's further action to take on this particular issue.