Trufflehog Integration with DefectDojo

Trufflehog Integration with DefectDojo

TruffleHog is an open source secret scanner from Truffle Security that searches Git repositories, file systems, and other sources for credentials such as API keys, tokens, and private keys. Version 3 identifies secrets with hundreds of credential-specific detectors and can verify many of them against the issuing service, reporting whether a found key is live. Trufflehog3 is a separate fork of the original TruffleHog, maintained at feeltheajf/trufflehog3 and installed with pip, that scans files and Git history using rules and entropy checks. Both tools write JSON, and DefectDojo has a parser for each. Truffle Security also sells TruffleHog Enterprise, and DefectDojo Pro has a connector that imports its secret detections.

Trufflehog Integration with DefectDojo

We scan repositories for secrets because a leaked credential is one of the few findings that can be exploited the same day it is pushed. Running TruffleHog alone tells us what is in the repository right now. Importing the results into DefectDojo gives every secret an owner, an SLA, and a record of when it was found, in which file and commit, and whether TruffleHog could verify it. When a key is rotated and removed from history, the next reimport closes the Finding, so we can show it was handled rather than assume it. Teams on TruffleHog Enterprise and DefectDojo Pro can skip the files and let the TruffleHog connector sync detections directly.

Why Trufflehog Matters

Secrets end up in source control through test fixtures, configuration files, and quick debugging commits. Deleting the line later does not remove it from Git history.

• TruffleHog scans the full commit history, not just the current tree, so it finds secrets that were committed and later removed.
• TruffleHog v3 can verify many credential types, which separates a live key from a revoked one or a false match.
• Trufflehog3 supports custom rules and entropy detection for teams that want a simpler, rule-driven scanner.
• A leaked secret is fixed by rotating it, not by editing code. That work usually crosses teams, which is why it needs tracking outside the scanner.

Advantages of This Integration

What we gained by routing secret scanning results through DefectDojo:

• Verification status carried over. For TruffleHog v3 reports, the tool's Verified result sets the DefectDojo Finding's verified flag, so live credentials can be filtered and handled first.
• Commit-level context. Descriptions include the repository, commit hash, commit date, file path, and a link to the commit when the source provides one.
• Collapsed duplicates. Within one report, repeated hits for the same secret in the same place merge into one Finding with an occurrence count.
• Rotation as tracked work. Each Finding can be assigned to the service owner, pushed to Jira, and held to an SLA, which is where rotation tends to stall without follow-up.
• Enterprise sync with DefectDojo Pro. The TruffleHog connector creates a Record for each configured scan source (a repository, bucket, or registry) in TruffleHog Enterprise, with no per-source setup, and findings carry only the redacted secret.
• History that survives cleanup. Reimporting after the secret is removed mitigates the Finding but keeps its record for audit.

How This Integration Works

DefectDojo has two scan types for this row:

• Trufflehog Scan reads JSON output from TruffleHog v2 or v3. The parser detects the version from the first line: v3 lines contain SourceMetadata, v2 lines contain path.
• Trufflehog3 Scan reads the JSON array written by the Trufflehog3 fork, in both its current rule-based format and its older format.

1. Produce a report. With TruffleHog v3, scan a repository and write one JSON object per line:

trufflehog git https://github.com/acme/payments-api.git --json > trufflehog-report.json

The same --json flag works with other TruffleHog sources, such as trufflehog filesystem ./ --json. With Trufflehog3:

trufflehog3 --format json --output trufflehog3-report.json

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Trufflehog Scan or Trufflehog3 Scan, and upload the file. Through the API, in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Trufflehog Scan" \
  -F "file=@trufflehog-report.json" \
  -F "product_name=payments-api" \
  -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 "Trufflehog3 Scan" \
  --report-path "./trufflehog3-report.json" \
  --product-name "payments-api" \
  --engagement-name "Secret Scanning" \
  --auto-create-context

3. Reimport after remediation. Send later scans to /api/v2/reimport-scan/ against the same Test, so secrets that no longer appear are mitigated.

Option: TruffleHog connector (DefectDojo Pro). If you run TruffleHog Enterprise, configure the TruffleHog connector in the DefectDojo Pro UI. Enter your TruffleHog Enterprise API host in the Location field and an Enterprise API token (sent as a bearer token) in the Secret field, and optionally set a Minimum Severity. Each configured scan source becomes a Record that you map to an Asset, and its detections become findings. The connector is for TruffleHog Enterprise only. It is not related to the Trufflehog3 parser, which reads a different tool's report format.

Data Granularity: What Gets Imported

Trufflehog3 reports include a commit author, but the parser intentionally does not import it. TruffleHog v3 descriptions do include the committer field from the source metadata.

The DefectDojo Pro connector handles secrets more conservatively than the file parsers. Findings carry only the redacted secret as TruffleHog Enterprise reports it. Raw secret material is read only to compute the deduplication digest and never reaches a finding field, log line, or error message.

Use Cases

In pre-merge CI: A pipeline runs TruffleHog v3 on each pull request branch and reimports into a Test per repository. A verified secret shows up as a Critical, verified Finding, and the team can block the merge and start rotation the same day.

For a one-time history sweep: Before open sourcing an internal project, a team scans the full Git history and imports the results. Every hit becomes a Finding to rotate or dismiss, and the Engagement records that the review happened.

Across many repositories: A security team scans every repository in an organization nightly and imports each into its owning Asset. Leads get one view of open secrets by team instead of a pile of JSON files.

For audits: DefectDojo keeps when each secret was found, who owned it, and when it was closed, which answers the question of how quickly exposed credentials were rotated.

Operational Tips

• Treat imported descriptions as sensitive. TruffleHog v2 and Trufflehog3 Findings include the matched secret text, so limit who can view these Assets and rotate the credential rather than relying on access control alone. If you have TruffleHog Enterprise, the DefectDojo Pro connector avoids this, because it stores only redacted values and never logs response bodies, even with debug logging on.
• With TruffleHog v3, nearly every Finding arrives as Critical, including unverified ones. Filter on the verified flag to triage live secrets first, then downgrade or close unverified matches after review.
• Keep the scanner consistent per repository. A Trufflehog Scan and a Trufflehog3 Scan of the same code produce differently shaped titles and descriptions and will not deduplicate against each other.
• Rotate, then clean history. Removing a secret from the current tree only stops future matches if history scanning is also clean, so reimport after any history rewrite to confirm the Finding closes.
• Mark known test fixtures as false positives once. DefectDojo keeps that decision on the Finding across reimports into the same Test.
• Tag imports with the repository name (for example tags=secrets,payments-api) to report on secret exposure separately from code findings.