Vulnerability Explanation and Vulnerability Resolution troubleshooting

Troubleshooting Resource Guide for VE and VR

When working with Vulnerability Resolution and Vulnerability Explanation, you might run into an error. Most commons problems are documented in this section. If you find an undocumented issue, you should document it in this section after you find a solution.

If you need help developing or testing locally, please see the setup guide.

For availability of these features please first check the prerequisites listed here: vulnerability explanation and vulnerability resolution.

Also check: VR troubleshooting guide.

Problem	Solution
Duo / VR features aren’t available	The group/project may not have assigned Duo Seats. Follow the Duo subscription add-ons instructions.
Upstream errors such as “The upstream AI provider request timed out without responding”	This may indicate an issue with our third-party AI. This could be Anthropic outage - check status.
Specific recurring errors like “an unexpected error has occurred”	This may indicate an issue with the creation of the diff patch or MR. Refer to Error handling code
False positive errors	We handle empty responses and empty <fixed_code> as false positives. Documentation, Response modifier code
If you see that the VR button is disabled, that means that the CWE is not part of the supported list at this time.	Feature coverage restriction: VR is available for a set of CWEs, check SSOT documentaton and spreadsheet.
Query custom errors in Elastic	Check this dashboard for further investigation.

CWE Support

Vulnerability Explaination

Vulnerability Explaination is enabled for all SAST vulnerabilities.

Vulnerability Resolution

Vulnerability Resolution is enabled for SAST vulnerabilities, only for a specific set of CWEs documented at Supported vulnerabilities for Vulnerability Resolution.

We determine whether a vulnerability supports Vulnerability Resolution based on its CWE identifier. This support is tracked using two mechanisms:

1. Database field on vulnerability records has_vulnerability_resolution

   The database field is populated and backfilled during ingestion, meaning any successful pipeline run on the default branch after a CWE list update will ensure it contains the latest values.

   This field is used, for example, in:

   • The Vulnerability Report (for filtering and display)
   • Vulnerability Details (e.g., availability of “Resolve with AI”)

   Attention: Background migrations aren’t strictly required to backfill this value, but they are currently an established part of our workflow (see example migration). Any changes to this process must be clearly documented.

2. Hardcoded list

   • Used for pipeline findings (e.g., in merge requests), meaning they haven’t been fully ingested as vulnerability records yet and the has_vulnerability_resolution field in the database remains unset.

Note: Unsupported CWEs may be tested by enabling the ignore_supported_cwe_list_check feature flag at the project level (MR)

Dashboard to see logs

1. Production log dashboard - shows request/response/error as well as p50/p90/p99 for the timings of the duo request
2. Staging log dashboard

Monitoring VR alerts

1. Elastic watcher
2. Slack channel to see alerts: #g_srm_security_insights_ai_error_alerts
3. Elastic logs used in watcher: https://log.gprd.gitlab.net/app/r/s/foNLr
4. Error watcher in IaC repo: https://gitlab.com/gitlab-com/runbooks/-/blob/master/elastic/managed-objects/log_gprd/watches/test_g_srm_security_insights_ai_error_watcher.jsonnet
5. Alert threshold for this watcher is 5 errors over last 90 minutes. If needed the watcher can be deactivated from this page. The threshold value can be changed from the edit page.

Resources

1. Documentation
   • Vulnerability Resolution
   • Vulnerability Resolution in the MR
2. LLM Prompts for VE and RV