Add capability to add/remove/change vulnerability data between upstream sources and grype-db

[joshbressers]

Today the data Grype uses for matching is sourced from upstream sources. If we want to modify any of this metadata, we have to submit those changes to the upstream data source. Submitting this data can be a slow process taking anywhere from hours to weeks. Additionally sometimes our desired changes will be rejected by the upstream data source.

The first example is an issue filed in GrypeDB about a Debian match that is being labeled as negligible even though only one of the affected packages is negligible
anchore/grype-db#108 (comment)
While this particular issue is a bug, if we could provide minor metadata modifications, we could quickly solve this.

Another example is when the Log4Shell incident was unfolding, CVE and NVD were very slow to add metadata in a timely manner. This additional metadata, which was all public, would have been valuable to Grype users. In this example we would want to add affected products quickly as they were reported. Once the upstream metadata was more complete, we would want to remove our metadata modifications.

We do try to bring metadata fixes upstream whenever possible, but there are instances where this isn't possible. Sometimes it could be a difference in opinions. An example of this is #773 where an issue was filed that is marked critical in NVD, but should have its severity lowered (NVD won't change the severity)

It probably makes sense to scope this as only affecting existing vulnerability IDs. Trying to add new IDs via this mechanism is not something we should be doing.

[joshbressers]

@willmurphyscode asked for a few more use cases, here goes

github/advisory-database#2900
is an issue where the GitHub data doesn't cover Maven repos outside of Maven Central. For example there are things in the Confluence Maven repo Grype will miss

Here's an instance where Apache Chainsaw is no longer distributed via Maven (but used to be as part of Log4j). It would be nice to add this back in
github/advisory-database#2630

This blog post shows a short term problem where getting a CVE updated was nearly impossible (it's very likely this would not have been updated without all the attention this received)
https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/

@westonsteimel If you know of other things please fill them in

[joshbressers]

It should also be noted we do not want this data to be large. We should only update our data in extreme cases. We should always be sending data updates upstream, this data set would be meant as a stopgap when the current security data creates a negative user experience