Occasionally, the secret detection job on my project (on gitlab.com) fails with:

Couldn't run the gitleaks command: exit status 2
Gitleaks analysis failed: exit status 2

I will try to get time to create a minimal project to reproduce and file an issue, but in the meantime there are two things that I see as bugs:

The list of commits to scan is wrong

The git command to produce the list of commits is:

git log --left-right --cherry-pick --pretty=format:"%H" refs/remotes/origin/$CI_DEFAULT_BRANCH...refs/remotes/origin/$CI_COMMIT_REF_NAME

(From here: https://gitlab.com/gitlab-org/gitlab/-/blob/v13.7.0-rc3-ee/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml#L41)

1. Shouldn’t the commits be the ones on the current branch that are not on the default branch? I.e. shouldn’t it be defaultBranch..currentBranch instead of defaultBranch...currentBranch? (Two dots instead of three!). Otherwise commits on the default branch are also scanned from jobs running on the current branch.
2. Using --left-right has no effect because --pretty=format:"%H" deletes the left/right markings. Tracking the changes through history, it has never had an effect.

Handling of GIT_LENGTH is wrong

In the function limitCommits in the secrets scanner (https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/gitleaks/gitleaks.go#L184) …

1. It is blindly assumed that the list of commits passed is consecutive commits. This is not generally the case. Also: it is particularly not the case for how the scanner is currently used, where commits from both the default branch and the current branch is picked with the ... operator.
2. It is assumed that handling of GIT_LENGTH is simply a matter of truncating the list of commits. How can this be right, when the list of commits can be any list of commits? Also – will there even be commits, that are unknown, when the list has been produced from a repository with git depth set – will git log even return commits that are not part of a shallow clone?