Skip to content

CVE Binary Tool Ideas Page for GSoC 2021

Jump to bottom
Terri Oda edited this page Feb 8, 2021 · 7 revisions

CVE Binary Tool in GSoC 2021

The CVE Binary tool team is hoping to participate in Google Summer of Code under the Python Software Foundation umbrella. You can read all about what this means at http://python-gsoc.org/

About the CVE Binary Tool

The CVE Binary Tool is a small Python script that scans for a number of common, vulnerable open source components (openssl, libpng, libxml2, expat and a few others) and will let you know if your binary code includes versions of these common libraries with known vulnerabilities.

This security tool is designed to be a minimal security check that can be made part of your continuous integration as a backup check to make sure older vulnerable code is not part of your release binaries.

Project Ideas

Remember: projects for 2021 are half sized compared to 2020 and earlier (175hr projects instead of 350hr ones), so the project should be scaled down compared to previous years.

  1. Improved Triage and Tracking -- The CVE Binary Tool has the ability to triage scans to mark issues as false positive, fixed, or otherwise keep notes as part of the scan. This issue covers some possible improvements, including the ability to merge scans and triages and helping projects track time to fix vulnerabilities. The ideal applicant for this intermediate to hard project would have an understanding of what it means to triage issues and what tracking is meaningful for teams fixing or monitoring known vulnerabilities.
  2. Building checkers/mappings for known package lists -- Many users want to scan full linux distributions, particularly in containers, to use cve-bin-tool as another diagnostic tool for the security of full systems. This project idea focuses on ideas around how to make sure we cover packages of interest and allow people to scan based on package data instead of having to do binary scans. The ideal applicant for this easy task should demonstrate that they understand what an "interesting" package means to Linux users and container users.
  3. Checker creation helper scripts -- Currently, creating a new checker requires a bunch of file manipulation, and many of the tools we use are easier for folk on Linux than on Windows. This project idea focuses on some ideas on how to make it easier for folk to make checkers. The ideal applicant for this easy task would want to demonstrate that they really understand how to build checkers themselves.

We also have a "catch all" issue for people to discuss new ideas. Prospective applicants are welcome to come up with their own ideas, but be aware that only those interesting to the users and developers of the CVE Binary Tool are likely to be selected, so you really want to discuss the ideas in public if you want to have a chance of your proposal being selected.

Getting Started:

  1. Follow the README and make sure you can run the tool. Try running it against random things on your hard drive and see if it finds anything. On a Linux system, your /bin directory usually yields some interesting results.

  2. Run the tests. The CVE Binary tool has a number of unit tests. Make sure you know how to run them, and if you've never used pytest before, you might want to read up on it (we also have some tests still using python's unittest, but we're tending towrads pytest for new tests). Figure out how to run a single test!

  3. Read the documentation. That should help you figure out what the tool is for and how people use it in more detail.

  4. Read the new contributor guide

Some potential first contributions:

  1. File issues. You might encounter a bug or something confusing in the documentation. Let us know if you do!
  2. Update documentation. We especially appreciate documentation feedback from new users, since your "beginner mind" means you see things differently than experienced users, and will catch places where the documentation could be more detailed or improved.
  3. Write a new test. Instructions for writing tests are here. This can be your first contribution!
  4. Try fixing a bug. We have a few flagged as "good first issue". A number of those are new checkers, which although they might sound challenging are often pretty easy to write. Instructions on how to add a new checker are here.

We expect prospective GSoC students to have made at least one code contribution if they want their application to be considered, so now's a good time to get that going! You can ask for as much help as you need.

Got stuck?

  1. Ask here in this issue! (Or file a new one with your question.)
  2. We have a chat server on gitter. That allows for "live" chat but no one's actually sitting there 24/7 so you should expect to post your question and get an answer hours later when someone sees it.
Clone this wiki locally