GSoC 2025 brainstorming issue

[terriko]

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]

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]

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.

[Shrishti1701]

@terriko These are some great potential ideas for GSoC 2025! A few thoughts:

VEX Editing Tool: A CLI with an optional GUI sounds like a solid approach. Integrating it with the HTML report format could improve usability, but we might need to assess how feasible that is.
Database Scaling: Moving away from SQLite could help performance, but it would be good to benchmark the current bottlenecks first. Would a hybrid approach (e.g., caching frequently accessed data) work instead of a full migration?
Decoupling from NVD: Allowing alternative data sources like OSV or distro security feeds would make cve-bin-tool more flexible. Are there specific sources we should prioritize?
Architecture Refactoring & Performance: Splitting component analysis and vulnerability scanning makes sense, but restructuring cvedb.py will require careful planning. Also, exploring compiled code (e.g., Rust/Cython) could be a big win for performance.
I'd love to help refine these ideas further. Are there any next steps for discussing feasibility or scope?