What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Maintenance status and long term support plans: confirm with the project before recommending for new adoption
- Which ecosystem analyzers are still marked experimental: verify against current documentation
- NVD data access requirements and API key handling: confirm current guidance
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Dependency-Check works by evidence collection rather than manifest parsing. For each file it examines, it pulls candidate vendor, product and version strings from wherever they appear: jar manifests, POM metadata, assembly attributes, file names, embedded package descriptors. It scores that evidence, builds candidate Common Platform Enumeration identifiers, and then queries a local copy of the National Vulnerability Database for CVEs recorded against those CPEs. Results are grouped by dependency with the evidence that produced the match shown alongside, so you can see why it made the call.
That design is the whole story, good and bad. Because it reasons about artifacts rather than declared dependency trees, it can identify a jar copied into a lib directory with no build metadata at all. Because CPE strings are assigned inconsistently across the NVD, it also mismatches similarly named products and misses entries whose CPE data is incomplete. Analyzers for Java and .NET are the most developed. Support for Node, Python, Ruby, PHP, Go and Swift has historically been less complete, and some analyzers need the ecosystem's own tooling present to resolve transitive dependencies.
Where it fits
Most teams run it as a Maven or Gradle plugin bound to the build, or as a Jenkins step, so the scan happens where the dependencies are already resolved. It needs a local NVD mirror, and keeping that mirror current is an operational detail that bites people: the initial download is slow, updates are rate limited, and a stale database silently produces stale results. Budget for a shared cache in CI rather than re-downloading per job.
Strengths
- No server component and nothing to procure, which makes it the usual starting point for teams without a commercial SCA tool.
- Evidence based identification finds artifacts copied in without build metadata.
- Mature Maven, Gradle, Ant and Jenkins integrations that slot into existing Java builds with little work.
- Reports show the evidence behind each match, so disputed findings can be reasoned about rather than accepted.
Limitations
- CPE matching produces both false positives on similar product names and false negatives where NVD CPE data is missing. Suppression file maintenance becomes a recurring chore.
- It reads NVD only, so ecosystem advisories that never receive a CVE, which is a large share of npm and Python issues, are invisible to it.
- NVD data synchronization is fragile and slow, and a misconfigured mirror degrades results without an obvious error.
Who it suits
Java and .NET teams who need credible dependency scanning in the build with no procurement, and who accept the suppression file work. Teams centered on npm, Python or Go will get better coverage from a scanner backed by ecosystem advisory data.
Used OWASP Dependency-Check? Recommend it under your own name and title.
Recommend this tool