OWASP Dependency Track Integration with DefectDojo

OWASP Dependency-Track Integration with DefectDojo

OWASP Dependency-Track is an open source component analysis platform maintained under the OWASP Foundation. It ingests Software Bills of Materials (SBOMs), most commonly in CycloneDX format, keeps an inventory of every component in every project, and continuously matches those components against vulnerability sources such as the NVD, GitHub Advisories, and OSV. Its findings can be exported in Dependency-Track's own JSON Finding Packaging Format (FPF), and Dependency-Track ships a built-in integration that publishes findings to DefectDojo on a schedule.

OWASP Dependency-Track Integration with DefectDojo

We use OWASP Dependency-Track because it keeps watching our SBOMs after the build finishes. A component that was clean last month can pick up a CVE today, and Dependency-Track notices. DefectDojo is where those findings become owned work: each vulnerable component lands on the right Asset, merges with what other SCA tools report, and runs against our SLA clock. Dependency-Track can push to DefectDojo on its own, so once a project is mapped to an Engagement, new component vulnerabilities arrive without anyone exporting a file. DefectDojo Pro adds a third path: a Dependency-Track connector that pulls from our on-premise instance over its REST API.

Why OWASP Dependency-Track Matters

Most application code is third-party code, and the list of known vulnerabilities in it changes daily.

• Dependency-Track works from SBOMs, so it covers whatever your build tooling can describe, across languages and ecosystems.
• It reevaluates stored SBOMs as new advisories are published, which catches vulnerabilities disclosed after a release shipped.
• Audit decisions made in Dependency-Track, such as marking a finding as a false positive, travel with the export.
• On its own it tracks components per project. It doesn't hold the SAST, DAST, and infrastructure findings for the same application, which is where DefectDojo fills the gap.

Advantages of This Integration

What we gained by sending Dependency-Track findings through DefectDojo:

• Stable identity across syncs. DefectDojo deduplicates Dependency-Track findings on the unique ID from the export, which combines the project, component, and vulnerability UUIDs. When that is absent it falls back to a hash of component name, component version, and vulnerability IDs.
• Upstream false positives carried over. Findings audited as FALSE_POSITIVE in Dependency-Track arrive marked false positive and inactive, so triage work isn't repeated.
• Aliases kept together. A vulnerability's CVE, GHSA, OSV, Snyk, and other alias IDs are stored as vulnerability IDs on one Finding, so filtering by any of them finds it.
• Lifecycle on reimport. With reimport enabled, each publish updates the same Test: components that were upgraded close, new vulnerabilities open, and returning ones reactivate.
• Pull instead of push on DefectDojo Pro. The Dependency-Track connector is configured inside DefectDojo Pro with a server URL and an API key, so the sync schedule and mapping live on the DefectDojo side.
• Prioritization data. CVSS v3 and v4 scores, EPSS score and percentile, and the advisory publish date are imported, which helps rank findings beyond raw severity.

How This Integration Works

DefectDojo imports Dependency-Track data with the Dependency Track Finding Packaging Format (FPF) Export scan type. Community Edition and DefectDojo Pro both support the first two options; the third is DefectDojo Pro only.

Option 1: Let Dependency-Track push to DefectDojo. Dependency-Track's DefectDojo integration (Dependency-Track 4.1.0 or later) calls the DefectDojo API on a configurable interval.

1. In DefectDojo, create an Asset and a CI/CD Engagement for the project, and note the Engagement ID.
2. In Dependency-Track's global configuration, enable the DefectDojo integration and enter the DefectDojo URL and an API key. Optionally enable reimport for all projects.
3. On each Dependency-Track project, add the property defectdojo.engagementId (group integrations, type STRING) with the Engagement ID.
4. Optionally add defectdojo.reimport set to true so findings go into one existing Test instead of a new Test each cycle. defectdojo.doNotReactivate keeps findings closed in DefectDojo closed, and defectdojo.testTitle names the Test.

Option 2: Export FPF and import it. Dependency-Track exposes the FPF document at /api/v1/finding/project/{uuid}/export, which requires the VIEW_VULNERABILITY permission. Request it with a Dependency-Track API key for the project's UUID and save the response as dtrack-findings.json.

Then upload the JSON in the UI (Import Scan Results, then select the scan type) or send it to the DefectDojo API, which works the same in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/reimport-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Dependency Track Finding Packaging Format (FPF) Export" \
  -F "file=@dtrack-findings.json" \
  -F "product_name=storefront" \
  -F "engagement_name=SBOM Monitoring" \
  -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 Track Finding Packaging Format (FPF) Export" \
  --report-path "./dtrack-findings.json" \
  --product-name "storefront" \
  --engagement-name "SBOM Monitoring" \
  --auto-create-context

An export with an empty or missing findings list imports cleanly with zero findings.

Option 3: Dependency-Track connector (DefectDojo Pro). The connector fetches data from an on-premise Dependency-Track instance through its REST API. In the DefectDojo Pro connector settings:

• Location: your Dependency-Track server URL.
• Secret: a Dependency-Track API key.

To create the key, go to Administration > Access Management > Teams in Dependency-Track, create or select a team, and generate a key in its API Keys section. Give the team the VIEW_PORTFOLIO and VIEW_VULNERABILITY permissions so the connector can read projects and their vulnerabilities.

Data Granularity: What Gets Imported

Use Cases

Continuous SBOM monitoring: Each release uploads its CycloneDX SBOM to Dependency-Track, and the project's defectdojo.engagementId property points at a long-lived Engagement. When a new advisory affects a component already in production, the next scheduled push opens a Finding in DefectDojo without a new build.

In a CI/CD pipeline: Teams that prefer explicit control export FPF after the SBOM is analyzed and reimport it from the pipeline. A release gate can query DefectDojo for active Critical findings on the Asset before promotion.

Consolidating SCA tools: An organization running Dependency-Track alongside another SCA scanner sees both tools' component findings on one Asset, with SLAs and reporting applied the same way, instead of reconciling two dashboards.

Audit trail for third-party risk: Discovery dates, false positive decisions, risk acceptances, and closure dates live on each Finding, which answers questions about how long a known vulnerable component stayed in use.

Operational Tips

• Turn on reimport (defectdojo.reimport or the global setting). Without it, every publish creates a new Test, and you lose the clean open-to-mitigated history.
• Use defectdojo.doNotReactivate only if DefectDojo is your source of truth for closure. Dependency-Track's docs warn that a reintroduced vulnerability, for example after a library downgrade, will then not reactivate automatically.
• Do false positive analysis in one place. Dependency-Track's FALSE_POSITIVE state comes across; its other analysis states are not used by the parser.
• Expect Info-level findings for vulnerabilities Dependency-Track rates INFO or leaves unassigned. Set minimum_severity on API imports if that noise isn't useful.
• Findings default to CWE-1035 (vulnerable third-party component) when Dependency-Track has no CWE, which keeps them grouped correctly in CWE-based reports.
• Choose one delivery path per instance. Running the built-in push and the DefectDojo Pro connector against the same projects duplicates the work of keeping two mappings correct.
• For the connector, create a dedicated Dependency-Track team holding only VIEW_PORTFOLIO and VIEW_VULNERABILITY, so its API key can read but not change anything.
• Map one Dependency-Track project to one DefectDojo Engagement, and keep project versions in separate Tests or Engagements if you track several releases at once.