Nosey Parker Integration with DefectDojo

Nosey Parker Integration with DefectDojo

Nosey Parker is an open source command-line secret scanner from Praetorian. It searches files, directories, and the full history of Git repositories for credentials and other sensitive values, such as cloud access keys, API tokens, private keys, and passwords, using a large set of detection rules. Scans are stored in a local datastore, and the report command writes findings in human-readable text, JSON, JSON Lines, or SARIF. Praetorian archived the repository in April 2026 and names Titus as its replacement, so existing pipelines keep working but new features will not arrive.

Nosey Parker Integration with DefectDojo

We added Nosey Parker because it is fast on large repositories and digs through Git history, which is where most of our leaked secrets turned out to be. The scanner tells you what it found. It doesn't tell you whether the key was rotated, who was asked to do it, or whether the same token reappeared a month later. Importing its JSON Lines output into DefectDojo gives every secret a Finding with its file, line, and commit, an owner, and a High severity SLA.

Why Nosey Parker Matters

A credential committed to a repository is exposed to everyone with read access, and deleting the file doesn't remove it from history.

• Full-history scanning catches secrets that were committed and later removed, which branch-only checks miss.
• Findings include the commit ID and committer, so the team can identify when and how a secret entered the code.
• Its rules cover many credential types across cloud providers and SaaS services.
• Secret findings need a real remediation workflow: rotate, remove, verify. A list of matches in a terminal doesn't provide one.

Advantages of This Integration

What we gained by routing Nosey Parker results through DefectDojo:

• One finding per secret location. The parser merges matches with the same file path, line, and secret (or rule, in newer output) and counts repeats as occurrences, so a key copied across many commits doesn't flood the queue.
• Consistent severity and CWE. Every finding is High with CWE-798 (use of hard-coded credentials), so secrets land under a single SLA and are easy to filter.
• A built-in remediation step. Each finding's mitigation tells the owner to reset the credential, remove it from source, and move it to a secrets manager.
• Lifecycle tracking. Reimporting into the same Test mitigates secrets that are gone and adds new ones.
• Assignment and Jira. Findings can be routed to the repository owner and pushed to Jira so rotation work is visible.

How This Integration Works

DefectDojo imports Nosey Parker output with the Nosey Parker Scan scan type. The parser only accepts JSON Lines files with a .jsonl extension, and it supports the output formats of Nosey Parker v0.16.0 and v0.22.0.

1. Scan and write a JSON Lines report. Scan a repository into a datastore, then report from it:

noseyparker scan --datastore np.noseyparker ./payments-api
noseyparker report --datastore np.noseyparker --format jsonl --output noseyparker.jsonl

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Nosey Parker Scan, and upload the .jsonl file. For automation, use 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=Nosey Parker Scan" \
  -F "file=@noseyparker.jsonl" \
  -F "product_name=payments-api" \
  -F "engagement_name=Secret Scanning" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Nosey Parker Scan" \
  --report-path "./noseyparker.jsonl" \
  --product-name "payments-api" \
  --engagement-name "Secret Scanning" \
  --auto-create-context

3. Reimport with care. For full-history scans, a secret removed from the current code still appears in history, so it keeps showing up. DefectDojo's documentation recommends setting do_not_reactivate when reimporting through the API so findings you closed after rotation stay closed.

Data Granularity: What Gets Imported

Use Cases

When onboarding a legacy repository: A full-history scan of an old monorepo surfaces credentials from years of commits. The team imports them, assigns each to the service owner, rotates, and closes them with notes, using do_not_reactivate on later reimports.

In a CI/CD pipeline: A branch scan on every merge reimports into a Test per repository, and any new High finding is a signal to rotate before the change ships.

After an incident: When a token is reported leaked, a fresh scan and import shows every location it appears, with commit and committer, so responders can trace how it spread.

For security reporting: Leaders can report open secret findings by Asset and age against the High SLA without stitching together scanner output from many repositories.

Operational Tips

• Save reports with the .jsonl extension. The parser rejects other extensions, including .json files containing the same data.
• Rotate first, then remove. Removing a secret from the current code does not revoke it, and full-history scans will keep reporting it.
• Use do_not_reactivate on API reimports of full-history scans, as the parser docs recommend, so rotated secrets don't come back as active.
• Remember that the commit ID is part of the title. The same secret found through a different first commit can appear as a separate finding.
• Restrict access to the Asset. Descriptions include committer names and email addresses, and v0.16.0 output adds the first three characters of each secret.
• Plan for the archive. Nosey Parker no longer receives updates, and the DefectDojo parser supports v0.16.0 and v0.22.0 output only, so pin a version in CI.