All integrations

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.name and creates a Test Type named {tool} (SARIF), such as semgrep (SARIF) or Trivy Scan (SARIF).
  • Fingerprint-based deduplication. SARIF uses the Unique ID From Tool or Hash Code algorithm: results with fingerprints or partialFingerprints are matched on that ID, and others fall back to a hash.
  • Suppressions respected. Results with a suppressions entry 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 provides security-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_severity to 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_PARSER and DD_HASHCODE_FIELDS_PER_SCANNER.