feat: add go symbol matching qualifier for better go vuln matching

[spiffcs]

Go symbol matching: stdlib and golang.org/x advisories match correctly based on new symbol data; merge govulndb symbol data onto GHSA records

The [Go Vuln DB] (https://vuln.go.dev/) is the only source for Go standard library advisories. It is also an authoritative source for a share of golang.org/x/* advisories.

Grype recently started hosting GoVulnDB records in its DB (#3527, #3534, #3527).

Keeping these records exposed without symbol matching lead to matching inaccuracies. We also would see inaccuracies from cases in GHSA where we did not have symbol data and only matched at the module/version range level.

PR Features

• stdlib and golang.org/x/* records now match on symbols
• grype catalogs Go binary function symbols by default (syft symbol capture enabled in getProviderConfig),
• govulndb's per-symbol reachability is stored as a go_imports qualifier, and only matches when a vulnerable symbol is actually present in the binary
• Stdlib packages always stay on the GO records (nothing else covers them);
• x/* advisories without a GHSA counterpart are also kept.
• Packages without symbol evidence (pre-built SBOMs) keep today's module-granularity behavior

Data Decisions

Where a GHSA covers the same module, the GHSA becomes the single, symbol-enriched record.

• Each GHSA affected package matching a GO record's module is patched with the go-imports qualifier.
• Patching is decided per exact match on affected[].package.name
• The GO record is written only if packages remain that were NOT found in the GHSA.
• Ranges: the GHSA's win by default
• Ranges exception: a GHSA range pinned to the pseudo-version of the fix commit can never match a real tagged release (v5.21.1 sorts above v0.0.0-… — a guaranteed FN). When the GO record carries that exact pseudo-version in its standard range plus exactly one custom range in ecosystem_specific.custom_ranges we patch in the custom_range
• Every GHSA amendment is recorded on the blob's modifications audit trail ({url, changes[]) changes can be symbol additions and range replacements.

Schema:

• DB model 6.1.9 adds GoImports to package qualifiers
• db search 1.1.7 adds go_imports
• db search vuln 1.0.6 adds modifications

Known limitations / follow-ups (tracked separately)

• Non-semver version strings (~20 govulndb custom_ranges strings plus 14 + 45 on the GHSA side

[spiffcs]

In the grype report what of the symbol data should we end up including? Just what the intersection was that caused the match or the full table for the package?

[wagoodman]

I doubt this is likely, but I'll mention it anyway: if there are two go records aliasing the same GHSA that list the same import path with different symbol sets then the second set is silently dropped instead of being combined.

[wagoodman]

why hold all of the go and ghsa records? We have a mechanism for ordering providers one before another (today we have NVD before others). I feel that we could write ghsa's as usual then patch overlapping ghsa records when we write the go vuln records --which doesn't requiring holding any/all records in memory and write them at close.

I did not look at the *provider caches that we have and how they are affected.

Was there specific frictions/reasons why to hold writes for all records?

[spiffcs]

We talked about this on a sync, but to record the decision here:

• We're not holding all the ghsa records, just the ones from the Go ecosystem
• Write once was deemed a better path than write then patch because of the additional complexity of adding new patch code.

If we run into issues with write once we can come back on a follow up to add the PATCH methods to the db builder/reconciler

[willmurphyscode]

Is it worth also capturing an architecture qualifier, e.g. https://vuln.go.dev/ID/GO-2022-0187.json is only affected on amd64. That's probably out of scope here but i wanted to check what others think. My vote would be to add it as a fast follow but still wanted to mention it.