Docs: Update Secret Detection documentation to reflect move away from SECRET_DETECTION_COMMIT_FROM and SECRET_DETECTION_COMMIT_TO in favor of SECRET_DETECTION_COMMITS
For Secret Detection, we currently use v6.1.2+
of gitleaks. Through the upstream Scanning with commit-from and commit-to includes whole commit history issue, gitleaks
no longer accepts the commit-to
and commit-from
options. Instead, a list of one or more commits is provided, either as a list of commits or a file containing a list of commits. Presently, our documentation includes a set of available CI/CD variables for customizing Secret Detection that describes the usage of both SECRET_DETECTION_COMMIT_FROM
and SECRET_DETECTION_COMMIT_TO
.
Related Issues/and MRs
See Update Gitleaks to v6.1.2 and add SECRET_DETECTION_COMMITS for more info. That issue was later updated to suggest updating the docs to reflect this change. This issue is opened to get the docs updated.
gitleaks
tool
Updating the Secret Detection documentation to reflect the changes in functionality from the upstream At a minimum, we should:
-
Not reference SECRET_DETECTION_COMMIT_FROM
-- see !68424 (merged) -
Not reference SECRET_DETECTION_COMMIT_TO
-- see !68424 (merged)
Additionally, I will
-
update the docs to clarify that we should be includingThe docs should continue to refer to theJobs/Secret-Detection.gitlab-ci.yml
instead ofSecurity/Secret-Detection.gitlab-ci.yml
in the Configuration section.Security
namespace.. -
Provide the alternative approach as an example of how to customize the Secret Detection functionality
See:
Independently, it may be worth a separate issue to investigate customizing the value of SECRET_DETECTION_COMMITS_FILE
to get something akin to the control that SECRET_DETECTION_COMMIT_FROM
and SECRET_DETECTION_COMMIT_TO
provided.
Alternative Approach
Update: The following works for me:
secret_detection:
variables:
SECRET_DETECTION_COMMITS: $CI_COMMIT_SHA
I found that with SECRET_DETECTION_COMMITS
set to the predefined variable CI_COMMIT_SHA
, the Secret Detection job did what I expected. I intentionally introduced another secret which was detected. I removed it and it was no longer detected in a subsequent pipeline run.