You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
@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?
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
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.
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 multipleFixedIn
entries.The text was updated successfully, but these errors were encountered: