skip to content

What is the OWASP dependency-check-maven plugin, and what problem does it solve in a Maven build?

level: juniorimportance: must knowfreq 65%

answer

  1. org.owasp dependency-check
  2. SCA / supply chain
  3. CVE + NVD + CPE matching
  4. check goal on verify
  5. transitive deps too

basics

~10 s

It is a Maven plugin that scans your project's dependencies for known security vulnerabilities (CVEs) by matching them against a public vulnerability database, and can fail the build if it finds risky libraries.

solid answer

~40 s

OWASP dependency-check-maven (groupId org.owasp, artifactId dependency-check-maven) is a Software Composition Analysis (SCA) tool. It inspects the JARs your project depends on, infers each library's identity (CPE), and matches it against the National Vulnerability Database (NVD) to find known CVEs. You bind its `check` goal to a build phase (commonly `verify`); it produces an HTML/JSON/XML report and can break the build via `failBuildOnCVSS`. It solves the supply-chain problem: your code may be clean, but a transitive dependency can carry a critical vulnerability (e.g. Log4Shell). Automating the scan in CI gives you a repeatable gate so vulnerable libraries are caught before release rather than in production.

code

bash · 3 lines
bash
# Run a one-off scan from the command line (no pom config needed)
mvn org.owasp:dependency-check-maven:check
# Report lands in target/dependency-check-report.html

go deeper

for a junior

Know it scans dependency JARs for known CVEs and can fail the build.

for a middle

Know the goals, the verify-phase binding, and that NVD/CPE matching drives results.

for a senior

Discuss false positives/negatives from CPE guessing, NVD data freshness, and CI integration cost.

for a principal

Position it within a broader supply-chain strategy: SBOM, signing, internal mirrors, and policy governance across many repos.

## The problem: supply-chain risk Modern Java apps pull in dozens or hundreds of third-party libraries, mostly **transitive** (dependencies of your dependencies). Any one of them can contain a publicly disclosed security flaw. Your own code can be perfect and you can still ship a critical vulnerability inside a JAR you never explicitly chose. The infamous **Log4Shell** (CVE-2021-44228 in log4j-core) is the canonical example. ## What the plugin is **OWASP dependency-check** is a free **Software Composition Analysis (SCA)** tool. The Maven integration is the plugin: - groupId: `org.owasp` - artifactId: `dependency-check-maven` ## Key vocabulary - **CVE** (Common Vulnerabilities and Exposures): a unique ID for a publicly known flaw, e.g. `CVE-2021-44228`. - **NVD** (National Vulnerability Database): the U.S. government feed that catalogs CVEs and assigns severity. - **CPE** (Common Platform Enumeration): a standardized name for a product/version. The plugin guesses each JAR's CPE from its metadata (group, artifact, version, manifest, embedded pom) and then looks up CVEs tied to that CPE. - **CVSS** (Common Vulnerability Scoring System): a 0.0–10.0 severity score. Roughly: 9.0+ critical, 7.0–8.9 high, 4.0–6.9 medium. ## How it runs The main goal is `dependency-check:check`. You typically bind it to the `verify` phase so it runs during `mvn verify` or `mvn install`. It downloads/updates a local copy of the NVD data, evidences each dependency, matches CVEs, and writes a report (default `target/dependency-check-report.html`). ```xml <plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>9.2.0</version> <executions> <execution> <goals><goal>check</goal></goals> </execution> </executions> </plugin> ``` ## Why automate it Running it manually is unreliable. Binding it to a phase and running it in CI makes vulnerability scanning a **repeatable gate**: the build itself refuses to pass when a dependency crosses your risk threshold. That shifts detection left — before release instead of after an incident.

  • Does it scan transitive dependencies or only direct ones?
    Both. It walks the full resolved dependency graph, which is the whole point — most real vulnerabilities arrive transitively.
  • Where does the vulnerability data come from?
    Primarily the NVD (National Vulnerability Database). The plugin downloads and caches it locally; newer versions also use the NVD API and may need an API key.

Like a customs scanner for your shipping containers: you trust your own cargo, but it checks every box (including ones nested inside others) against a watchlist before the truck leaves.

saying these in an interview costs you the question

  • Saying it scans your own source code for bugs — it does SCA on dependencies, not SAST on your code.
  • Claiming it only checks direct dependencies.
  • Thinking it guarantees you are vulnerability-free — it only finds publicly known CVEs that match a recognizable CPE.

context

resolving links…