Secrets detection fails when default branch has unrelated history

Summary

Secret detection will exit with error ERR fatal: ambiguous argument when $CI_DEFAULT_BRANCH is unrelated.

Steps to reproduce

# git init secret-detection-bug -b master && cd secret-detection-bug/
# git remote add origin git@gitlab.com:group/subgroup/secret-detection-bug.git
# for i in {1..5};do echo test${i} >> testfile.txt; git add testfile.txt; git commit -m "commit #${i} on master" ;done
# cat >.gitlab-ci.yml <<EOL
include:
  - template: Security/Secret-Detection.gitlab-ci.yml

variables:
  SECURE_LOG_LEVEL: "debug"
EOL
# git add .gitlab-ci.yaml; git commit -m "enable Secret Detection" 
# git push origin master

### Creating unrelated branch 

# git init secret-detection-bug2 -b gcs && cd secret-detection-bug2/
# git remote add origin git@gitlab.com:group/subgroup/secret-detection-bug.git
# for i in {1..5};do echo test${i} >> testfile.txt; git add testfile.txt; git commit -m "commit #${i} on gcs" ;done
# cat >.gitlab-ci.yml <<EOL
include:
  - template: Security/Secret-Detection.gitlab-ci.yml

variables:
  SECURE_LOG_LEVEL: "debug"
EOL
# git add .gitlab-ci.yaml; git commit -m "enable Secret Detection" 
# git push origin gcs

The secret-detection job that starts by the push event on gcs branch will fail.

Example Project

https://gitlab.com/gitlab-gold/kateg/secret-detection-bug/-/jobs/2055143176

What is the current bug behavior?

The secret-detection job that starts by the push event on gcs branch will fail.

What is the expected correct behavior?

The secret-detection job that starts by the push event on gcs branch should pass.

Relevant logs and/or screenshots

[INFO] [secrets] [2022-02-04T14:08:47Z] ▶ 2:08PM ERR fatal: ambiguous argument '27b8c90e6a8fa1114ee2e184aa070ff5d302c61f^..6206b23445155b547a79ea6294b79f55c0bc2082': unknown revision or path not in the working tree.

Output of checks

This bug happens on GitLab.com

Possible fixes

Do not include parent commit into the scan by removing ^ here. This fix has a drawback, however. The number of commits gitleaks has to scan will grow overtime indefinitely if default branch stays unrelated.

An alternative solution will be documenting this caveat in the Troubleshooting section and advise the customers to always make sure the the their repo's default branch is related to the branch where secret detection job is running. Created a Docs MR for this: !79959 (merged)