nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

atlassian/git-secrets-scan does not annotate the commit correctly in the pipeline report

Casper Rademaker

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.

Accepted answers

Igor Stoyanov

Hi @Casper Rademaker . New version of the pipe with correct links available.
Example:

Screenshot 2025-02-14 at 14.31.39.png

```The pipeline does not seem to find any leaked secrets when triggered manually, rather than from a pull request.``` -- could not reproduce this.

Regards, Igor

All comments

Igor Stoyanov

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

Igor Stoyanov

Hi @Casper Rademaker . New version of the pipe with correct links available.
Example:

Screenshot 2025-02-14 at 14.31.39.png

```The pipeline does not seem to find any leaked secrets when triggered manually, rather than from a pull request.``` -- could not reproduce this.

Regards, Igor

Casper Rademaker

Hi Igor,

This is great work, thanks, I was able to confirm that the findings in the secret scan pipeline reports for 3.1.0 link to the right commits. Super happy with this!

Regarding difference between manual runs and PR runs, we still observe differences, hereby my findings. I can also split this off in a separate thread if so desired.

Pipeline definition (abbreviated)

image: python:3.13

pipelines:
  pull-requests:
    '**':
      - parallel:
        - step:
            name: Bitbucket Security - Secret Scanner
            script:
              - pipe: atlassian/git-secrets-scan:3.1.0
                variables:
                  DEBUG: "true"
                  GITLEAKS_EXTRA_ARGS: "--verbose --redact=100 --max-decode-depth 3"

Manual pipeline run triggered on a specific branch, gives log:

INFO: Extend gitleaks command to create reports...
DEBUG: gitleaks generated command:
gitleaks git -v --report-path=gitleaks-report.json --report-format=json
1:36PM INF 102 commits scanned.
1:36PM INF scanned ~1677326 bytes (1.68 MB) in 629ms
1:36PM WRN leaks found: 7

102 commits are scanned. 7 leaks are found.

Manual pipeline run triggered on a created PR, from the same branch as before:

INFO: Extend gitleaks command to create reports...
DEBUG: gitleaks generated command:
gitleaks git -v --report-path=gitleaks-report.json --report-format=json
1:39PM INF 452 commits scanned.
1:39PM INF scanned ~1347768 bytes (1.35 MB) in 1.39s
1:39PM WRN leaks found: 6

452 commits are scanned. 6 leaks are found.

Findings:

- A different commit range is scanned (102 commits in manual run vs. 452 commits in PR run)
- Actually, more leaks are found in the manual run, even though the number of commits is smaller, meaning the manual run commit range is not a subset of the PR run commit range.
- Not shown in above logs, but the leaks are not redacted, `redact=100` flag seems to be ignored by the pipe.

Let me know if I can submit any other info. My repo is private, so unfortunately, I cannot share access.

Igor Stoyanov

Hi @Casper Rademaker .
Your arguments was not passed correctly, because it is required to use them in a different way:

variables:
  DEBUG: "true"
  GITLEAKS_EXTRA_ARGS:
    - "--redact=100"
    - "--max-decode-depth=3"

also you could skip --verbose since this flag added automatically with by DEBUG: "true"

I tried to reproduce your issue, but i always receive the same number in my pipelines.

Also you provided your pipe usage for pull-requests. Maybe there is another for custom branch?

One of the possible reasons is that there are different commits number for different sources/branches. I. e:


git rev-list --count HEAD
99

git rev-list --count master
68

and this is how it works with gitleaks git.

Also you could describe your case here: https://github.com/gitleaks/gitleaks/issues, because i'm not sure this problem relates to the pipe or to the gitleaks tool.

Regards, Igor

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud

git

bitbucket-pipelines

security

pipes

secrets