SARIF Integration with DefectDojo
SARIF Integration with DefectDojo
SARIF (Static Analysis Results Interchange Format) is not a scanner. It is an open, JSON-based file format for the output of analysis tools, standardized by OASIS, with version 2.1.0 approved as an OASIS Standard in 2020. A SARIF file describes one or more runs, each with the tool that produced it, the rules it applied, and the results it found, including file locations, code snippets, code flows, fixes, and stable fingerprints. Many tools emit SARIF, among them CodeQL, Semgrep, Trivy, Gitleaks, SpotBugs, Flawfinder, mobsfscan, njsscan, Dockle, and OWASP Dependency-Check, and it is the upload format for GitHub code scanning.
SARIF Integration with DefectDojo
We use DefectDojo's SARIF parser as the common path for the long tail of code analysis tools. When a team adopts a new linter or scanner, the first question we ask is whether it can write SARIF. If it can, the results go into DefectDojo the same day, with file paths, line numbers, CWEs, and fingerprints intact, and each tool still gets its own Test Type so its Findings don't blur together. It means we don't wait for a dedicated parser before a tool's output is tracked, deduplicated, and held to SLAs.
Why SARIF Matters
Every analysis tool used to invent its own output format, and every consumer had to write a parser for each one. SARIF fixes that at the format level.
- One format covers SAST, secrets scanning, IaC checks, container scanning, and more, so one parser handles many tools.
- Rules, results, and locations are structured the same way regardless of vendor, which makes cross-tool reporting consistent.
- The format supports fingerprints, which give each result an identity that survives code moving around.
- Suppressions, fixes, code flows, and taxonomies such as CWE have defined places in the schema instead of being buried in free text.
Advantages of This Integration
What we gained by importing SARIF into DefectDojo:
- A Test Type per tool. DefectDojo reads the tool name from
runs[].tool.driver.nameand creates a Test Type named{tool} (SARIF), such assemgrep (SARIF)orTrivy Scan (SARIF). - Fingerprint-based deduplication. SARIF uses the Unique ID From Tool or Hash Code algorithm: results with
fingerprintsorpartialFingerprintsare matched on that ID, and others fall back to a hash. - Suppressions respected. Results with a
suppressionsentry import as inactive false positives, so in-code suppressions carry their decision with them. - Rich descriptions. Result message, code snippet, rule name and descriptions, and the full code flow are written into the Finding, which makes taint-tracking results readable without the original tool.
- Safe reimport. DefectDojo checks that the tool in a reimported SARIF file matches the existing Test's Test Type, so results from two tools can't overwrite each other.
How This Integration Works
DefectDojo imports SARIF with the SARIF scan type. The parser supports SARIF version 2.1.0.
1. Produce a SARIF file from your tool. Some common examples:
semgrep scan --config auto --sarif --output semgrep.sarif
trivy fs --format sarif --output trivy.sarif .
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select SARIF, and upload the file. With 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=SARIF" \
-F "file=@semgrep.sarif" \
-F "product_name=orders-service" \
-F "engagement_name=CI" \
-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 "SARIF" \
--report-path "./semgrep.sarif" \
--product-name "orders-service" \
--engagement-name "CI" \
--auto-create-context
3. Reimport one tool per Test. Send each tool's later SARIF files to /api/v2/reimport-scan/ against that tool's Test. If a file holds several runs, DefectDojo aggregates their findings into a single Test, so keep one tool per file.
Data Granularity: What Gets Imported
Only results whose kind is fail (the default when absent) are imported. A result with several locations becomes one Finding per location.
| DefectDojo Field | Source in SARIF | Notes |
|---|---|---|
| Title | result.message |
Falls back to rule short or full description, name, or ID; shortened to 150 characters |
| Severity | level or rule security-severity |
note to Info, warning to Medium, error to High, otherwise Medium; a numeric security-severity maps by CVSS bands and wins |
| Description | Message, snippet, rule text, code flows | Rule descriptions are skipped when they repeat the message |
| File Path / Line | physicalLocation |
artifactLocation.uri and region.startLine |
| Vuln ID from Tool | ruleId |
A CVE in the rule ID also becomes a vulnerability ID |
| CWE | Rule relationships, properties, tags, taxa | All CWEs stored; one chosen as primary |
| CVSS v3 Score | Rule security-severity |
When numeric |
| Mitigation | fixes[].description |
When the tool supplies fixes |
| References | Rule helpUri |
Or help text if it is a URL |
| Tags | Rule and result properties.tags |
external/cwe/ prefix removed |
| Date | Last invocation endTimeUtc |
When present |
| Unique ID from Tool | fingerprints or partialFingerprints |
Dropped if the same ID repeats within one report |
| Active / False Positive | suppressions |
Suppressed results import inactive and false positive |
| Finding type | Static | All SARIF Findings are static |
| Deduplication | Unique ID or hashcode | Fallback hash of title, CWE, line, file path, description |
Use Cases
Onboarding a new tool quickly: A team adds a language-specific linter that has no dedicated DefectDojo parser but writes SARIF. Its results are imported the same week under their own Test Type, with the same triage and SLA workflow as everything else.
Standardizing a multi-tool pipeline: A platform team runs CodeQL, Semgrep, and Gitleaks on 50 repositories, all emitting SARIF. Each tool gets its own Test per repository, and one import step in the shared CI template handles all three.
Bringing code scanning results together: Teams already producing SARIF for GitHub code scanning reuse the same files for DefectDojo, so code findings appear next to SCA, container, and DAST results for the same Asset.
Preserving suppression decisions: When developers suppress results in code with a justification, the SARIF suppression arrives in DefectDojo as a false positive, keeping the decision visible to the security team.
Operational Tips
- Check whether your tool writes fingerprints. Fingerprinted results deduplicate on their ID even when lines shift; without them, the fallback hash includes line and description, so edits can produce new Findings.
- Keep tool names stable. The Test Type comes from
tool.driver.name, and a tool that changes its name between versions will create a new Test Type that won't match on reimport. - Some tools report every result as
warning, which imports as Medium. Where the tool providessecurity-severity, DefectDojo uses it instead, so prefer tool settings that include it. - Watch for multi-location results. A single result with five locations becomes five Findings, which is accurate but can inflate counts.
- Some tools write non-security results (style, complexity) into SARIF. Filter them in the tool's configuration or use
minimum_severityto keep Info results out. - In DefectDojo Pro, deduplication for SARIF can be tuned under Settings, Finding Workflow, Matching Configuration. In Community Edition, use
DD_DEDUPLICATION_ALGORITHM_PER_PARSERandDD_HASHCODE_FIELDS_PER_SCANNER.