skip to content

Vulnerability Scanning

OWASP dependency-check against the NVD, CVSS thresholds that fail the build, and suppression files for false positives. Interviewers ask how you keep a scanner useful instead of universally ignored.

on this pageshow

explore

questions

6

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

open as a page

How does failBuildOnCVSS work, and how would you tune it so it is useful rather than just noisy?

level: seniorimportance: must knowfreq 50%

basics

~20 s

failBuildOnCVSS is a number from 0 to 11. If any dependency has a CVE with a CVSS score at or above that value, the build fails. Lower the number to be stricter; raise it to be more lenient.

open as a page

What is the difference between the dependency-check `check` and `aggregate` goals in a multi-module Maven build?

level: middleimportance: should knowfreq 40%

basics

~10 s

check scans each module on its own and produces a report per module. aggregate scans the whole multi-module project together and produces a single combined report at the root.

open as a page

How does versions-maven-plugin help you stay on top of outdated dependencies, and how is it different from a vulnerability scanner?

level: middleimportance: should knowfreq 45%

basics

~10 s

versions-maven-plugin reports newer available versions of your dependencies and plugins (for example with display-dependency-updates) and can update your pom. It only checks for newer versions, not for security vulnerabilities.

open as a page

How do you handle false positives from dependency-check, and what goes into a suppression file?

level: seniorimportance: should knowfreq 35%

basics

~20 s

You write a suppression.xml file listing specific CVEs to ignore for specific dependencies, then point the plugin at it. It tells the scanner that a particular finding is a false positive (or accepted risk) so it stops failing the build.

open as a page

What operational challenges does running dependency-check in CI introduce, and how do you keep the pipeline fast and reliable?

level: principalimportance: should knowfreq 30%

basics

~20 s

The big cost is downloading and updating the NVD database, which is large and slow and can hit rate limits. You fix this by caching the database, using an NVD API key, updating it once centrally, and not re-downloading it in every build.

open as a page