Skip to content

GitLab SAST Incorrectly Auto-Resolving Security Vulnerabilities

Summary

GitLab's SAST scanner is incorrectly auto-resolving security vulnerabilities when the underlying security issues have not been remediated. This behavior creates security risks as vulnerable code remains in production while appearing to be fixed in the GitLab interface.

Steps to reproduce

Pattern 1: Code Movement Resolution

  1. Create a file with a security vulnerability (e.g., XSS vulnerability on line 10)
  2. Run SAST scan to detect the vulnerability
  3. Verify vulnerability appears in Security Dashboard
  4. Make unrelated code changes that move the vulnerable code to a different line number (add comments, whitespace, or code above the vulnerable line)
  5. Commit changes and run SAST scan again
  6. Observe that GitLab incorrectly marks the original vulnerability as resolved

Pattern 2: Minor Code Changes with Duplicate Creation

  1. Create a file with a security vulnerability
  2. Run SAST scan to detect the vulnerability
  3. Make minor, non-security-related changes to the same file (formatting, comments, variable renaming)
  4. Commit changes and run SAST scan again
  5. Observe that GitLab may incorrectly resolve the original finding and sometimes creates a duplicate finding for the same vulnerability

Pattern 3: False Fix Detection

  1. Create a file with a security vulnerability
  2. Run SAST scan to detect the vulnerability
  3. Make code changes that don't actually address the security issue but modify the surrounding context
  4. Commit changes and run SAST scan again
  5. Observe that GitLab incorrectly detects remediation and marks the vulnerability as resolved

Example Project

What is the current bug behavior?

  • Vulnerabilities are automatically marked as "resolved" when vulnerable code moves to different line numbers due to unrelated changes
  • Security findings disappear from dashboards even though the actual security risk remains in the codebase
  • Duplicate vulnerabilities are sometimes created for the same security issue
  • The auto-resolution logic triggers on cosmetic code changes rather than actual security fixes
  • Manual effort is required to re-open incorrectly resolved findings
  • Creates false sense of security where teams believe vulnerabilities are fixed when they aren't

What is the expected correct behavior?

GitLab SAST should only auto-resolve findings when:

  • The actual vulnerable code pattern has been genuinely remediated
  • The security issue has been legitimately fixed through proper code changes
  • The vulnerability no longer exists in the codebase due to security-relevant modifications

GitLab SAST should NOT auto-resolve findings for:

  • Line number changes due to code reorganization (adding/removing lines above vulnerable code)
  • Cosmetic code changes (comments, whitespace, formatting, variable renaming)
  • Minor modifications to files containing vulnerabilities that don't address the security issue
  • Code movement within the same file or to different files

The vulnerability tracking should be robust enough to:

  • Maintain vulnerability identity across line number changes
  • Distinguish between security-relevant and cosmetic code modifications
  • Preserve vulnerability status through code refactoring that doesn't address the security issue
  • Only resolve vulnerabilities when there is clear evidence of security remediation

Relevant logs and/or screenshots

See support ticket #639017 for screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

 (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:env:info\`)  (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\`)

Results of GitLab application Check

Expand for output related to the GitLab application check 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:check SANITIZE=true`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)

(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖