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?

[kaushik853]

We can also have something like for "no scan" SBOM

• Add a new command-line flag like --sbom-only
• Modify the scanning logic to bypass vulnerability lookup when this flag is set
• Ensure SBOM generation still works with complete component information

[terriko]

GSoC 2025 applications are now closed, so I'm going to close this issue as well.

[manish721]

The CVE Binary Tool is vital for identifying known vulnerabilities in software components. This proposal tackles multiple interconnected needs:

Simplifying the editing and triage process for VEX data through a dedicated tool (CLI + optional GUI)

Refactoring the architecture to separate component analysis, SBOM generation, and vulnerability scanning

Reducing dependence on NVD by introducing alternative data sources (e.g. OSV, Debian) and offering "no-scan" SBOM support

Exploring performance improvements through database optimization and compiled code

Benefits to the Community
Developer Productivity: An easier-to-use VEX editor empowers maintainers to handle vulnerability triage efficiently

Tool Modularity: Refactored architecture enables users to plug in only what they need—analysis, scanning, or reporting

Data Flexibility: Alternatives to NVD expand usability in disconnected or custom environments

Speed & Scale: Performance optimization prepares the tool for growing datasets and large-scale adoption

Deliverables
📦 VEX Editing Tool

A CLI/optional GUI to create/update valid VEX JSON (with dropdown-like controls for constrained fields)

Could use TUI libraries (like Textual) or a minimal Electron-based GUI

🧱 Architecture Refactor

Split the CVE Binary Tool into distinct layers:

SBOM / component detection

Vulnerability scanner

Database update / querying module

🧩 No-Scan Mode

Allow SBOM analysis or metadata generation without requiring NVD download

Integrate support for other data sources (OSV, Debian Security Tracker)

🗃 Database Performance Improvements

Benchmark SQLite limits

Explore migration paths (PostgreSQL / NoSQL) and memory tuning

Consider compiled Python modules for critical performance paths (e.g. cython, rustpy, nuitka)

📚 Updated documentation, tutorials, and examples