MR security widget and approval rules work incorrectly for chained MRs

Summary

When project has Merge commit merge method and multiple MRs are chained with branches created from one another before they are merged, the MR security widget and MR approval rules work incorrectly by enforcing approvals and showing security findings as newly detected. This happens because the pipeline runs after the MR is merged for the merge commit only, but the MR's base commit (diff_base_commit) does not run a pipeline.

Steps to reproduce

  • Create a project with a security scan that introduces new vulnerabilities
  • Create a security policy to require approval when a new vulnerability is introduced
  • Make sure that the merge method in Settings -> Merge Request is Merge commit
  • Create a branch (first-change), update README.md and create an MR
  • Create a new branch from the previously created branch (second-change), update README.md and create an MR with the target branch as the previously created branch
  • Observe that both the MRs does not show any new findings in MR widget and no approval is required
  • Merge the first MR
  • Observe that the second MR's target branch is updated to default branch but the MR now requires approval and MR widget shows the findings as newly introduced

Example Project

https://gitlab.com/gitlab-org/govern/security-policies/sashis-test-group/test-same-branch

First MR Second MR
Before Screenshot_2024-04-23_at_2.17.46_PM Screenshot_2024-04-23_at_2.17.52_PM
Screenshot_2024-04-23_at_2.35.27_PM Screenshot_2024-04-23_at_2.18.31_PM

In the list of commits below, 29dad197 is the diff_base_commit of the second MR, but since we have merge commit merge method, the pipeline runs only for the merge commit and not for the other commits in the source branch. This results in comparing the source branch pipeline to no pipeline resulting in incorrect behaviour

Screenshot_2024-04-23_at_2.36.00_PM

In the violation bot comment, the target pipeline is empty: Screenshot_2024-04-23_at_2.18.38_PM

What is the current bug behavior?

  • MR widget shows the vulnerabilities as newly introduced
  • MR approval rules enforce false approvals

What is the expected correct behavior?

  • MR widget should not show the vulnerabilities as newly introduced
  • MR approval rules should not enforce approvals

Relevant logs and/or 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