Wish List for a replacement tool or at least v2.0

[willmurphyscode]

This tool has some difficulties, but has become quite load bearing in terms of how we ensure matching is correct end to end.

This is a list of mistakes we wish to reverse or make a different mistake for.

1. Instead of git submodules, we would like to make a different choice
2. Instead of rolling our own JSON format, we would like to use something specified (OpenVEX)?
3. Instead of a TUI where J opens the JSON view, we want to make a TUI where "J" has no effect or means "down" (or provide vim mode).

[wagoodman]

• Drive labels off of a sqlite DB instead of json flat files. This also solves distribution much more elegantly (we don't need git submodules, can optionally pin or float to latest, etc).
• labels at this point should not be home-grown, head nod to something like openvex like suggested above
• should be able to describe f1 score like we do today (so we need to label everything) but should also allow for partial analysis modes (looking at just sensitivity or recall for instance) so we can answer quality questions without having to minimize the unknowns in an quality gate scan
  • For instance, a nice mode testing would be to scan these images https://github.com/vulhub/vulhub to ensure we at leaset find CVE's x,y, and z in an image. But we don't need to do exhaustive labeling (we don't care about the rest of the universe of vulnerabilities for these test images).
  • odds are we want to have different kinds of quality gates here: some in the vunnel development path for ensuring that the happy path for matching works, some as a release gate for grype that aren't necessary to run when we are doing development but want to check before releasing, etc. Some of these paths might not require a full f1 score to be helpful.
  • should allow for partial matching of label and result data Add a vulnerability-id only mode #472 this is a good example where a new mode of analysis would allow us to purely look at "does this image catch these CVEs regardless of which package it's associated with".
• should allow for CPE and PURL only input, today we are dependent on images which causes a lot of secondary issues
• Label data should probably live next to the SBOMs that the labels describe, this way we can make quality gates that aren't necessarily reproducible but are cheap to create (great for bootstrapping a new distro).

[willmurphyscode]

It should be easier to tell what was used in the matching, like package type and distro name and version.