All integrations

OWASP Dependency Check Integration with DefectDojo

OWASP Dependency Check Integration with DefectDojo

OWASP Dependency-Check is an open source software composition analysis (SCA) tool, created by Jeremy Long and maintained as an OWASP project. It inspects a project's dependencies, identifies them through evidence such as package URLs and CPE identifiers, and matches them against vulnerability data from the NVD and other sources. It is strongest in the Java ecosystem, with Maven, Gradle, Ant, and Jenkins integrations and a command-line tool, and it also analyzes .NET assemblies, npm and other JavaScript packages, and several other ecosystems. Reports can be written in formats including HTML, JSON, and XML; DefectDojo imports the XML report.

OWASP Dependency Check Integration with DefectDojo

We run OWASP Dependency-Check in our builds because it is free, runs anywhere a JVM runs, and plugs into the build tools our Java teams already use. DefectDojo is where its results become a managed backlog. Each vulnerable library becomes a Finding with its component name and version, CVE, CVSS-based severity, and a plain instruction to upgrade, attached to the Asset that owns the build. Suppressions our developers maintain in Dependency-Check carry over as mitigated findings with their justification, so we can audit them instead of wondering why a CVE vanished from the report.

Why OWASP Dependency Check Matters

Most application code is third-party code, and a single outdated library can expose an otherwise well-written service.

  • It identifies dependencies from the artifacts themselves, which catches libraries that don't appear in a manifest, such as shaded or bundled jars.
  • Matches link to CVEs and CWEs with CVSS data, so severity is grounded in public scoring.
  • Its suppression file lets teams document false positives and accepted risks in version control.
  • It fits into Maven, Gradle, Ant, Jenkins, or a plain CLI, so adoption doesn't require a new platform.
  • Its reports describe one build. Without tracking, nobody can say whether a CVE is new this sprint or has been ignored for a year.

Advantages of This Integration

What we gained by importing Dependency-Check results into DefectDojo:

  • Deduplication by library and file. DefectDojo hashes these findings on title, CWE, and file path, and the title combines the component, version, and vulnerability name, so rebuilds don't duplicate findings.
  • Suppressions become auditable. Suppressed vulnerabilities are imported as mitigated and inactive, tagged suppressed, with the suppression notes in the mitigation. A suppression without notes is also tagged no_suppression_document.
  • Less noise from bundled artifacts. One finding is created per vulnerability per main dependency, and related dependencies that Dependency-Check bundled together are listed in the description instead of becoming separate findings.
  • A lifecycle per build. Reimporting into the same Test mitigates findings for upgraded libraries and adds newly disclosed CVEs.
  • SLAs on real severity. When a CVSSv3 block is present, severity is computed from the vector, so SLA timing follows the published score.

How This Integration Works

DefectDojo imports Dependency-Check output with the Dependency Check Scan scan type, which reads the XML report.

1. Generate an XML report. With the command-line tool:

dependency-check.sh --project "payments-api" --scan ./ --format XML --out ./reports --nvdApiKey "$NVD_API_KEY"

This writes dependency-check-report.xml to the output directory. Since version 9.0.0 Dependency-Check uses the NVD API, and its maintainers strongly recommend an API key because updates without one are very slow. The Maven and Gradle plugins can produce the same XML format through their own format settings.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Dependency Check Scan, and upload the XML. To automate it, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Dependency Check Scan" \
  -F "file=@reports/dependency-check-report.xml" \
  -F "product_name=payments-api" \
  -F "engagement_name=SCA" \
  -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 "Dependency Check Scan" \
  --report-path "./reports/dependency-check-report.xml" \
  --product-name "payments-api" \
  --engagement-name "SCA" \
  --auto-create-context

3. Reimport on every build. Send later reports to /api/v2/reimport-scan/ for the same Test so upgrades close findings and new CVEs appear as new.

Data Granularity: What Gets Imported

DefectDojo Field Source in Dependency-Check XML Notes
Title Component, version, vulnerability name name:version, a pipe character, then the vulnerability name
Severity cvssV3, cvssV2, or severity CVSSv3 vector score first, then CVSSv2 severity, then the raw value. Unrecognized values become Medium
CVSS v3 cvssV3 elements Vector and score rebuilt from the report
Description Vulnerability description, source, file path Related dependency paths appended when bundled
Mitigation Generated "Update component:version to at least the version recommended in the description" plus suppression notes
References references Source, URL, and name for each reference
CWE cwes / cwe First numeric CWE; falls back to 1035 (Vulnerable Third Party Component)
Vulnerability IDs name Set when the name begins with a CVE ID
Component Name / Version Package URL, CPE, Maven ID, or evidence Falls back to the dependency file name
File Path Dependency fileName The jar or package file
Status / Tags suppressedVulnerability Mitigated, inactive, tagged suppressed
Date projectInfo/reportDate Applied to every finding
Finding type Static All findings are static
Deduplication Hashcode Title, CWE, file path

Within one report, findings with the same title, CWE, and file path are imported once.

Use Cases

In a Maven or Gradle build: The Dependency-Check plugin runs during CI and the XML is reimported into a Test per service. Developers see new CVEs introduced by a dependency bump, and upgrades show up as mitigations.

Auditing suppressions: Because suppressed vulnerabilities arrive tagged and mitigated, a security lead can filter on the no_suppression_document tag and follow up on suppressions nobody explained.

Across a Java portfolio: Teams running Dependency-Check in dozens of services import each into its own Asset. Searching a CVE ID in DefectDojo shows every service still on the affected library version.

Release readiness: A release pipeline queries DefectDojo for active Critical and High Dependency-Check findings on the Asset, while risk-accepted findings with expiration dates stay out of the gate.

Operational Tips

  • Use an NVD API key and cache the Dependency-Check data directory in CI. Slow or rate-limited updates lead to stale results and long builds.
  • Keep your suppression file in version control and require notes on each entry. DefectDojo tags suppressions without notes, which makes gaps easy to find.
  • Watch for findings whose component name is a file name. That means Dependency-Check had no package URL, CPE, or Maven identifier, and those findings deserve a closer look for false positives.
  • Reimport into a stable Test per build target rather than creating a new Test each run.
  • Set minimum_severity on import if Low and Info findings add noise to the queue for a large legacy codebase.
  • DefectDojo Pro's connector catalog covers OWASP Dependency-Track, which is a separate project. Dependency-Check results come in through file import.