Validate CVSS vectors that grype reports on

[wagoodman]

(a topic from the OSS community meeting today from @pandatix)

Today grype outputs CVSS information in the JSON output, however, this is unprocessed vectors from upstream data providers. Ideally we should be validating these vectors and reporting issues (at least with log.warning()) when there are CVSS vectors reported which are not valid.

Things to consider:

• should this validation be upstream in grype-db or vunnel? (probably not since that would mean showing a warning no one would see or suppressing potentially useful information from the user)
• how should validation be expressed? (logger only? probably should not affect the return code, but up for a conversation on this)

dev note: a lib for consideration https://github.com/pandatix/go-cvss

[pandatix]

To help you implement this, and Go folks around here, I documented an efficient way to handle and verify CVSS vectors at https://github.com/pandatix/go-cvss#how-to-determine-cvss-version.

As the idea here is to check whether a CVSS vector is valid or not, you only need to handle the errors (validation is achieved on parsing).

[wagoodman]

Based on the conversation from the community meeting, I wanted to drop a few implementations paths here.

Assuming grype-db was the right spot for checking cvss information, I think there are two locations that could make sense:

• just before writing into the DB, in a single chokepoint per-schema version: https://github.com/anchore/grype/blob/3d582fd85145afe3fd3726437527a321efb664e9/grype/db/v5/store/store.go#L196-L208
• when creating cvss objects --which is done in multiple places per-schema version. E.g.
  • https://github.com/anchore/grype-db/blob/ef7ddfd459086a46eec2f69856c9bdd80eb3d2d8/pkg/process/v5/transformers/nvd/transform.go#L90
  • https://github.com/anchore/grype-db/blob/ef7ddfd459086a46eec2f69856c9bdd80eb3d2d8/pkg/process/v5/transformers/github/transform.go#L134

I think validating on write makes sense, given that they are records that will certainly be in the DB, something which is not necessarily true when simply creating cvss objects.

Either way, the logic for validating should probably live on the cvss object itself, even though it would be invoked when writing https://github.com/anchore/grype/blob/3d582fd85145afe3fd3726437527a321efb664e9/grype/db/v5/vulnerability_metadata.go#L18

On further thought, I don't think vunnel is the right place for this (but that's certainly debatable) since we don't necessarily use all data from the providers. It might be that there are invalid CVSS vectors that we aren't packing into the DB, in which case messaging out maintainers to take care of such invalid values would not be a good use of time.