schemas version 2 wishlist

[westonsteimel]

The original vunnel schemas were very heavily influenced by the existing results format from Anchore Enterprise since we were trying to rip that out with as little disruption as possible. Now we would like to begin evaluating what a future iteration of these schemas could look like.

• The OS schema should not emit FixedIn entries but rather actual constraints. This way each provider can tailor the constraint creation logic to its needs, and grype-db does not have to figure out how to interpret multiple FixedIn entries.
• Needs to allow capture of upstream lifecycle dates (published, modified, withdrawn, etc) where available
• Needs to allow override of the severity at a per-package level (example 🪄 Schema version 6 wishlist grype-db#108 (comment))

[willmurphyscode]

@westonsteimel how would overriding the severity at a per-package level here help if grype db schema v5 can only have one severity per (VulnID, Namespace) tuple? Or is the ask here just to make the severity-per-package available to grype-db, and then grype-db can fix its own schema later?

[westonsteimel]

Or is the ask here just to make the severity-per-package available to grype-db, and then grype-db can fix its own schema later?

Yes

[westonsteimel]

I think adding a column to the vulnerability table in the current grype-db schema could be done without a breaking change, so we should get vunnel supporting it first and then update grype-db when we're ready to consume it

[TimBrown1611]

what do you thing adding EOL based on - https://endoflife.date/
currently i do not see any "offline" source which syncs this data (xeol doesn't seem maintained)

[willmurphyscode]

@wagoodman / @westonsteimel do we need to do anything here for the grype schema v6 work? Should we take advantage of the grype schema change to implement anything here?