Merge Request Widget Falsely Shows Existing Vulnerabilities As "new" When Last Default Branch Pipeline is Skipped

Summary

When the latest pipeline on the default branch is skipped (e.g., via git push -o ci.skip) or does not contain security scan jobs, the Merge Request vulnerability widget treats already existing vulnerabilities as "new". This behavior contradicts the GitLab documentation, which states that findings are compared against the last 10 pipelines on the default branch.

Steps to reproduce

1. Ensure the default branch (main or develop) has an existing known vulnerability (e.g., vulnerable dependency in package-lock.json):

   {
     "name": "vuln-demo",
     "version": "1.0.0",
     "lockfileVersion": 1,
     "dependencies": {
       "minimist": {
         "version": "0.0.8",
         "resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.8.tgz",
         "integrity": "sha512-Nu4YOVnAOFDXB/E6m++rRvd8WPoS9K5lYdBQnqJ2bYz+gUMW//LKHEx1h+ZdTJmjRyTckfS+UTfW1REy6+vJvQ=="
       }
     }
   }

2. Push this to the default branch and trigger a normal pipeline with Dependency Scanning enabled:

   git checkout -b main
   git add package-lock.json
   git commit -m "Add vulnerable package"
   git push -u origin main

3. Confirm that the default branch pipeline runs and gl-dependency-scanning-report.json is uploaded.

4. Now, simulate the bug trigger by pushing a commit to the default branch with the pipeline skipped:

   git commit --allow-empty -m "skip the scan"
   git push -o ci.skip

5. Create a new feature branch from that skipped commit:

   git checkout -b feature/trigger-the-bug
   git commit --allow-empty -m "no-op change to see the bug"
   git push -u origin feature/trigger-the-bug

6. Open a Merge Request from feature/trigger-the-bug into main.

7. Let the MR pipeline complete. Observe the MR security widget or Security tab:

   • It will show existing vulnerabilities (e.g., minimist) as new, despite them being already present in a previous scan on main.

8. Sanity check (optional): push a regular (non-skipped) commit to main to re-enable scan baseline:

   git checkout main
   git commit --allow-empty -m "trigger scan"
   git push

   Then refresh the MR — now the previously “new” vulnerabilities will correctly show as “existing”.

Example Project

What is the current bug behavior?

The MR widget treats all findings as “new”, including those already present in the default branch's latest valid security scan.

What is the expected correct behavior?

The Merge Request widget should compare scan results against the most recent successful default branch pipeline that includes security scan reports (up to 10 recent runs), and accurately determine that no new vulnerabilities were introduced.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

This bug happens on GitLab.com

Results of GitLab application Check

This bug happens on GitLab.com

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.