Report comparison logic does not work when the base commit does not have pipeline on the target branch

Summary

Security report comparison is done by comparing the artifacts generated by the "base pipeline" and the "head pipeline". The "base pipeline" is the pipeline for the base commit on the target branch. If there is no pipeline for the base commit on the target branch, the "MR security widget" shows all the vulnerabilities as new even if they exist on the target branch(e.g. default branch).

The base commit might not have a pipeline on the target branch if that commit was initially on a feature branch which eventually gets merged into the target branch.

Another similar scenario happens when the pipeline on the target branch is skipped.

Steps to reproduce

  1. Create a new branch(feature-1) from the default branch
  2. Add a commit to the branch called feature-1
  3. Create another branch from the feature-1 branch called feature-2
  4. Create a new branch(feature-1) from the default branch
  5. Merge the feature-1 branch into the default branch
  6. Create a merge request for the feature-2 branch targeting the default branch
  7. At this point you should see all the vulnerabilities as new.

Example Project

gitlab-org/govern/demos/sandbox/minac/static-reports/interesting-mr-widget-behavior!2 (closed)

What is the current bug behavior?

When there is no pipeline for base commit on the target branch, the MR security widget reports all vulnerabilities as new, even if these existed on the target branch.

What is the expected correct behavior?

Even if no pipeline exists for base commit on the target branch the MR security widget properly reports vulnerabilities by not showing old vulnerabilities that existed on target branch prior to this change as new ones if there is a pipeline for the base commit on other branches.

Relevant logs and/or screenshots

Vulnerability widget incorrectly showing detected vulnerability as new even though it was already introduced by earlier commit: image

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

Workarounds

  1. The workaround for this bug is to use merged results pipeline as suggested in #436956 (comment 1736611731)
Edited by Alejandro Guerrero