GSoC 2023 Project Idea: Integration of new formats into triage workflow

[terriko]

• related: GSoC 2023: Start Here #2230
• expanding the idea from GSoC 2023 brainstorming thread #2354

cve-bin-tool: Integration of new formats into triage workflow

Project description

When cve-bin-tool's current triage system was created, there was very little adoption of standardized formats for reporting vulnerabilities. That's starting to change. We're expecting a lot of upheaval in this space over the next year as people start to comply with things like US Executive Order 14028, “Improving the Nation’s Cybersecurity” (which roughly says that you need to report components and provide evidence that you're not shipping vulnerable ones, but leaves exactly how you do that a little vague). But I think we're at the point where even if the standards change, the work we do to implement any one will likely carry over to make implementing others easier.

We think our triage workflow in the future will look something like this:

1. Scan product using cve-bin-tool and produce a SBOM of the products identified and a VEX.
2. Triage the VEX and update the status to remove false reports etc
3. Repeatedly scan the SBOM and the triaged VEX producing an updated VEX.

It's likely that this new workflow will replace our old one entirely, although we may support both for some time. Right now VEX is an evolving format and @anthonyharrison has integrated the CycloneDX version of the format and has a partially finished PR for CSAF (see #2427 for more discussion) here: #2401 . OpenVex may also be a possibility.

This project will involve:

• Improving cve-bin-tool output so we can produce an SBOM and matching CSAF-formatted vulnerability information file
  • We hope to have initial implementations of SBOM and CSAF generation integrated at the time when you start the project, but it's likely they'll need refinement.
  • We may also want to produce code to export OpenVEX and Vulnerability Disclosure Reports (VDR) as referenced in NIST SP800-21.
  • Given the rapidly changing nature of standards in this space, it's perfectly reasonably to pick 1 or 2 to standards focus on, then look at converting/porting code for others at the end of the summer.
• Building tools as needed to help users use, edit and manage triage files.
  • Some of these may need local UIs beyond our usual command line interface. We will not be building online services for this at this time, everything will need to run on a user's local machine.)
  • Potential use cases: Making notes about mitigated vulnerabilities, marking false positives (and optionally reporting them to us?), producing evidence that could be shared with users about risks, producing triage files to be shared across multiple projects using an overlapping subset of components, loading and combining triage files from multiple sources
• Building tools to help people track and understand triage over time.
  • We have some of these with our existing triage but it only works on our old json format
  • Potential use cases: explaining vulnerability patterns to management in a presentation, saving reports to be used as evidence in case of audit, examining patterns over time about how frequently components must be upgraded, quantifying risk in terms of how long it takes for things to be patched.

Related reading

• Discussion: Triage workflow improvements  #2427

Skills

• python
• ability to read json/xml data formats (if you don't know it yet you can learn it before we start),
• understanding of triage of security issues would be helpful
• understanding of SBOMs or license management would be helpful

Difficulty level

• medium/hard.
• The standards used here are evolving, it's possible that we'll have to rethink our approach over the course of the summer

Project Length

• 350 hours (e.g. full-time for 10 weeks or part-time for longer)
• It may be possible to do parts of this project within a 175 hour project, or split it into two 175 projects done by different GSoC contributors. If you're hoping to split this with another contributor, please be precise about which parts you intend to do and also which ones you'd be willing to do if we needed to split things up equitably.

GSoC Participants Only

This issue is a potential project idea for GSoC 2023, 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 #2230 .

[anthonyharrison]

Need to also consider looking at supporing Vulnerability Disclosure Reports (VDR) as referenced in NIST SP800-21

[anthonyharrison]

This is also of relevance

[terriko]

Closing this (and all the other leftover gsoc ideas from previous years) in order to help folk focus on the new project idea descriptions.