This request concerns https://bitbucket.org/atlassian/git-secrets-scan/src/master at version 3.0.0 (i.e. latest).
In its default mode, gitleaks and atlassian/git-secrets-scan scan git history, meaning that any leaks found may be in old commits.
Here's an abbreviated output from running below locally on a certain repo
gitleaks . -v
Finding: AUTH_CLIENT_ID=xxx Secret: xxx RuleID: generic-api-key Entropy: 3.784528 File: proxy/.env.development Line: 2 Commit: 6f3a27a5f04fb02494fd2e263da12370e0effec7 Author: xxx Email: xxx Date: 2024-08-22T10:37:20Z Fingerprint: 6f3a27a5f04fb02494fd2e263da12370e0effec7:proxy/.env.development:generic-api-key:2 Finding: ...warz/nidp/oauth/nam AUTH_CLIENT_ID=xxx Secret: xxx RuleID: generic-api-key Entropy: 3.684260 File: proxy/.env.example Line: 3 Commit: 908036907856d808f3eecf76602846bab76fafad Author: xxx Email: xxx Date: 2024-02-16T13:24:07Z Fingerprint: 908036907856d808f3eecf76602846bab76fafad:proxy/.env.example:generic-api-key:3
We set up bitbucket-pipelines.yml as follows:
- step: &atlassian-git-secrets-scan name: Bitbucket Security - Secret Scanner script: - pipe: atlassian/git-secrets-scan:3.0.0 variables: GITLEAKS_EXTRA_ARGS: "--max-decode-depth 3"
The pipeline finds and annotates the two findings (amongst others) in a report, see the two findings expanded below, however, the file URL points to the wrong commit (see bottom-left in attached screenshot)
As-is behavior:
- file links to current commit. The linked line of code is completely out of date. See below example, pointing to and highlighting (in yellow) an empty line of code.
Expected behavior:
- Preferably the file URL links to the correct line of code in the correct commit.
- If not possible, remove the fie URL and clearly add commit hash in the report, so user can find it themselves.
Unfortunately, this is a pretty serious issue, because in practice many leaks are not found in the latest commit and the findings are confusing to users.
Workaround:
Set `DEBUG: true` in pipe variables.
Set `GITLEAKS_EXTRA_ARGS: -v`
Both need to be set. When both are set, at least the pipeline build logs show the commit hashes of the secrets.
Working workaround, but less secure:
Add `GITLEAKS_COMMAND: "dir` so that directory is scanned instead of git history. This is less secure, because leaks found in older commits are not reported.
Additional finding:
The pipeline does not seem to find any leaked secrets when triggered manually, rather than from a pull request.
Hi @Casper Rademaker . Thanks for your suggestion.
Currently under file section in annotation is the same string you could see in the gitleaks report annotation. Your example from gitleaks:
Finding: AUTH_CLIENT_ID=xxx ... File: proxy/.env.development
Bu the UI in the Bitbucket Pipelines redirect to the source file by path provided by pipe git-secrets-scan.
We could try to update this path with commit, so you will have the ability to click and go to the problem file.
```The pipeline does not seem to find any leaked secrets when triggered manually, rather than from a pull request.``` -- our team will also check this.
Also please provide your bitbucket-pipelines.yml details, where you investigating the issue described above.
Regards, Igor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.