OWASP Dependency-Check

OWASP Dependency-Check is one of the oldest and most widely used open-source SCA tools. As an OWASP Flagship Project, it addresses the OWASP Top 10’s A06:2021 “Vulnerable and Outdated Components” category directly.

With 7.4k GitHub stars, 290+ contributors, and 82+ releases, it has been a go-to free option for identifying known vulnerabilities in project dependencies.

The tool checks your dependencies against the National Vulnerability Database (NVD) using CPE (Common Platform Enumeration) matching. It runs as a CLI tool, Maven plugin, Gradle plugin, Ant task, or Jenkins plugin. The current version is 12.2.1 (April 2025).

What is OWASP Dependency-Check?

Dependency-Check scans project dependencies and matches them against NVD entries to find known CVEs. It supports Java (Maven, Gradle), .NET (NuGet), JavaScript (npm), Python (pip), Ruby (Bundler), and Go modules.

It also pulls data from NPM Audit, Sonatype OSS Index, and RetireJS for additional coverage.

Key features

SBOM output and license scope

Dependency-Check produces HTML, JSON, XML, CSV, SARIF, and JUnit reports. SARIF output imports directly into GitHub’s code-scanning alerts, which is how most GitHub Actions workflows surface findings on pull requests. An experimental CycloneDX report format exists in the engine, but the primary outputs are vulnerability reports rather than signed SBOMs — teams wanting strict SPDX or CycloneDX SBOM workflows pair Dependency-Check with Dependency-Track or Syft.

On licensing: the tool identifies components but does not run the license-compliance workflows that FOSSA or Black Duck specialise in. It will tell you that axios@0.21.0 is in your tree; it will not tell you whether your distribution obligations around its MIT license are met.

Supported ecosystems

NVD integration

Dependency-Check identifies components using CPE matching and correlates them against the NVD. It also pulls data from NPM Audit, Sonatype OSS Index, and RetireJS for additional coverage. Database updates are cached locally for offline scanning.

Build tool plugins

Native plugins for Maven, Gradle, and Ant let you add vulnerability checking directly to your build lifecycle. Set a failBuildOnCVSS threshold to break builds when critical vulnerabilities are found. Community-maintained plugins also exist for SBT and Leiningen.

Suppression files

False positives are managed through XML suppression files. You can suppress by CVE ID, CPE pattern, or component name, keeping reports clean while maintaining an audit trail of suppression decisions.

Report formats

Reports are available in HTML (default, good for manual review), JSON, XML, CSV, SARIF, and JUnit. The SARIF format integrates directly with GitHub’s code scanning alerts. JUnit format works with Jenkins test result dashboards.

Transitive dependencies and what Dependency-Check misses

Dependency-Check resolves transitive dependencies through whichever build-tool plugin is driving the scan. The Maven and Gradle plugins walk the full resolved dependency tree from pom.xml or build.gradle respectively, which means transitive vulnerabilities surface in the same report as direct ones. For the standalone CLI scanning a directory, transitive resolution depends on whether lockfiles (package-lock.json, Gemfile.lock, go.sum) are present.

Two categories of risk sit outside what the tool is designed to catch. CPE-based matching against the NVD does not detect malicious packages — typosquatted packages, compromised maintainer publishes, or install-time scripts that exfiltrate secrets. Tools like Socket and Phylum focus specifically on that behavioural-analysis gap.

The tool also does not produce SBOMs in strict SPDX or CycloneDX form out of the box; the SARIF and JSON outputs are vulnerability reports, not signed bills of material in the sense that Syft or Dependency-Track workflows use the term. Teams that need SBOM-centric workflows usually pair Dependency-Check with Dependency-Track, or swap it for Grype + Syft.

Integrations

Dependency-Check ships native plugins for the two build tools most commonly paired with it — Maven (mvn dependency-check:check) and Gradle (./gradlew dependencyCheckAnalyze) — plus an Ant task for older JVM projects.

CI platforms wire in either through the CLI or dedicated plugins: a community-maintained Jenkins plugin, a GitHub Actions workflow that invokes the CLI, an Azure DevOps Marketplace extension, GitLab CI jobs, and CircleCI orbs. The Docker image at owasp/dependency-check is the standard entry point for self-hosted runners.

For non-JVM ecosystems, the core CLI handles npm (package-lock.json), pip (requirements.txt), Ruby Bundler (Gemfile.lock), .NET NuGet, Go modules, PHP Composer, and Swift CocoaPods directly — no separate plugin needed. Windows users run the same CLI via PowerShell, and the SonarQube plugin imports Dependency-Check output into SonarQube dashboards.

Build Tools

Maven

Gradle

CI/CD

Jenkins

GitHub Actions

Azure DevOps

SonarQube

Getting started

License and pricing posture

Dependency-Check is free. The codebase is Apache 2.0 licensed, hosted at github.com/dependency-check/DependencyCheck, and recognised as an OWASP Flagship Project — the highest OWASP project tier, reserved for mature, widely adopted projects.

There is no commercial edition, no paid tier, no SaaS variant, and no account required to download or run the scanner. OWASP itself does not sell support contracts for the project; the closest thing to paid support is commercial SCA vendors that bundle Dependency-Check output into their own platforms.

That posture makes Dependency-Check materially different from Snyk Open Source, Mend SCA, Black Duck, or JFrog Xray — all of which are commercial products with per-developer pricing or enterprise contracts. Teams that need a free-forever scanner with no vendor relationship choose Dependency-Check for exactly this reason; teams that need a managed vulnerability DB, triage workflows, or SLAs generally reach for one of the commercial SCA tools.

When to use Dependency-Check

Dependency-Check is the right choice for teams that need free, proven SCA scanning with strong build tool integration, especially in Java environments.

The CPE matching approach can produce more false positives than ecosystem-specific scanners like Grype or Trivy. Plan to maintain a suppression file.

The tool also lacks reachability analysis and automated fix PRs that commercial tools provide.

For teams that want free SCA with fewer false positives, Grype or Trivy are worth evaluating. For teams wanting automated remediation, Snyk or Dependabot offer fix pull requests.

How it compares:

For more background, see What is SCA? and our guide on SCA in CI/CD pipelines.

OWASP Dependency-Check alternatives

The closest free alternatives are Grype, Trivy, and Google’s OSV-Scanner. Each trades CPE matching for ecosystem-native package parsing, which generally means fewer false positives but different coverage characteristics.

Grype pairs with Syft-generated SBOMs and matches against the GitHub Security Advisory database plus NVD. Trivy scans container images, filesystems, and git repos and is the de-facto standard inside the CNCF ecosystem. OSV-Scanner reads Google’s OSV database, which aggregates advisories from GitHub, RustSec, PyPA, and several language-specific sources into a single cross-ecosystem feed.

On the commercial side, Snyk Open Source layers reachability analysis and automated fix PRs on top of its own curated vulnerability DB, and Dependabot ships natively inside GitHub with zero configuration. Both trade the self-hosted nature of Dependency-Check for a hosted workflow with vendor-maintained data.

The existing FAQ already answers “How does Dependency-Check compare to Grype or Trivy?” at a high level; this section fills in the full alternatives landscape. For a broader view, see our comparison guides under SCA tools and open-source SCA tools.

Frequently Asked Questions