OSV Scanner Integration with DefectDojo

OSV Scanner Integration with DefectDojo

OSV-Scanner is an open source dependency scanner from Google, written in Go. It reads lockfiles and other dependency manifests in a project, then checks each package version against the OSV.dev database, which aggregates advisories from sources such as the GitHub Advisory Database, PyPI, Go, RustSec, and Linux distributions. Results can be printed as a table or written in machine-readable formats including JSON, which is the format DefectDojo imports.

OSV Scanner Integration with DefectDojo

We picked OSV-Scanner because it is free, fast, and covers most of the ecosystems in our repositories with one binary. DefectDojo is what makes its output usable over time. Each advisory in the JSON report becomes a Finding on the right Asset, with the fixed versions written into the Mitigation field. Rescans are deduplicated against what we already know, and reimporting after an upgrade closes the Findings that were fixed. Engineers get a backlog with owners and SLAs instead of a terminal table that scrolls away.

Why OSV Scanner Matters

Dependency risk changes even when your code doesn't, because new advisories are published against versions you already ship.

• OSV.dev uses a single open schema across ecosystems, so npm, PyPI, Go, Maven, crates.io, RubyGems, and others report in the same shape.
• The scanner works from lockfiles, which reflect the versions actually resolved, including transitive dependencies.
• Advisories in OSV format include affected version ranges and fix events, which tells you the exact version that resolves the issue.
• It is easy to run in CI with no account or server, which makes it a common first SCA tool for teams that don't yet have one.
• A JSON report has no memory of past runs. Without a platform behind it, nobody can tell whether an advisory is new or has been open for months.

Advantages of This Integration

What we get from routing OSV-Scanner results through DefectDojo:

• Deduplication across runs. OSV Scan findings hash on title, description, and severity, so the same advisory against the same package isn't duplicated every time the pipeline runs.
• Fix versions on the Finding. The parser collects every "fixed" event from the advisory's affected ranges and writes them into Mitigation, grouped by range type. Git ranges become commit URLs.
• Reimport lifecycle. Reimporting into the same Test mitigates advisories that disappeared after an upgrade, adds new ones, and reactivates any that come back.
• CWE data. Where the advisory carries CWE IDs, the first becomes the Finding's CWE and all of them are stored, which helps CWE-based reporting.
• One process for every SCA tool. OSV Findings get the same SLAs, assignment, risk acceptance, false positive handling, and Jira push as Findings from commercial scanners.

How This Integration Works

DefectDojo imports OSV-Scanner results with the OSV Scan scan type. The parser expects JSON output (--format json).

1. Produce a JSON report. Scan a project directory recursively and redirect the JSON to a file:

osv-scanner scan -r --format json ./ > osv-results.json

To scan a single lockfile instead:

osv-scanner scan --format json -L package-lock.json > osv-results.json

OSV-Scanner writes JSON to stdout and other messages to stderr, so the redirect captures only the report.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select OSV Scan, and upload the file. For automation, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=OSV Scan" \
  -F "file=@osv-results.json" \
  -F "product_name=web-frontend" \
  -F "engagement_name=Dependency Scans" \
  -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 "OSV Scan" \
  --report-path "./osv-results.json" \
  --product-name "web-frontend" \
  --engagement-name "Dependency Scans" \
  --auto-create-context

3. Reimport on each build. Send later reports to /api/v2/reimport-scan/ against the same Test so the Test always reflects the current dependency set.

Data Granularity: What Gets Imported

The parser walks each result (one per scanned source file), each package in it, and each vulnerability on that package. One advisory on one package becomes one Finding.

Use Cases

In a CI/CD pipeline: Each merge runs OSV-Scanner across the repository and reimports into a Test for that repository. Developers see what their change introduced, and a deploy gate can query DefectDojo for active Critical or High Findings.

For a quick SCA baseline: A team without a commercial SCA product runs OSV-Scanner across 50 repositories in one afternoon, imports each into its Asset, and gets an Organization-level view of vulnerable dependencies sorted by severity and owner.

Alongside a commercial scanner: Some teams run OSV-Scanner next to a paid SCA tool to compare coverage. With both in DefectDojo on the same Asset, it's easy to see which advisories only one tool reports.

During upgrade planning: The Mitigation field lists the fixed versions per range, so engineers can tell whether a patch release resolves the advisory or a larger upgrade is needed before they open the lockfile.

Operational Tips

• Check severity on advisories that lack database_specific.severity. They import as Low by default, which can understate real risk. Review those with your own CVSS data or the advisory text before SLAs depend on them.
• The hash doesn't include the package version or lockfile path. The same advisory on the same package in two lockfiles of one Asset can be flagged as a duplicate, which is usually what you want but worth knowing when counting.
• Because the description is part of the hash and includes OSV's advisory text, an upstream edit to an advisory can make a rescan look like a new Finding. Reimport into the same Test to keep matching tidy.
• An unreadable or non-JSON file imports with zero Findings rather than an error. If a pipeline suddenly reports nothing, check that --format json was set.
• Tag imports with the repository or branch (for example tags=web-frontend,main) to filter Findings across many repositories.
• Use minimum_severity to hold back Low Findings during initial rollout, then lower it once the backlog is manageable.