OSS Review Toolkit (ORT) Integration with DefectDojo

OSS Review Toolkit (ORT) Integration with DefectDojo

The OSS Review Toolkit (ORT) is an open source suite for automating open source compliance, developed on GitHub under the oss-review-toolkit organization. It runs as a pipeline of tools: the analyzer resolves a project's dependencies across many package managers, the scanner detects licenses and copyrights in source code, the advisor looks up known vulnerabilities, the evaluator applies policy rules you write, and the reporter produces outputs such as SBOMs, notices, and a web app report. DefectDojo imports the reporter's EvaluatedModel output, a JSON file that contains the packages, dependency trees, licenses, and rule violations of an evaluated project.

OSS Review Toolkit (ORT) Integration with DefectDojo

We adopted ORT because our legal and engineering teams needed one enforceable policy for which licenses we can ship, and ORT lets us write that policy as rules. The rule violations it produces are real work: a copyleft dependency in a distributed product, a package with no declared license, a component our policy forbids. Importing the evaluated model into DefectDojo turns each unresolved violation into a Finding on the Asset for that product, with the root project, package, license, and how-to-fix text, so it gets an owner and a deadline like any security issue.

Why OSS Review Toolkit (ORT) Matters

Open source license obligations follow every dependency, including transitive ones nobody chose directly. Manual review doesn't keep up with modern dependency trees.

• ORT resolves dependencies across many ecosystems in one run, so a polyglot product gets one consistent view.
• Policy is code. Rules in the evaluator encode what your organization allows, and every violation comes with the rule name and a message explaining it.
• Resolutions let reviewers record approved exceptions so the same violation doesn't resurface after it has been reviewed.
• Without a tracking system, violations are entries in a report. Nobody is assigned, and there is no record of when they were addressed.

Advantages of This Integration

What we gained by sending ORT results through DefectDojo:

• Only unresolved violations imported. The parser skips any rule violation that carries resolutions, so decisions already made in ORT are respected.
• Context for each violation. The description lists the root projects that pull in the package, the license and where it was found, the package ID, the rule message, and ORT's how-to-fix guidance.
• Severity from the rule. ORT's ERROR, WARNING, and HINT levels map to High, Medium, and Info, so policy severity drives SLAs.
• One finding per rule and message. Repeated violations with the same rule and message are merged within a report.
• Compliance next to security. License and policy violations sit on the same Asset as vulnerability findings, and can be assigned, risk-accepted, or pushed to Jira.

How This Integration Works

DefectDojo imports ORT output with the ORT evaluated model Importer scan type. The file is JSON, even though the scan type's description text in DefectDojo refers to an XML scan.

1. Run the ORT pipeline through evaluation. Analyze the project, optionally scan and run the advisor, then run ort evaluate with your rules file. The evaluator writes evaluation-result.yml.

2. Produce the EvaluatedModel report. Run the reporter with the EvaluatedModel format:

ort report -f EvaluatedModel -i ./ort-out/evaluation-result.yml -o ./ort-out/reports

Import the JSON file the reporter writes.

3. Import it. In the UI, open the Engagement, choose Import Scan Results, select ORT evaluated model Importer, and upload the file. For automation, use 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=ORT evaluated model Importer" \
  -F "file=@evaluated-model.json" \
  -F "product_name=mobile-sdk" \
  -F "engagement_name=License Compliance" \
  -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 "ORT evaluated model Importer" \
  --report-path "./evaluated-model.json" \
  --product-name "mobile-sdk" \
  --engagement-name "License Compliance" \
  --auto-create-context

4. Reimport per build. Reimport later evaluated models into the same Test so violations fixed by upgrading or replacing a dependency are mitigated.

Data Granularity: What Gets Imported

Within one file, violations are keyed by rule and message, so duplicates collapse into one finding. The parser imports rule violations only. Advisor vulnerabilities and scanner results in the evaluated model are not imported unless your rules turn them into violations.

Use Cases

For distributed software: A team shipping an SDK or mobile app runs ORT on every release branch. Copyleft and unknown-license violations land in DefectDojo, are assigned to the component owner, and must be fixed or resolved before release.

For policy rollout: When legal tightens the allowed license list, the new rules produce violations across many products at once. DefectDojo shows the count per Asset and tracks the cleanup against SLAs.

For acquisitions and audits: Importing ORT results for an acquired codebase gives the review team a list of license issues with owners and status, instead of a static report.

Alongside SCA vulnerability scanning: With license violations and dependency CVEs on the same Asset, teams can plan a single upgrade that addresses both.

Operational Tips

• Record approved exceptions as ORT resolutions rather than closing findings in DefectDojo. Resolved violations are not imported, so the decision stays in your policy repository.
• Check severities in your rules. Any severity other than ERROR, WARNING, or HINT is imported as Critical.
• Write useful how-to-fix text in your rules. It flows into every finding's description and is the main remediation guidance developers see.
• Use one Test per product and reimport per build, so a dependency upgrade that removes a violation shows up as a mitigation.
• Keep the Engagement name tied to the policy version you evaluated against (for example License Policy 2026-Q4) so you can tell which rule set produced a finding.
• Add your own vulnerability scanner if you need CVE tracking. This parser does not carry ORT advisor results into DefectDojo.