Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSoC 2025 brainstorming issue #4732

Open
terriko opened this issue Jan 29, 2025 · 2 comments
Open

GSoC 2025 brainstorming issue #4732

terriko opened this issue Jan 29, 2025 · 2 comments

Comments

@terriko
Copy link
Contributor

terriko commented Jan 29, 2025

This issue is for brainstorming on potential GSoC 2025 projects. Not all of these projects will be viable but feel free to raise even impractical ideas.

  1. Continuing VEX / Triage work: VEX is a JSON format which can be a pain to edit especially since some fields have only a few allowed values. We may want to work on an editing tool to make it easier for people to update and triage vulnerabillities. (Will be a 4 month+ project.)
    • Could be a CLI tool with optional GUI?
    • Could be integrated with our existing html report format?
    • It's unlikely Terri will be able to run any backend due to
  2. Database work: 40k+ vulnerabilities per year, our database is getting large (~2.5G) and there may be places we can improve performance.
    • Should we be considering other db architectures? Currently using SQLite but could move to a "real" or "nosql" database
    • 4 month+
  3. Provide "no scan" SBOMs and remove reliance on NVD.
    • Currently you must download the NVD data to do anything in cve-bin-tool, it would be nice if we could actually disable it as a data source (for example, if you want to use OSV or if you want to use cve-bin-tool to do component analysis without any vulnerability scanning)
  4. Other sources of data? Debian, other distros?
  5. Architecture refactoring?
    • We had wanted to split cve-bin-tool into component analysis / sbom generation and separate vulnerability scanning tool (which can't currently be done because of how we set up cvedb.py)
    • Separate database update so it doesn't have to be done with a scan.
  6. Performance tuning (e.g. memory issues, places where we could replace python with compiled code to improve performance)
@Paras-245
Copy link

Heyo @terriko , wasnt able to join the meet (mistaken by timezone :) ) These projects are of high priority and practical + achievable also,
I was reading previous discussion and found two things we missed here.

  1. Test grouping - reducing the time for tests + Test Coverage (although this could be delayed ig)
  2. Training Materials : To create small courses or videos. (should be included in Summer of Docs or not)
    Although these are of low priority than other , but just thought to include here.

@Prtm2110
Copy link
Contributor

Prtm2110 commented Feb 2, 2025

If this discussion is not limited to maintainers:

Continuing VEX / Triage work: VEX is a JSON format which can be a pain to edit especially since some fields have only a few allowed values. We may want to work on an editing tool to make it easier for people to update and triage vulnerabillities. (Will be a 4 month+ project.)

  • Could be a CLI tool with optional GUI?

That sounds like a great idea! What tech stack are we considering for the optional GUI? Would it be a web application (Flask) or a Python-based desktop application (PyQt, Tkinter)?

  • Could be integrated with our existing html report format?

If this is feasible then I believe this can be the best as for users they wouldn’t need to navigate to a separate tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants