skip to content

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

level: seniorimportance: must knowfreq 50%

answer

  1. 0–11 threshold, default 11 = never
  2. 7 = high+critical, 9 = critical only
  3. CVSS 9+ critical / 7+ high
  4. ratchet down over time
  5. pair with suppression.xml + scope skips

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.

solid answer

~40 s

`failBuildOnCVSS` sets the severity threshold at which the `check`/`aggregate` goal fails the build. It takes a value 0–11 (default 11, which effectively never fails since CVSS maxes at 10). Set it to, say, 7.0 to fail on high and critical CVEs. Tuning is about signal vs. noise: too low and every build breaks on low-severity transitive findings; too high and you miss real risk. A pragmatic strategy is to start lenient (warn only, threshold 11 with reports published), triage and suppress confirmed false positives, then ratchet the threshold down (e.g. 9 → 7) as the backlog clears. Pair it with `suppression.xml` for documented false positives and with `skipProvidedScope`/`skipTestScope` if you want to ignore non-shipping dependencies. The goal is a gate the team trusts and does not routinely bypass.

code

xml · 5 lines
xml
<configuration>
  <!-- Fail on any High or Critical (CVSS >= 7.0) -->
  <failBuildOnCVSS>7.0</failBuildOnCVSS>
  <skipTestScope>true</skipTestScope>
</configuration>

go deeper

for a junior

Know it is a CVSS threshold that fails the build above a score.

for a middle

Know the 0–11 range, the 11 default that never fails, and which bands 7 and 9 catch.

for a senior

Drive a phased rollout: report-only, triage, then ratchet down; balance noise vs. coverage and scope handling.

for a principal

Define org-wide policy: standard threshold, suppression governance, and guardrails against the gate being skipped.

## What the parameter does `failBuildOnCVSS` is a plugin configuration parameter on the `check`/`aggregate` goal. The plugin computes the **CVSS** score of each matched CVE; if any finding has a score **>= failBuildOnCVSS**, the goal throws and the build fails. - Range: `0`–`11`. - **Default: `11`** — and since real CVSS scores cap at `10.0`, the default means the build never fails on score alone (you only get a report). Many teams are surprised their build stays green with default config. ## CVSS severity bands (CVSS v3) - 9.0–10.0 = Critical - 7.0–8.9 = High - 4.0–6.9 = Medium - 0.1–3.9 = Low So `failBuildOnCVSS=7` fails on High and Critical; `=9` fails on Critical only. ## Example ```xml <plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>9.2.0</version> <configuration> <failBuildOnCVSS>7.0</failBuildOnCVSS> <suppressionFiles> <suppressionFile>dependency-check-suppressions.xml</suppressionFile> </suppressionFiles> </configuration> <executions> <execution><goals><goal>check</goal></goals></execution> </executions> </plugin> ``` ## Tuning for signal over noise 1. **Adopt gradually.** Start with the default (report only) so you do not block everyone on day one. Publish the report in CI. 2. **Triage and suppress** confirmed false positives in `suppression.xml` (CPE mismatches are common). Each suppression should be justified and ideally time-boxed. 3. **Ratchet down** the threshold as the noise clears: 11 → 9 (critical) → 7 (high+critical). Lowering further (4) is usually too noisy for a hard gate. 4. **Scope it.** Use `skipTestScope`, `skipProvidedScope`, `skipRuntimeScope`, or `skipSystemScope` to ignore dependencies that never ship to production if that matches your risk model — but be careful: test-time RCE can still bite your CI. 5. **Don't let it be bypassed.** A gate everyone routinely skips (`-Ddependency-check.skip=true`) is worse than none. Keep the threshold credible. ## Related knobs - `failOnError` (whether plugin errors, e.g. NVD download failure, fail the build). - `cvssBuildFailScore` was an older name in some versions; current is `failBuildOnCVSS`.

  • Why does a fresh install with default config never fail on vulnerabilities?
    Because the default failBuildOnCVSS is 11 and CVSS scores max at 10, so the threshold is never reached. You must lower it to get a real gate.
  • What is the risk of setting the threshold too low, like 4?
    Frequent failures on low/medium transitive findings cause alert fatigue; the team starts skipping the check, defeating its purpose.
  • Should you skip test-scope dependencies from the gate?
    It is a defensible way to cut noise on non-shipping deps, but test/build-time dependencies can still compromise your CI, so do it deliberately, not reflexively.

saying these in an interview costs you the question

  • Believing the build fails out of the box — default 11 means it never does on score.
  • Setting the threshold so low the team routinely bypasses the check.
  • Confusing CVSS (severity) with CVE (the identifier).

context

resolving links…