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:

  grype/grype/db/v5/store/store.go

  Lines 196 to 208 in 3d582fd

  	// go through all incoming CVSS and see if they are already stored.
  	// If they exist already in the database then skip adding them,
  	// preventing a duplicate
  	for _, incomingCvss := range m.Cvss {
  	for _, existingCvss := range existing.Cvss {
  	if len(deep.Equal(incomingCvss, existingCvss)) == 0 {
  	// duplicate found, so incoming CVSS shouldn't get added
  	continue incoming
  	}
  	}
  	// a duplicate CVSS entry wasn't found, so append the incoming CVSS
  	existing.Cvss = append(existing.Cvss, incomingCvss)
  	}

• 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

grype/grype/db/v5/vulnerability_metadata.go

Line 18 in 3d582fd

type Cvss struct {

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.