Draft: Make Vulnerability#reachability finding-context aware

What does this MR do

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

Vulnerability#reachability queried all sbom_occurrences linked to the deduplicated vulnerability, so a vulnerability on a non default tracked branch reported the default branch's reachability. This MR scopes the lookup to the vulnerability's own finding.

Reachability is a characteristic of a specific finding (vulnerability_occurrence), not the deduplicated Vulnerability, and the finding already carries the tracked context. So reachability now resolves through Sbom::Occurrence.filter_by_vulnerability_occurrence_id(finding.id), which joins sbom_occurrences_vulnerabilities on vulnerability_occurrence_id. No sbom_occurrence_refs, no separate tracked-context filter.

History

This started as a sbom_occurrence_refs context filter (using the now-removed for_tracked_context scope from !241041 (merged)). A model review established that the finding is the right grain, so it was reworked to the finding-keyed approach. See the discussion on !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 MR cannot do anything useful until:

Marked as Draft until those land. ~"blocked"

Testing

Finding-keyed #reachability specs (occurrence linked to the finding reports its reachability, an occurrence linked to a different finding does not leak, no-finding returns unknown). Ran locally against PostgreSQL 17:

ee/spec/models/ee/vulnerability_spec.rb -e reachability
7 examples, 0 failures

Reviewer notes

@zmartins as the reachability DRI. The GraphQL consumer is the companion !241043.

Edited by Gregory Havenga

Merge request reports

Loading
Loading