n0s1 Integration with DefectDojo

n0s1 Integration with DefectDojo

n0s1 is an open source secret scanner from Spark 1, published under the spark1security organization on GitHub. Instead of scanning source code, it targets the places people paste credentials while they work: issue trackers, wikis, and chat, including Jira, Confluence, Slack, Linear, Asana, Wrike, Zendesk, GitHub, and GitLab, as well as the local filesystem. It matches content against a set of regex rules for known token formats and writes a report in its own JSON format, SARIF, or GitLab format. DefectDojo imports the n0s1 JSON format.

n0s1 Integration with DefectDojo

We run n0s1 because our code scanning was never going to find the API key someone pasted into a Jira comment to unblock a colleague. Importing the n0s1 report into DefectDojo turns each match into a High severity Finding on the Asset that owns the workspace, with the link to the exact ticket or page, the field it was found in, and the rule that matched. Those Findings get an owner and a due date, which is what actually gets a credential rotated.

Why n0s1 Matters

Secrets do not only leak through repositories. Support tickets, runbook pages, and incident threads collect tokens and passwords, often from people with broad access, and those platforms are usually readable by far more people than a single repository.

• It scans collaboration platforms directly, through their APIs, rather than relying on exports.
• It records where a match was found, including the URL and the ticket field, so the owner can find and clean it up.
• Its rules are regular expressions with keywords and tags, and the report includes the rule set it used, so reviewers can see which credential type matched and why.
• A leaked credential is a problem until it is revoked, not just until the text is deleted. That follow-through needs tracking outside the scanner.

Advantages of This Integration

Running n0s1 through DefectDojo gives us:

• Every leak treated as urgent. All n0s1 findings import at High severity, so they fall under your High SLA without per-rule configuration.
• Location on the Finding. The description carries the URL, platform, and ticket field, which tells the assignee exactly where to go.
• Rule context. The matched rule's ID becomes the title, and the rule's description, pattern, keywords, and tags are added to the description, so reviewers know what kind of credential was found.
• No duplicates within a run. n0s1 gives each match an ID. The parser keeps one Finding per ID, even if it appears more than once in the report.
• Deduplication across scans. DefectDojo hashes n0s1 findings on the description, which includes the location and matched content, so rescanning the same unresolved leak does not create a second Finding.
• Closure on reimport. Once the text is removed from the ticket or page, reimporting the next scan mitigates the Finding. Pair that with a note confirming the credential was revoked.

How This Integration Works

DefectDojo reads n0s1 output with the n0s1 Scanner scan type.

1. Run a scan and write a report. Each platform has its own n0s1 subcommand (for example jira_scan or confluence_scan), which takes the server address and the platform account details as options. Use --report-file to write the report; the default report format is n0s1's own JSON, which is what DefectDojo expects. Keep platform credentials in environment variables or your CI secret store:

n0s1 confluence_scan --server "https://YOUR_SITE.atlassian.net" --email "$CONFLUENCE_EMAIL" --api-key "$CONFLUENCE_API_TOKEN" --report-file n0s1-report.json

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select n0s1 Scanner, and upload the file. For automation, the API works in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=n0s1 Scanner" 
  -F "file=@n0s1-report.json" 
  -F "product_name=engineering-wiki" 
  -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 "n0s1 Scanner" 
  --report-path "./n0s1-report.json" 
  --product-name "engineering-wiki" 
  --engagement-name "Secret Scanning" 
  --auto-create-context

3. Reimport on a schedule. Send later scans of the same platform to /api/v2/reimport-scan/ against the same Test, so cleaned-up locations are mitigated.

The parser reads the report's findings object and its regex_config rules, merging the rule details into each Finding.

Data Granularity: What Gets Imported

n0s1 does not report CWEs, CVEs, file paths, or remediation text, so those fields are left empty. Rotating or revoking the credential is the remediation in every case.

Use Cases

For collaboration platform hygiene: A security team scans its Jira and Confluence instances weekly and reimports each into its own Test. New Findings go to the space or project owner, and the Test shows how many leaks are still open and for how long.

After an incident: When a credential is found in a ticket during an investigation, a one-off n0s1 scan of the affected platform shows whether the same token, or others, appear elsewhere. Each match becomes a tracked Finding rather than a line in an incident document.

Alongside code secret scanning: Teams that already import repository secret scanners into DefectDojo add n0s1 for their issue trackers and wikis, so all leaked credential findings appear in one queue with one SLA.

For audit evidence: Findings record when each leak was discovered and closed, which gives auditors a history of how credential exposure in collaboration tools is handled.

Operational Tips

• The description includes the excerpt n0s1 recorded for the match. Check what your n0s1 configuration writes into the report, and restrict access to these Findings accordingly.
• Deleting the text closes the Finding on reimport, but the credential may already be copied elsewhere. Add a note confirming revocation before closing the work.
• Because deduplication uses the full description, an edit to the surrounding text or a rule change can make a known leak import as a new Finding. Review new Findings against recently mitigated ones after rule updates.
• Use a separate Test per platform (Jira, Confluence, GitHub) so reimports of one platform do not mitigate findings from another.
• Every finding is High. If a rule produces false positives for an internal format, mark them as false positives rather than lowering the threshold for all rules.
• Scan with an account that can read the spaces and projects you care about. Content the account cannot see is not scanned, and that gap is invisible in the report.