OWASP Dependency-Check: CPE Matching for Java and Polyglot Builds

What Dependency-Check Actually Answers

The README states the goal plainly: Dependency-Check is a Software Composition Analysis tool that attempts to detect publicly disclosed vulnerabilities contained within a project's dependencies. The mechanism is identification, not resolution. For a given dependency it tries to determine whether a Common Platform Enumeration identifier exists, and when one does, it generates a report linking to the associated CVE entries.

That framing matters when you pick a tool. Dependency-Check does not ask your package manager what the full transitive graph looks like and then query a vulnerability database by package coordinates. It looks at the artifacts it can find, guesses what product and version they are, and matches that guess against CPE data. The audience is therefore teams with an existing build: the repository ships integrations for Maven, Gradle, Ant and Jenkins, plus a command line client, and the topics list names all of them. If your project has no build tool that Dependency-Check understands, you are working against its grain.

CPE Matching and Why False Positives Follow

The core loop is CPE-centric. A dependency is fingerprinted, a CPE candidate is proposed, and the CVE entries attached to that CPE become findings. This is why the project can cover stacks that have no central vulnerability feed of their own, and also why the same design produces false positives: an identifier match is a claim about what a file is, not proof that the vulnerable code path is reachable or even present in the way you use it.

A second layer exists. The README notes that without credentials Dependency-Check will automatically disable the OSS Index analyzer, which means one of the supplementary analyzers is opt-in by configuration rather than on by default. Sonatype OSS Index began enforcing API tokens in September 2025, and the README describes a migration to Sonatype Guide that started in April 2026, with Guide API Tokens planned to replace legacy OSS Index keys before the end of 2026. That is a moving dependency on a commercial service whose usage model the README says has changed. Teams that relied on OSS Index results should treat that analyzer as something to re-verify, not as a stable baseline.

Analysis of non-Java ecosystems leans on external tools rather than reimplementing them. The README lists the requirements: dotnet 8 runtime or SDK for .NET assemblies, go for GoLang, mix_audit for Elixir, npm, pnpm or yarn for those package managers, and bundle-audit for Ruby. Some of that analysis may be experimental and require the experimental analyzers to be enabled. In practice that means your scanner image needs those toolchains installed, or those ecosystems simply go unanalyzed.

Installing the CLI and Running a First Scan

The README points at the GitHub releases section for the latest CLI, and at the project's GitHub Pages for more detailed instructions. The Dockerfile in the repository shows what the official image expects: it is built from a Zulu OpenJDK base, copies a jlinked runtime to /opt/jdk, adds the CLI release zip under /usr/share/, and sets JAVA_OPTS to point the .NET, bundle-audit and Go analyzers at /usr/bin/dotnet, /usr/bin/bundle-audit and /usr/local/go/bin/go respectively. Those paths are the ones the image configures; a local install will not have them unless you install those tools.

Before any scan, get an NVD API key. The README is explicit that users are highly encouraged to obtain one, that updates without a key will be extremely slow, and it links to the NVD request page. The README does not document the exact flag name for supplying the key, so check the CLI documentation page rather than guessing.

The README's version history explains one upgrade trap. Version 11.0.0 changed the local H2 database format, so a shared data directory is not compatible with older versions and a full NVD download occurs. The documented purge commands are:

./gradlew dependencyCheckPurge
mvn org.owasp:dependency-check-maven:11.0.0:purge
dependency-check.sh --purge

For Gradle builds, the README gives a concrete fix for NoSuchMethodError failures caused by transitive dependency resolution, using constraints in /buildSrc/build.gradle:

dependencies {
    constraints {
        add("implementation", "com.fasterxml.jackson:jackson-bom:2.21.2")
        add("implementation", "org.apache.commons:commons-lang3:3.20.0")
        add("implementation", "org.apache.commons:commons-text:1.15.0")
    }
}

Minimum Java version to run version 11.0.0 or higher is Java 11, per the README.

The NVD API Key and CI Rate Limits

This is the operational constraint that decides whether Dependency-Check is pleasant or painful. Since 9.0.0 the project moved from the NVD data feed to the NVD API. That API enforces rate limits, and the README warns that a single API key used across multiple builds can hit the limit and return 403 errors. The prescribed answer for a CI environment is a caching strategy.

Read that as an architectural requirement rather than a tip. A shared data directory, cached between pipeline runs, is what keeps update time bounded; without it every job re-downloads NVD data. The README does not document rollback of the data directory, and it does not describe a supported way to run with a stale database indefinitely, so plan for a cache volume and a periodic refresh rather than a per-job download.

Version 12.1.0 or higher is mandatory because of NVD API compatibility changes, per the README's notice. If you are pinning an older release for reproducibility, that pin is now a correctness problem, not just a staleness one.

Where Dependency-Check Is the Wrong Tool

The clearest boundary is the build-tool assumption. If you want to scan a container image or a directory of binaries with no project metadata, Dependency-Check's analyzers are organized around project types and build integrations. The Jenkins, Maven, Gradle and Ant plugins exist precisely because the tool expects to be embedded in a build.

Second, the CPE matching model trades precision for coverage. A finding means an identifier matched, and the README never claims reachability analysis. If your team cannot absorb triage work on false positives, or if findings are wired directly into a blocking gate with no suppression path, the tool will generate noise that someone has to own.

Third, the Sonatype dependency is a real external risk. The README states that without credentials the OSS Index analyzer is automatically disabled, and that the migration to Sonatype Guide involves a changed commercial and usage model. A team that adopted Dependency-Check specifically for OSS Index coverage now has a configuration and licensing question, not just a version bump.

Finally, the ecosystem analyzers are wrappers. Ruby analysis is a wrapper around bundle-audit, and npm, pnpm and yarn analysis use each tool's audit feature. If those tools are not installed in your scan environment, the corresponding analysis does not happen, and nothing in the README suggests Dependency-Check substitutes for them.

Dependency-Check Versus Dependency-Track and Trivy

Dependency-Track is the comparison people search for most, and the difference in approach is structural. Dependency-Check is a scanner that runs inside a build or from a CLI and produces a report. Dependency-Track is a server that consumes software bill of materials data and tracks components over time. The practical consequence: Dependency-Check answers what a specific build contains right now, while a platform-style tool answers what your organization is running across many projects and how that changes between releases. If you need per-project results in the pipeline, Dependency-Check fits. If you need a portfolio view, a scanner report is the input to that, not the thing itself.

Trivy starts from artifacts and container images rather than from build-tool integration, which is the inverse trade-off. A team whose primary unit of deployment is an image will find an image-oriented scanner shorter to wire up. A team whose primary unit is a Maven or Gradle module gets more from Dependency-Check because the plugin already knows where the dependencies are.

Neither comparison makes one tool wrong. They differ in where the dependency list comes from and where the results live.

Licence, Maintenance and Upgrade Cost

Dependency-Check is licensed under Apache-2.0, and the repository carries LICENSE.txt and NOTICE.txt at the top level. Apache-2.0 permits commercial use and modification, but this is not legal advice; the NOTICE file and the NVD disclaimer in the README (the product uses the NVD API but is not endorsed or certified by the NVD) are the parts a compliance reviewer will want to read alongside the licence text.

The repository is not archived, and the last push was on 2026-09-21, one day before this article. Recent releases are v13.0.0 on 2026-08-03, v12.2.2 on 2026-05-03 and v12.2.1 on 2026-04-11. The release cadence is real, and so is the upgrade cost: the README documents an H2 database format change in 11.0.0 that forces a full NVD download and breaks shared data directories, and a mandatory NVD API compatibility upgrade at 12.1.0. Two breaking infrastructure changes inside a major version series is the pattern to budget for.

Editorial conclusion

Adopt Dependency-Check if your build is already Maven, Gradle, Ant or Jenkins based and you can hold a shared NVD data directory plus an API key. Do not adopt it if you expect a scanner that resolves dependency trees without a build tool, or if your CI cannot cache the NVD database. Before rolling it out, verify the CLI or plugin version you install is at least 12.1.0, and confirm that your Sonatype Guide or legacy OSS Index credential is configured, because without credentials the OSS Index analyzer disables itself silently.

Frequently asked questions

Official sources

1. dependency-check/DependencyCheck on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases