## Overview Right now, when we query for vulnerabilities in a group, the query assumes that all vulnerabilities found in projects within the group are for the respective default branches. This is implicit - we only track one branch per project, so all rows are relevant. When we begin tracking more than one branch on a project, this group level assumption does not hold. We need to maintain the current behaviour where the group level report shows all information for the default branches in all projects in the group. Options: 1. We join with `security_project_tracked_contexts` and only return rows where the tracked context refers to the default branch. 2. We add a column to `vulnerability_reads` `refers_to_default_branch` which is `true` when this read record refers to the default branch and `false` otherwise. We then filter for this at the group level query `where refers_to_default_branch == true`. 3. We add a field to the elasticsearch model `refers_to_default_branch` which is set during replication to elasticsearch and then added into the query we send to elasticsearch. If we commit to option 3 then we use ES for **every** render of the vulnerability report rather than just when we're using advanced filters. Tracking multiple branches depends on ES being present anyway. ### Implementation Plan 1. Convert all loads of the vulnerability report to use Elasticsearch (currently only a certain set of fields will trigger the use of ES). 2. Update the new ES indexing model to persist the "on default branch" flag. **This should be done before the backfill of the new index occurs to save two backfills**. 3. Update the vulnerability finder to conditionally use the "on default branch" flag: 1. If no tracked context is provided, then add `on default branch == true` to the query. 2. If a tracked context is provided, then filter by that and do not filter by `on default branch`.