Draft: Make GraphQL VulnerabilityType reachability finding-context aware

What does this MR do

Part of #602157 (epic &21396 Complete at Scale Vulnerability Management).

The VulnerabilityType GraphQL reachability resolver batched occurrences by the deduplicated vulnerability, so vulnerabilities on non default branches reported the default branch's reachability. This MR makes the resolver resolve reachability per finding.

Reachability is a characteristic of a specific finding (vulnerability_occurrence). The BatchLoader now keys on the vulnerability object, collects each vulnerability's finding.id, and queries Sbom::Occurrence.filter_by_vulnerability_occurrence_id grouped by vulnerability_occurrence_id, so each vulnerability reports its own finding's reachability with no cross-finding leak. reachability: :findings is added to the resolver preloads to avoid an N+1 on the finding lookup.

History

This started as a per tracked-context grouping using the sbom_occurrence_refs scope (the now-removed for_tracked_context from !241041 (merged)). A model review established the finding is the right grain, so it was reworked to the finding-keyed approach. See !241041 (merged) and the removal in !241593 (merged).

Blocked on

sbom_occurrences_vulnerabilities.vulnerability_occurrence_id is currently NULL in production: the ingestion does not yet populate it and there is no backfill. This depends on:

Marked as Draft until those land.

Testing

Finding-keyed GraphQL type specs including the multi-finding correctness case (a batch with vulnerabilities from different findings resolves each against its own finding, no cross-finding leak) plus a dependency_scanning N+1 guard. Ran locally against PostgreSQL 17:

ee/spec/graphql/types/vulnerability_type_spec.rb -e reachability
8 examples, 0 failures

Reviewer notes

@zmartins the per finding grouping in the BatchLoader is the part most worth your review.

Edited by Gregory Havenga

Merge request reports

Loading
Loading