MR security widget shows findings as new after rebase
Summary
Previously existing vulnerabilities in the target branch will appear as X new potential vulnerabilities
in the merge request security findings widget after a rebase and force push.
Steps to reproduce
- Fork the example repository or create a new one which includes secret detection within the
.gitlab-ci.yml
. Be sure to include vulnerabilities, such as thetest.tf
file in the example project. - Ensure the default branch has a successful pipeline run with secret detection having identified the intentionally added vulnerability.
- Create a secondary branch.
- Add a commit, push up the new branch.
- Create a new merge request. After the pipeline runs, the security widget will detect no new potential vulnerabilities.
- Checkout the default branch, make a new commit and push it up.
- Checkout the feature branch and rebase.
- Force push your changes.
- Observe security widget in existing MR.
Example Project
https://gitlab.com/calebw/security-widget-rebase
What is the current bug behavior?
Existing vulnerabilities in the target branch are displayed as new potential vulnerabilities in the merge request security widget.
What is the expected correct behavior?
Existing vulnerabilities in the target branch are not displayed as new potential vulnerabilities in the merge request security widget.
Relevant logs and/or screenshots
These vulnerability exists on the default branch:
After creating a new branch from the default, adding a test file and creating a merge request, the security widget appropriately identifies no new potential vulnerabilities:
Commits are then added to main. The feature branch is rebased, and the changes force pushed. This results in the existing vulnerability being shown as new in the security widget:
Output of checks
This bug happens on GitLab.com