GSoC 2025 Project Idea: VEX tooling

[terriko]

• Related GSoC 2025: Start here #4712

cve-bin-tool: VEX tooling and improvements

Project description

In GSoC 2024, we added support for triage using the VEX format, which is a set of standards for storing additional information about how vulnerabilities affect a given product. For example, a product may have backported patches or configuration changes in place that mean the security vulnerability does not apply even if the version of the component being used has a weakness that will show up on scans.

One of the challenges of VEX is that the rest of the toolchain around it isn't great. It's a JSON-based format which is convenient for machines, but it can be a pain for humans to edit for a variety of reasons, including that only certain values are allowed but typically humans need to use a text editor that gives them no hints about what can and cannot go in a given field.

We're looking to extend cve-bin-tool to provide some tools for VEX editing and validation, as well as likely extend our support of VEX. Right now, cve-bin-tool does not have a graphical user interface as most of our users need it to work on the command line, nor do we provide an online service. So we will need to work within those limitations at this time.

1. Add triage capabilities to our html reports, including the ability to save triage and updated reports. This needs to work offline in the user's browser, so will likely rely heavily on HTML5/Javascript rather than any sort of back end.
2. Add command line tools for validation and fixing of invalid VEX files, on the assumption that users will often have slightly incorrect files and need help. We may also want to have tooling to help guide users to remove or archive triage information that is no longer applicable (for example, when a component is updated and the original CVE no longer applies)
3. Add command line tools for generation of VEX files. We make blank ones already, but we could probably look at ways to help walk users through which issues are new and should be triaged.

@anthonyharrison will likely be the mentor on this project, so I'll leave him to fill in more details in the comments below.

Related reading

• https://cyclonedx.org/capabilities/vex/
• https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Document_508c.pdf

Skills

• python
• javascript
• software security: knowledge of how software vulnerabilities are triaged, mitigated and solved would be very helpful here.
  • You can learn more abou this as you go, but it's worth doing some background reading on how open source projects and corporations handle vulnerabilities if you can because it'll help inform what you propose.

Difficulty level

• medium/hard.

Project Length

• 350 hours (e.g. full-time for 10 weeks or part-time for longer)
• It would be possible to do part of this project in a 175 hour project, but we may prefer candidates who have the time to do more assuming similar levels of ability

Mentor

• The primary mentor for this project will likely be @anthonyharrison . Please ask all questions on this issue rather than sending email so you can benefit from the expertise of other contributors and mentors. (and so Anthony doesn't get swamped)

GSoC Participants Only

This issue is a potential project idea for GSoC 2025, and is reserved for completion by a selected GSoC contributor. Please do not work on it outside of that program. If you'd like to apply to do it through GSoC, please start by reading #4712.

[anthonyharrison]

Updating a VEX statement is much more than just changing the status value. The data associated with the vulnerability will be dependent on the updated status as well as the type of VEX being modified as there is no consistency between the formats. Use of the lib4vex library may be useful as this abstracts the specific JSON structures for each status value/VEX type.

Options to be considered could be a CLI utility and/or a simple user interface. It will probably be a standalone application from the rest of cve-bin-tool. Given the fluidity of the VEX formats, having a robust testing approach is an important aspect of this work

[AshishYesale7]

Hi @anthonyharrison and @terriko ,

I've drafted a proposal for the GSoC 2025 VEX tooling project, aligning it with the CVE Binary Tool Contributor Guide and relevant documentation (e.g., the Minimum Requirements for VEX and OpenVEX JSON schema). My approach includes developing a CLI utility with optional GUI elements to help users edit, validate, and generate VEX files, addressing the challenges in our current workflow.

Could you please review my proposal and provide feedback on the technical approach, milestones, and overall structure?

Project Title

Enhanced VEX Tooling for CVE Binary Tool

Abstract

Develop a standalone VEX editing and validation utility that integrates with the CVE Binary Tool ecosystem. This tool will streamline the process of updating VEX documents by leveraging the lib4vex library to abstract format differences and provide both CLI and (optionally) lightweight GUI interfaces for interactive triage and validation. The goal is to simplify vulnerability triage, reduce manual editing errors, and improve the consistency and reliability of VEX data used by security teams.

Motivation

VEX (Vulnerability Exploitability eXchange) documents are critical for conveying the impact of vulnerabilities on software components. However, due to the fluid nature of VEX formats and the limitations of text editors (which provide no schema guidance), users often face challenges when updating these documents. This project addresses the need for robust tooling to validate, edit, and generate VEX files, thereby supporting efficient vulnerability triage and reporting.

Objectives

• Validation & Editing:

  • Build a CLI utility to load, validate, and interactively update VEX files.
  • Use the lib4vex library to abstract the underlying JSON structures for various VEX formats (e.g., CycloneDX, OpenVEX).

• Guided Triage:

  • Implement automated suggestions for updating status (e.g., “not_affected”, “affected”, “fixed”, “under_investigation”) along with context‑dependent fields (such as justification, impact, or action statements).

• Optional GUI:

  • (Optional) Develop a simple, browser‑based user interface that runs offline to help users visually manage and triage VEX documents.

• Testing & Documentation:

  • Create a robust testing suite (using pytest) to ensure reliability as the VEX specifications evolve.
  • Update documentation (including the CVE Binary Tool Contributor Guide) with clear usage examples.

Technical Approach

1. Research and Requirement Analysis

   • Review the [Minimum Requirements for VEX](https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf) and related documentation.
   • Compare OpenVEX (e.g., the [OpenVEX JSON Schema](https://github.com/openvex/spec/blob/main/openvex_json_schema.json)) with CycloneDX VEX models.

2. Architecture and Design

   • Design the tool as a standalone application that can be invoked from the command line.
   • Plan modular components for:
     • VEX file I/O and schema validation.
     • VEX data manipulation (updating status and associated fields).
     • (Optional) A lightweight web‑interface for interactive triage.

3. Implementation

   • CLI Utility:
     Develop commands to:

     • Load and validate a VEX file against its JSON schema.
     • Interactively update a VEX statement and automatically adjust related fields.
     • Generate new, template VEX documents.

   • GUI Prototype (Optional):
     Create a minimal HTML5/JavaScript interface (e.g., using Flask) that lets users load, edit, and validate VEX documents locally.

   • Integration with lib4vex:
     Use the lib4vex library to abstract the JSON differences between VEX formats, ensuring your tool works consistently regardless of the source format.

4. Testing and Documentation

   • Write unit and integration tests to cover key functionalities (validation, update logic, file I/O).
   • Prepare detailed documentation and usage guides, referencing key sources such as the JSON Schema Getting Started Guide.

Timeline

• Phase 1 (Weeks 1–2):

  • Research, requirements gathering, and design.

• Phase 2 (Weeks 3–7):

  • Develop core CLI functionality and integrate with lib4vex.
  • Implement basic VEX validation and editing features.

• Phase 3 (Weeks 8–10):

  • (Optional) Develop and integrate a lightweight GUI.
  • Expand automated testing and refine validation logic.

• Phase 4 (Weeks 11–12):

  • Finalize documentation, perform user testing, and prepare the final deliverables.

Expected Outcome

• A standalone, robust VEX tooling application that simplifies vulnerability triaging and VEX file updates.
• Seamless integration with CVE Binary Tool workflows and support for multiple VEX formats.
• Enhanced reliability and automation for maintaining accurate VEX documents, with comprehensive testing ensuring future compatibility.

References

• [Minimum Requirements for Vulnerability Exploitability eXchange (VEX)]
• [OpenVEX JSON Schema]
• [JSON Schema Getting Started Guide]

Mentor Guidance

As mentioned by @anthonyharrison, updating a VEX statement involves more than changing a status value. The tool must adjust associated data (like justification or impact statements) based on the updated status and handle multiple VEX formats seamlessly. A robust testing strategy is essential due to the evolving nature of VEX specifications.

---

Development Environment Note :

Although I am developing primarily on macOS, I have set up ParrotOS under a UTM virtual machine to emulate a Linux environment for testing and compatibility purposes. I am actively consulting the necessary documentation (including the OpenVEX and CycloneDX guides) to ensure that the tool meets cross‑platform requirements and works reliably in diverse deployment scenarios.

Timeline
Phase 1 (Weeks 1–2):
Research, requirements

[anthonyharrison]

Ho @AshishYesale7 cc @terriko

Thanks for your ideas. We don't want your ideas/proposal published on GitHub. The application process is not yet open but I suggest you find the project channel on giiter and join the conversation. We will be creating a specific channel for GSOC2025 applications shortly.

[Shrishti1701]

I am currently working on my GSoC 2025 proposal for the VEX Support project under the CVE Binary Tool and wanted to confirm the correct submission process.
Could you please guide me on where I should submit my proposal for review? Should I post it as a draft on a GitHub issue, share it via email, or follow a specific submission process within the community?
Looking forward to your guidance.