Secret Detection execution policy not scanning full commit range

Summary

Per @mcavoj

I was testing something related to secret detection and policies the other day and noticed something weird. I reproduced it in this test project: gitlab-org/govern/security-policies/martins-test-group/secret-detection-test!1
I have a policy requiring approval when secret detection scanner finds vulnerabilities. In the first commit, it correctly identifies a leaked secret and requires an approval. In the same MR, I add a second commit, just changing something in the README, and now the MR doesn't require the approval anymore because the scanner checked only the last commit and there are no security vulnerabilities detected.
This seems to me like a pretty big oversight when it comes to requiring approvals. Shouldn't the scanner run in something like a historic mode in the scope of the MR, scanning all the commits? Do you have something like this on your radar?

Yes, it should scan the full commit range. If the policy is not this is a typebug bugfunctional

Steps to reproduce

Example Project

gitlab-org/govern/security-policies/martins-test-group/secret-detection-test!1

What is the current bug behavior?

1. A Category:Secret Detection Scan Execution Policy should scan all commits in a given MR

What is the expected correct behavior?

1. A Category:Secret Detection Scan Execution Policy only scans the latest commit

Output of checks

This bug happens on GitLab.com

Possible fixes

Author Maintainer

Correct typo in Secret Detection variable reference: https://gitlab.com/gitlab-org/gitlab/-/blob/733485bbc11f4118e2dcdf30aeecaf133c5c31b0/ee/app/services/security/security_orchestration_policies/create_pipeline_service.rb#L68

SECRET_DETECTION_LOG_OPTS should be SECRET_DETECTION_LOG_OPTIONS per our docs and the source analyzer.