Gitleaks Integration with DefectDojo

Gitleaks Integration with DefectDojo

Gitleaks is an open source secret scanner, created by Zachary Rice, that finds hardcoded credentials such as API keys, tokens, passwords, and private keys. It can scan a repository's full Git history, a plain directory, or input from stdin, and it identifies secrets with a configurable set of regex and entropy-based rules. Gitleaks writes reports in JSON, CSV, JUnit, and SARIF, and DefectDojo imports the JSON format.

Gitleaks Integration with DefectDojo

Gitleaks is quick enough to run on every push, which is why we use it, but a leaked key isn't fixed when the scan goes red. It's fixed when the credential is rotated and the exposure is closed out. Importing Gitleaks results into DefectDojo turns each detected secret into a Finding on the repository's Asset, with an owner and a short SLA. Reimporting later scans tells us which ones are actually gone, and the history is there when someone asks how long a key sat in the repo.

Why Gitleaks Matters

Committed credentials are one of the most direct ways an attacker gets from source code to production systems.

• Gitleaks scans Git history, not just the current tree, so a key deleted three commits ago is still caught.
• Its default rule set covers many common providers, and teams can add rules for internal token formats.
• It runs as a single binary, in a pre-commit hook or a CI job, with no service to host.
• The --redact option keeps secret values out of the report, so results can be shared and stored more safely.
• A Gitleaks report is a list of matches. It doesn't track whether each credential was rotated, who owns it, or how long it was exposed.

Advantages of This Integration

What we gained by sending Gitleaks results through DefectDojo:

• Rotation tracked to closure. Each secret becomes a Finding with an owner, notes, and an SLA. The work isn't done until the Finding is closed, not when the CI job passes.
• High default severity. Every Gitleaks finding imports as High (older reports can raise AWS, GitHub, and Heroku rules to Critical), so secrets land under a tight SLA by default.
• Consistent classification. All findings carry CWE-798 (Use of Hard-coded Credentials), which makes secrets easy to report on across every tool that flags them.
• Fewer duplicates. Within a report, the same secret on the same line in the same file is merged into one Finding with an occurrence count. Across scans, DefectDojo hashes title, CWE, line, file path, and description.
• Lifecycle on reimport. Reimporting a new scan into the same Test mitigates secrets that no longer appear and reactivates any that return.

How This Integration Works

DefectDojo imports Gitleaks output with the Gitleaks Scan scan type. The parser recognizes both the current Gitleaks 8 JSON format and the older format from Gitleaks 7 and earlier.

1. Run Gitleaks with JSON output. To scan a repository's history with secrets redacted:

gitleaks git . --redact --report-format json --report-path gitleaks-report.json

Use gitleaks dir instead to scan a directory that isn't a Git repository. Older Gitleaks 8 releases use gitleaks detect with the same report flags.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Gitleaks Scan, and upload the JSON. To automate (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Gitleaks Scan" \
  -F "file=@gitleaks-report.json" \
  -F "product_name=checkout-web" \
  -F "engagement_name=Secret Scanning" \
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Gitleaks Scan" \
  --report-path "./gitleaks-report.json" \
  --product-name "checkout-web" \
  --engagement-name "Secret Scanning" \
  --auto-create-context

3. Reimport after cleanup. Once a secret has been rotated and removed (including from history, if your process requires it), reimport a fresh scan into the same Test so the Finding is mitigated with a record of when.

An empty Gitleaks report (a JSON null) imports cleanly with zero findings.

Data Granularity: What Gets Imported

For Gitleaks 7 reports, the description instead lists commit message, hash, date, author, rule, path, line, operation, and leak URL, and the matched string is shown with the secret replaced by REDACTED. Commit author and email from Gitleaks 8 reports are deliberately not imported.

Use Cases

On every push: A CI job runs Gitleaks on the repository and imports the result. A new High finding notifies the owning team, and the SLA clock starts the moment the secret is detected, not when someone gets around to reading the log.

For a history sweep: Before open sourcing an internal repository, the security team runs a full-history scan and imports it. Each Finding is assigned for rotation, and the repository stays private until every one is closed.

Across an organization: Scanning every repository and importing into each Asset gives security leads a count of open secrets by team, with ages, which makes the cleanup measurable.

For audit evidence: When a reviewer asks how hardcoded credentials are handled, DefectDojo shows detection dates, owners, rotation notes, and closure dates for every secret found.

Operational Tips

• Always run with --redact. The Gitleaks 8 parser copies the Secret and Match fields into the description, so an unredacted report stores the live credential in DefectDojo.
• Treat closure as rotation, not deletion. Removing the line from the latest commit doesn't help if the key is still valid and still in history. Add a note recording the rotation before closing.
• Use the Gitleaks rule tags to route findings. Custom rules can tag internal token formats, and those tags carry into DefectDojo for filtering.
• Mark test fixtures and sample keys as false positives in DefectDojo, or better, add them to a Gitleaks allowlist so they stop appearing at the source.
• Description is part of the deduplication hash, and it includes commit details. Scanning different commit ranges can therefore produce separate Findings for the same secret. Keep the scan scope consistent per Test.
• Set an SLA for High that reflects how fast a credential should be rotated, typically much shorter than for code vulnerabilities.