Gate tracked ref filter on advanced vulnerability management

Bala Kumarrequested to merge
fix/tracked-ref-token-advanced-vuln-management-ability into master

What does this MR do and why?

Adds a check for the access_advanced_vulnerability_management ability to the frontend gate that decides whether the "Tracked ref" filter token appears in the vulnerability report's filtered search. Without that check the token renders — and pre-applies a default value — on every project, including instances where the backend cannot accept the argument it sends. The whole vulnerability report then fails to load.

The causal chain:

  • vulnerabilities_across_contexts shipped as beta with default_enabled: true in !250276 (merged), so the Tracked ref token now renders for every project by default.
  • TrackedRefToken pre-selects the project's default branch through its defaultValues() hook, and filtered_search.vue turns that into an initial filter value. So trackedRefIds is sent on page load, before the user touches the filter.
  • trackedRefIds maps to security_project_tracked_context_id, one of the ADVANCED_FILTERS in ee/app/graphql/resolvers/vulnerability_filterable.rb.
  • That filter requires the access_advanced_vulnerability_management ability, which requires advanced search to be configured — Search::Elastic::VulnerabilityIndexHelper.advanced_vulnerability_management_allowed? needs both the elasticsearch_indexing and elasticsearch_search application settings.
  • On an instance without advanced search, validate_advanced_vuln_management! raises Require advanced vulnerability management to be enabled!, so both project.vulnerabilities and project.vulnerabilitySeveritiesCount fail. The user gets an "Error fetching the vulnerability counts" banner, all six severity tiles reading "Something went wrong", an applied "Tracked ref" chip they never chose, and "No vulnerabilities to report".

The fix reuses the existing advancedVulnerabilityManagement computed property in the same component. The REACHABILITY and VALIDITY_CHECK cases in the same switch already gate on it, and the only two filter presets that include TRACKED_REF (DEVELOPMENT_PROJECT and OPERATIONAL_PROJECT) also include those two, so the ability is already required and pushed to the frontend on the affected pages.

This was found through E2E, but it is a user-facing bug: any self-managed instance without advanced search configured hits the same broken report, because the flag defaults on.

Local testing observations

Tested against a local GDK, EE Ultimate license, with the vulnerabilities_across_contexts flag enabled (it is beta / default_enabled: true), on a project with 1,100 vulnerabilities, default branch main, and a default-branch Security::ProjectTrackedContext record. All requests were run as an owner/admin user via GitlabSchema.execute, using the same GraphQL query the report page issues on load:

query($fullPath: ID!, $trackedRefIds: [SecurityProjectTrackedContextID!]) {
  project(fullPath: $fullPath) {
    vulnerabilities(trackedRefIds: $trackedRefIds, first: 3) { nodes { id } }
    vulnerabilitySeveritiesCount(trackedRefIds: $trackedRefIds) { critical high medium low }
  }
}
Case Advanced search trackedRefIds sent Result
A OFF Yes Error: Require advanced vulnerability management to be enabled! (both fields)
B OFF No Loads: 3 vulnerabilities, counts critical: 55, low: 1045
C ON Yes Loads: 3 vulnerabilities, counts critical: 55, low: 1045

Before / after: on master, case A is what actually happens on page load for any instance without advanced search configured — the report is broken. With this MR the token is not rendered, trackedRefIds is never sent, and the report loads (case B).

  • A vs B isolates the cause: the only difference between the two requests is whether trackedRefIds is present, and that alone flips the result from erroring to succeeding.
  • C shows the MR does not regress instances that do have advanced search configured — the tracked-ref filter still works there, and access_advanced_vulnerability_management is exactly what distinguishes the working case (C) from the broken one (A).

Added a Jest test asserting the token is absent when accessAdvancedVulnerabilityManagement is false; confirmed it fails on master (token present) and passes with the fix. The full spec file passes (25 tests), and the wider filtered_search plus vulnerability_report suites pass (39 suites, 1,573 tests).

The advanced-search settings were restored to their original values (both enabled) after testing.

Screenshots or screen recordings

Captured locally in Chrome (via Capybara) on a project with one SAST vulnerability and a default-branch Security::ProjectTrackedContext. Advanced search is unconfigured, which is the RSpec default — so this is the exact scenario the bug affects, with no settings tampering needed.

Before (master) After (this MR)
before after

Before: the counts error banner, all six severity tiles reading "Something went wrong", Development vulnerabilities 0, and no rows. After: real counts (High 1), no banner, and the vulnerability listed.

Assertions extracted from the saved DOM of each run, rather than read off the images:

Check Before (master) After (this MR)
Tracked ref filter applied present absent
"Error fetching the vulnerability counts" banner present absent
Severity tiles reading "Something went wrong" present absent
"No vulnerabilities to report" present absent
Vulnerability row rendered absent present
"Limited experience available" callout present present

The limited-experience callout is expected in both: it is the legitimate notice that advanced search is not configured, and this MR does not suppress it. Only the pre-applied filter and the resulting query failure go away.

How to set up and validate locally

  1. Prerequisites: a GDK with an EE Ultimate license, a project with some vulnerabilities, and a default-branch Security::ProjectTrackedContext record for that project. The report page only pre-applies the Tracked ref filter when one exists — EE::ProjectsHelper provides default_branch_context from Security::ProjectTrackedContext.find_default_branch_context.

  2. Simulate an instance without advanced search. In the Rails console, disable both application settings and expire the settings cache:

    s = ApplicationSetting.current
s.elasticsearch_indexing = false
s.elasticsearch_search = false
s.save!(validate: false)
Gitlab::CurrentSettings.expire_current_application_settings

    Note: elasticsearch_indexing and elasticsearch_search live in the elasticsearch JSONB column on application_settings, so update_columns fails with PG::UndefinedColumn — use the attribute writers as shown. If your GDK normally has advanced search enabled, restore both settings to true the same way when you are done.

  3. Confirm the precondition took effect: Search::Elastic::VulnerabilityIndexHelper.advanced_vulnerability_management_allowed? should return false.

  4. On master, open the project's Secure → Vulnerability report. Expect the broken state: an "Error fetching the vulnerability counts" banner, severity tiles reading "Something went wrong", an applied Tracked ref chip the user never selected, and "No vulnerabilities to report".

  5. Optionally reproduce at the API layer instead of the UI, by running the same GraphQL query with and without trackedRefIds:

    query($fullPath: ID!, $trackedRefIds: [SecurityProjectTrackedContextID!]) {
  project(fullPath: $fullPath) {
    vulnerabilities(trackedRefIds: $trackedRefIds, first: 3) { nodes { id } }
    vulnerabilitySeveritiesCount(trackedRefIds: $trackedRefIds) { critical high medium low }
  }
}

    With trackedRefIds set it errors; without it, it succeeds.

  6. Check out this branch, reload frontend assets, and reload the report. Expect the Tracked ref token to be gone and the report to load normally, with counts and rows.

  7. Run the Jest spec:

    yarn jest ee/spec/frontend/security_dashboard/components/shared/filtered_search/vulnerability_report_filtered_search_spec.js

References

Five sibling security-risk-management vulnerability report E2E specs are still fast-quarantined for this same root cause. Fast quarantines are cleared automatically every Sunday, so they should be re-checked once this merges.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Bala Kumar

Merge request reports