OWASP Dependency-Check 13.0.0

Basic-to-Essentials Hands-On Lab Manual

Audience: Beginners and engineers with basic DevOps/DevSecOps knowledge
Tutorial verified/researched on: 2026-10-03
OWASP Dependency-Check version: 13.0.0
Minimum Java supported by Dependency-Check: Java 11
Recommended lab Java runtime: Java 17 LTS or newer supported LTS
Recommended lab OS: Ubuntu 24.04 LTS (macOS notes included)
Sample repository: OWASP/NodeGoat
Repository commit: 9336e34 (fix: sync lockfile)
Sample application: Node.js / npm
Recommended Node runtime for the lab host: Node.js 24 LTS with npm available

Version note: This manual is deliberately pinned to Dependency-Check 13.0.0 and an immutable NodeGoat commit. Vulnerability databases continue to change, so the number of findings and exact severity metadata can change even when the code does not.

1. Tutorial Overview

OWASP Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to identify publicly disclosed vulnerabilities in third-party dependencies. It analyzes dependency evidence, identifies software components, maps them to identifiers such as CPEs, and associates known CVEs with the identified component.

This lab takes you from installation to a practical scan of a real OWASP training application. You will generate reports, investigate a finding, work with suppression safely, test a CVSS-based gate, and see basic Maven, Gradle, and GitHub Actions integrations.

What this lab is – and is not

This lab covers basic to essential operational use. It does not try to teach enterprise database mirroring, centralized Dependency-Check services, custom analyzers, advanced hints, air-gapped architecture, or large-scale scanner administration.

Current-version facts that matter

• Latest stable Dependency-Check release at the research cut-off: 13.0.0, released 2026-08-03.
• Java 11 or newer is required for Dependency-Check 11.0.0+.
• Dependency-Check moved from the NVD legacy data-feed model to the NVD API in 9.0.0+.
• Dependency-Check 12.1.0+ is mandatory because of NVD API compatibility changes; this lab uses 13.0.0.
• An NVD API key is strongly recommended. Without one, initial/update operations are much slower and rate limits are easier to hit.
• Current CLI report formats are: HTML, XML, CSV, JSON, JUNIT, SARIF, JENKINS, GITLAB, ALL.
• The active source repository is dependency-check/DependencyCheck; the old jeremylong/DependencyCheck repository is archived/moved.

2. Learning Objectives

By the end of the lab, you should be able to:

• Explain what OWASP Dependency-Check is and where it fits in SCA.
• Explain why dependency vulnerability analysis is part of DevSecOps.
• Install Dependency-Check CLI 13.0.0.
• Verify Java and Dependency-Check versions.
• Explain the basic evidence -> component -> CPE/CVE workflow.
• Configure the minimum settings needed for a useful scan.
• Use an NVD API key without committing it to source control.
• Clone and pin a real GitHub application for a reproducible lab.
• Identify direct dependencies in package.json and resolved dependencies in package-lock.json.
• Run Dependency-Check against the codebase.
• Locate and open the generated HTML report.
• Interpret dependency, component, CPE, evidence, CVE, CVSS, severity, references, and affected-version information.
• Explain why a detected vulnerability is not automatically proof of exploitability.
• Generate multiple report formats.
• Use important CLI options without memorizing the full CLI.
• Create and validate a suppression in a controlled exercise.
• Configure a CVSS threshold that returns a failing exit code.
• Understand the basics of Maven and Gradle integration.
• Understand a current GitHub Actions integration pattern.
• Troubleshoot common update, Java, network, path, and report problems.

3. Prerequisites

Prerequisites
├── 64-bit Ubuntu Linux or macOS
├── Java 11+ (Java 17 LTS recommended for this lab)
├── Git
├── curl
├── unzip
├── Internet access
├── Node.js 24 LTS + npm for the NodeGoat/npm analyzers
├── NVD API key (strongly recommended)
└── About 4 GB free disk space recommended for tools, cache, repo and reports
Code language: JavaScript (javascript)

Prerequisite verification

Run:

java -version
git --version
curl --version | head -n 1
unzip -v | head -n 2
node --version
npm --version

Expected result

You should see:

• Java 11 or newer.
• A valid Git version.
• curl and unzip available.
• Node.js/npm commands available.

Exact patch versions are not important to this lab.

Important Node.js note

Dependency-Check’s current documentation states that npm/pnpm/yarn analysis requires the corresponding package-manager command to be installed because the respective audit capability is used. Node.js 24 is an LTS line as of the research date. You do not need to run the intentionally vulnerable NodeGoat application for this lab.

NVD API key

Request an NVD API key from the official NVD developer page:

Do not put the key in Git, screenshots, lab handouts, shell scripts checked into repositories, or CI workflow source.

For an interactive Bash/Zsh lab session:

read -rsp "NVD API key: " NVD_API_KEY; echo
export NVD_API_KEY
Code language: JavaScript (javascript)

Verification without printing the secret:

test -n "$NVD_API_KEY" && echo "NVD_API_KEY is set" || echo "NVD_API_KEY is NOT set"
Code language: PHP (php)

4. Lab Environment

Recommended configuration

Environment variables used in this lab

export DC_VERSION="13.0.0"
export DC_ROOT="$HOME/tools/owasp-dc-$DC_VERSION"
export DC_HOME="$DC_ROOT/dependency-check"
Code language: JavaScript (javascript)

NVD_API_KEY is set interactively as shown earlier.

5. What Is OWASP Dependency-Check?

Dependency-Check is an SCA utility. Its main job is to help answer:

“Do any of the third-party components used by this application correspond to software for which publicly disclosed vulnerabilities are known?”

It is not a proof-of-exploitability engine. It is also not a replacement for patch management, threat modeling, SAST, DAST, runtime testing, or human triage.

Why SCA matters

Modern applications depend on large dependency trees. A developer may add one package while the build resolves dozens or hundreds of transitive components. SCA creates visibility into that supply chain and helps teams prioritize dependency upgrades and investigation.

Where Dependency-Check fits

Source code / dependency manifests
              |
              v
         Build / CI
              |
              v
     Dependency-Check (SCA)
              |
     +--------+---------+
     |                  |
     v                  v
Human report       Machine report
HTML               JSON/XML/SARIF/etc.
     |                  |
     +--------+---------+
              v
          Triage / Gate
              |
              v
     Upgrade / mitigate / suppress
              |
              v
            Deploy
Code language: JavaScript (javascript)

6. How Dependency-Check Works

At a beginner level, think of the scan as this pipeline:

Application
    |
    v
Dependencies / manifests / package metadata
    |
    v
Analyzers collect evidence
(vendor, product, version and ecosystem metadata)
    |
    v
Component identification
    |
    v
CPE / package identifiers where applicable
    |
    v
Vulnerability matching
    |
    v
CVE + CVSS + references + evidence
    |
    v
HTML / JSON / XML / CSV / SARIF / ... reports
Code language: JavaScript (javascript)

Dependency-Check uses analyzers to collect evidence. Evidence is categorized around vendor, product, and version. Evidence is assigned confidence levels. The tool then attempts to identify the component; for CPE-based matching, associated CVEs can be attached to the dependency.

Why false positives can happen

Names are not always globally unique. Two unrelated projects can have similar names or versions, and ecosystem metadata can be incomplete. Therefore, the first report-triage question is:

Is the identified component/CPE actually the dependency I use?

Why false negatives can happen

A dependency may lack enough identifying evidence, a product can be named differently in NVD data, or an ecosystem may not map cleanly to CPE. A clean report therefore does not prove that the application has no vulnerable dependencies.

7. Installation

The main lab uses the official CLI distribution. This makes the CLI behavior visible and keeps the lab independent of a particular build system.

Step 1 – Create a user-owned tools directory

Command

export DC_VERSION="13.0.0"
export DC_ROOT="$HOME/tools/owasp-dc-$DC_VERSION"
mkdir -p "$DC_ROOT"
Code language: JavaScript (javascript)

Expected output

No output is expected if the command succeeds.

Verification

test -d "$DC_ROOT" && echo "Tool directory ready: $DC_ROOT"
Code language: PHP (php)

Troubleshooting

Problem: Permission denied.
Cause: You selected a directory your user cannot write to.
Solution: Use a user-owned path such as $HOME/tools.
Verification: test -w "$DC_ROOT" && echo writable.

Step 2 – Download Dependency-Check 13.0.0

Command

curl -fL \
  "https://github.com/dependency-check/DependencyCheck/releases/download/v${DC_VERSION}/dependency-check-${DC_VERSION}-release.zip" \
  -o "/tmp/dependency-check-${DC_VERSION}-release.zip"
Code language: JavaScript (javascript)

Expected output

curl displays transfer progress and exits with status 0.

Verification

ls -lh "/tmp/dependency-check-${DC_VERSION}-release.zip"
Code language: JavaScript (javascript)

Troubleshooting

Problem: HTTP/DNS/connection error.
Cause: Internet access, proxy, DNS or GitHub access is blocked.
Solution: Confirm HTTPS access to GitHub or configure the required corporate proxy.
Verification: Repeat the download and confirm exit code 0.

Integrity option: OWASP publishes a signature file and documents GPG verification. For production distribution workflows, verify the release signature rather than treating an HTTPS download alone as supply-chain validation.

Step 3 – Extract the release

Command

unzip -q "/tmp/dependency-check-${DC_VERSION}-release.zip" -d "$DC_ROOT"
export DC_HOME="$DC_ROOT/dependency-check"
Code language: JavaScript (javascript)

Expected output

No output is expected from unzip -q on success.

Verification

ls "$DC_HOME/bin/dependency-check.sh"
ls "$DC_HOME/lib" | head
Code language: JavaScript (javascript)

Troubleshooting

Problem: cannot find or open archive.
Cause: Download failed or filename differs.
Solution: Verify the exact file under /tmp.
Verification: ls -l /tmp/dependency-check-13.0.0-release.zip.

Step 4 – Verify the CLI

Command

"$DC_HOME/bin/dependency-check.sh" --version
Code language: JavaScript (javascript)

Expected output

Output should identify Dependency-Check 13.0.0.

Verification

"$DC_HOME/bin/dependency-check.sh" --help | head -n 20
Code language: JavaScript (javascript)

Troubleshooting

Problem: Java error or unsupported runtime.
Cause: Java is missing, too old, or JAVA_HOME/PATH points to the wrong runtime.
Solution: Install/select Java 11+; Java 17 LTS is recommended for this lab.
Verification: java -version, then rerun --version.

macOS alternative – Homebrew

Official Dependency-Check documentation also supports Homebrew:

brew update
brew install dependency-check
dependency-check --version

For the rest of the lab, macOS Homebrew users can replace:

"$DC_HOME/bin/dependency-check.sh"
Code language: JSON / JSON with Comments (json)

with:

dependency-check

Windows note

Use the official ZIP distribution and run:

.\bin\dependency-check.bat --version
Code language: CSS (css)

The CLI options taught in this manual are the same; path quoting and shell syntax differ.

Alternative delivery methods

8. Installation Verification

Run all of the following:

java -version
"$DC_HOME/bin/dependency-check.sh" --version
"$DC_HOME/bin/dependency-check.sh" --help | head -n 30
Code language: JavaScript (javascript)

Validation criteria:

[ ] Java command works
[ ] Java is version 11 or newer
[ ] Dependency-Check reports 13.0.0
[ ] --help displays CLI usage
Code language: CSS (css)

Exercise 1 – Install and verify

Task: Install Dependency-Check and prove the installed version.
Success criteria: A terminal capture or lab note showing Dependency-Check 13.0.0 and Java 11+.

9. NVD / Data Update Configuration

Dependency-Check maintains local vulnerability data so it does not need to download the full vulnerability corpus for every scan.

What changed from older tutorials?

Older material often refers to downloading NVD JSON feeds or NVD API 1.0. That is no longer the standard current path:

• Dependency-Check has used the NVD API since 9.0.0+.
• NVD 1.0 APIs are retired.
• NVD 2.0 APIs are the preferred/current NVD interface.
• Dependency-Check 12.1.0+ is mandatory because of NVD API compatibility changes.

NVD API key – required or recommended?

For Dependency-Check itself, the key is not strictly required for every local invocation, but the project highly recommends it. Without a key, update calls use a longer default delay and initial population becomes extremely slow.

Current CLI defaults include:

Step 1 – Perform an explicit data update

Command

"$DC_HOME/bin/dependency-check.sh" \
  --updateonly \
  --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

Expected output

Expect informational messages indicating that vulnerability data is being retrieved/processed. The first population is substantially heavier than incremental updates. Exact line counts and timestamps change over time.

--updateonly does not generate a vulnerability report.

Verification

find "$DC_HOME/data" -maxdepth 2 -type f | head
Code language: JavaScript (javascript)

You should see local Dependency-Check data files.

Troubleshooting

Problem: 403 or NVD request failures.
Cause: Invalid/rate-limited key, too many concurrent jobs sharing a key, network filtering, or NVD service issues.
Solution: Verify the key, avoid many concurrent jobs using one key, persist/reuse the data cache, and check NVD availability.
Verification: Run --updateonly again after correcting the cause and confirm it completes successfully.

CI warning: do not re-download the NVD corpus in every ephemeral job

The Dependency-Check project explicitly warns that one API key used across many simultaneous CI builds can hit NVD rate limits. Operational CI should use a cache or mirrored data strategy. Enterprise mirroring is outside this beginner lab.

10. Sample GitHub Project

Selected project: OWASP NodeGoat

Repository:

Pinned commit:

9336e34  fix: sync lockfile

Why this repository was selected

• It is an OWASP public training project.
• It is intentionally designed for security learning.
• It uses a real npm dependency tree.
• The pinned commit contains both package.json and package-lock.json.
• It intentionally pins marked version 0.3.5, a historically vulnerable version used by the project’s insecure-components lesson.
• The immutable commit makes the lab reproducible even if master changes later.

Safety note: NodeGoat is intentionally vulnerable. This lab scans its dependency metadata. Do not expose the application to untrusted networks and do not use it as a production service.

Step 1 – Clone NodeGoat

mkdir -p "$HOME/labs"
cd "$HOME/labs"
git clone https://github.com/OWASP/NodeGoat.git
cd NodeGoat
Code language: PHP (php)

Expected output

Git reports cloning objects into NodeGoat.

Verification

git remote -v

Step 2 – Pin the lab commit

git checkout 9336e34

Expected Git behavior: detached HEAD at the requested historical commit.

Verify:

git rev-parse --short HEAD

Expected:

9336e34

Step 3 – Inspect the dependency manifests

ls -l package.json package-lock.json
grep '"marked"' package.json
grep -m 1 -A 3 '"marked"' package-lock.json
Code language: JavaScript (javascript)

Expected package.json line:

"marked": "0.3.5"
Code language: JavaScript (javascript)

Important dependency concepts

• package.json expresses the application’s direct dependency declarations.
• package-lock.json records the resolved npm dependency graph.
• The lock file contains many more components than the direct dependency list because transitive dependencies are included.

Exercise 2 – Identify dependencies

Task: Identify five direct dependencies and one exact pinned dependency.
Validation: Student records marked 0.3.5 and four other entries from package.json.

11. First Dependency-Check Scan

Step 1 – Go to the project

cd "$HOME/labs/NodeGoat"
Code language: JavaScript (javascript)

Verify:

pwd
git rev-parse --short HEAD

Step 2 – Create the report directory

mkdir -p reports

Step 3 – Run the scan

"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Training Lab" \
  --scan "." \
  --out "./reports" \
  --format "HTML" \
  --nvdApiKey "$NVD_API_KEY" \
  --log "./reports/dependency-check.log"
Code language: JavaScript (javascript)

What Dependency-Check is doing

1. Ensuring vulnerability/supporting data is current enough.
2. Walking the requested scan path.
3. Running applicable analyzers.
4. Reading npm package metadata/lock information.
5. Collecting identifiers/evidence.
6. Correlating identified components with vulnerability data.
7. Creating the requested report.

Expected output

The console should show normal update/analysis/report-generation messages. Exact analyzer messages and vulnerability counts are intentionally not fixed in this manual because online vulnerability/advisory data evolves.

Verification

find reports -maxdepth 1 -type f -print
Code language: PHP (php)

You should find an HTML report, normally:

reports/dependency-check-report.html

Step 4 – Open the report

Linux desktop:

xdg-open reports/dependency-check-report.html

macOS:

open reports/dependency-check-report.html

If you are on a headless training VM, copy the report to your workstation or use a browser-accessible lab artifact location.

Exercise 3 – First scan

Task: Run the scan and locate the HTML report.
Validation: reports/dependency-check-report.html exists and opens.

12. Understanding the Output

The HTML report summarizes dependencies and vulnerable components, then provides per-dependency details.

The current OWASP report-reading documentation highlights these top-level fields:

For npm components, you may also see package ecosystem identifiers rather than Java-oriented GAV information.

The most important triage sequence

Finding appears
     |
     v
Is the dependency/component identified correctly?
     |
     +-- No --> false-positive investigation / suppression candidate
     |
     v Yes
Does the vulnerability version range include our version?
     |
     +-- No --> investigate data/matching discrepancy
     |
     v Yes
Is the vulnerable code/configuration reachable or applicable here?
     |
     +-- Unknown --> investigate
     |
     +-- No --> document compensating facts; suppression only if justified
     |
     v Yes
Remediate / upgrade / mitigate
Code language: JavaScript (javascript)

13. Understanding the HTML Report

Field-by-field workflow

For one finding, work downward through:

Dependency
    |
    v
Detected version / package identity
    |
    v
CPE / package identifier + confidence
    |
    v
CVE / advisory
    |
    v
Severity + CVSS version/score
    |
    v
Description / CWE where present
    |
    v
Affected version range
    |
    v
References
    |
    v
Fixed version / remediation source where available
    |
    v
Your application's real usage and exposure

Example candidate in this lab: marked 0.3.5

The pinned NodeGoat manifest explicitly contains:

marked 0.3.5
Code language: CSS (css)

One historical advisory associated with that version is CVE-2016-10531, a sanitization-bypass/XSS issue affecting marked 0.3.5 and earlier. A current OSV record lists a CVSS v3 score of 6.1 (Medium) and a fixed version of 0.3.6.

Do not hard-code your lab grading to this one CVE. Dependency-Check data sources and matching evolve. If the exact CVE is not in your current report, select another actual finding from the generated report and perform the same analysis.

Finding worksheet

Exercise 4 – Read one finding

Task: Complete the worksheet for a real finding in your report.
Validation: Student can explain component identity, CVE, CVSS and why further investigation may still be required.

14. Understanding CVE, CVSS, Severity and Evidence

CVE

A CVE is an identifier for a publicly disclosed vulnerability record. A CVE identifier does not by itself tell you whether the issue is exploitable in your specific application.

CVSS

CVSS is a standardized severity-scoring system. Dependency-Check may display scores supplied by vulnerability sources. Always note the CVSS version and source shown in the report; do not compare numbers from different contexts as though they were identical measurements.

Typical qualitative bands on the 0-10 scale are:

Severity is not business risk

A high CVSS score does not automatically mean “fix this first” in every environment. Real risk also depends on reachability, exposure, privileges, data sensitivity, compensating controls, known exploitation, asset importance and patch feasibility.

Evidence and CPE confidence

Dependency-Check evidence supports its identification decision. Confidence indicates how strongly the collected evidence supported a CPE match. A high-confidence match can still require human validation; confidence is about identity matching, not exploitability.

Five useful finding states

15. Different Report Formats

Dependency-Check 13.0.0 supports:

HTML, XML, CSV, JSON, JUNIT, SARIF, JENKINS, GITLAB, ALL
Code language: JavaScript (javascript)

Practical report table

Generate multiple formats

rm -rf reports/multi
mkdir -p reports/multi

"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Multi-format" \
  --scan "." \
  --out "./reports/multi" \
  --format "HTML" \
  --format "JSON" \
  --format "XML" \
  --format "CSV" \
  --format "SARIF" \
  --prettyPrint \
  --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

Verify:

find reports/multi -maxdepth 1 -type f -print | sort
Code language: PHP (php)

Exercise 5 – Machine-readable output

Task: Generate JSON and SARIF in addition to HTML.
Validation: Corresponding files are present and non-empty.

test -s reports/multi/dependency-check-report.json && echo "JSON OK"
test -s reports/multi/dependency-check-report.sarif && echo "SARIF OK"
Code language: PHP (php)

16. Important CLI Options

This table intentionally covers commonly useful options rather than dumping every advanced switch.

Ant-style path caution

The official CLI documentation recommends quoting Ant-style paths so your shell does not expand them before Dependency-Check receives the pattern.

Example:

"$DC_HOME/bin/dependency-check.sh" \
  --scan './lib/**/*.jar' \
  --out ./reports
Code language: JavaScript (javascript)

Exercise 6 – Exclusion

Task: Run a scan with an exclusion that targets a known non-production test-fixture directory if your own project has one.
Validation: Report/log shows the excluded path was not analyzed.
Rule: Do not exclude a path merely because it contains inconvenient vulnerabilities.

17. Configuration

Required / strongly recommended for this lab

Optional, commonly useful

• --project
• --out
• multiple --format
• --log
• --exclude
• --suppression
• --failOnCVSS
• proxy options

Advanced – know these exist, but do not start here

• NVD mirrors/data feeds
• centralized database configuration
• analyzer enable/disable matrix
• custom hints
• OSS Index/Sonatype credentials
• hosted suppression mirrors
• custom plugins
• database server integration

Proxy configuration

Current CLI options include:

--proxyserver <server>
--proxyport <port>
--proxyuser <user>
--proxypass <pass>
--nonProxyHosts <list>
Code language: HTML, XML (xml)

Example for a proxy that does not require authentication:

"$DC_HOME/bin/dependency-check.sh" \
  --updateonly \
  --nvdApiKey "$NVD_API_KEY" \
  --proxyserver proxy.example.com \
  --proxyport 8080
Code language: JavaScript (javascript)

Avoid putting proxy passwords directly in persistent shell history when a safer organizational secret mechanism is available.

18. Suppression and False Positives

Suppression is a triage mechanism, not a way to make a dashboard green.

When suppression is appropriate

Consider suppression when you have evidence that:

• the component/CPE identification is wrong;
• a CVE does not apply to the identified artifact/version;
• a documented exception has been approved and the suppression captures the scope/rationale.

Do not suppress simply because:

• a vulnerability is hard to fix;
• the score breaks the build;
• the team is short on time;
• you have not investigated the finding.

Best beginner workflow: generate from the HTML report

1. Open the HTML report.
2. Select the relevant dependency/CPE/CVE.
3. Use the report’s Suppress function.
4. Copy the generated XML.
5. Add a meaningful note/rationale.
6. Save it as dependency-check-suppressions.xml.
7. Re-run with --suppression.
8. Confirm only the intended finding changed.

The current suppression schema is dependency-suppression.1.4.xsd.

Lab-only example

Create:

cat > dependency-check-suppressions.xml <<'XML'
<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.4.xsd">
    <!-- Prefer the XML generated from your own HTML report. -->
</suppressions>
XML
Code language: JavaScript (javascript)

Then replace the empty body with the suppression snippet produced by the report for a selected training finding.

Run:

mkdir -p reports/suppressed

"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Suppression Exercise" \
  --scan "." \
  --out "./reports/suppressed" \
  --format "HTML" \
  --suppression "./dependency-check-suppressions.xml" \
  --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

How to verify the suppression

Compare the original and suppressed reports. Confirm:

[ ] Intended finding is suppressed
[ ] Other findings remain visible
[ ] Suppression note explains why it exists
[ ] Matching scope is as narrow as practical
Code language: CSS (css)

Training rule: If you suppress a real NodeGoat vulnerability only to learn the mechanism, label it LAB ONLY, demonstrate the behavior, then remove that rule. The vulnerable component did not become safe because the report stopped showing it.

Exercise 7 – Suppression

Task: Use the HTML report to generate one lab-only suppression, rerun, validate it, and then remove the lab suppression.
Success criteria: Student can show before/after reports and explain why suppression is not remediation.

19. Build Failure / Security Threshold

A scan and a security gate are different concepts:

Scan
  |
  v
Report findings
  |
  v
Compare findings with threshold/policy
  |
  +---- below threshold ----> exit 0 / pass
  |
  +---- at/above threshold -> non-zero / fail
Code language: JavaScript (javascript)

Dependency-Check CLI supports:

--failOnCVSS <score>
Code language: HTML, XML (xml)

A value between 0 and 10 causes the exit status to indicate failure when a vulnerability with CVSS equal to or greater than the threshold is identified.

Controlled gate exercise

First identify the highest CVSS score in your actual report. Choose a threshold at or below one reported score, for example 7.0 if a High finding exists.

set +e

"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Gate Exercise" \
  --scan "." \
  --out "./reports/gate" \
  --format "HTML" \
  --nvdApiKey "$NVD_API_KEY" \
  --failOnCVSS 7.0

DC_EXIT=$?
set -e

echo "Dependency-Check exit code: $DC_EXIT"
Code language: PHP (php)

Expected result

If at least one unsuppressed finding has CVSS >= 7.0, the command should return a non-zero exit status.

If your current report has no finding at or above 7.0, set the exercise threshold equal to or below an observed score rather than pretending the gate failed.

Report generation vs gate vs build failure

A mature policy usually considers more than CVSS alone. This lab uses CVSS only because it is the scanner’s simple built-in gate mechanism.

Exercise 8 – Test the threshold

Task: Demonstrate one passing and one failing threshold using the same scan target.
Validation: Record both exit codes and explain why the report itself is still valuable even when the process exits non-zero.

20. Maven Integration

This section is an integration example for a Maven project; NodeGoat itself is not Maven-based.

Current requirements

Dependency-Check Maven plugin 13.0.0 requires:

• Maven 3.8.1+
• JDK 11+

One-off scan

mvn org.owasp:dependency-check-maven:13.0.0:check
Code language: CSS (css)

For real CI, do not pass the NVD key in a way that may be exposed by Maven debug logging. Current plugin documentation specifically recommends nvdApiKeyEnvironmentVariable (or Maven server settings) rather than directly logging a key.

Recommended POM pattern

<build>
  <plugins>
    <plugin>
      <groupId>org.owasp</groupId>
      <artifactId>dependency-check-maven</artifactId>
      <version>13.0.0</version>
      <configuration>
        <nvdApiKeyEnvironmentVariable>NVD_API_KEY</nvdApiKeyEnvironmentVariable>
        <failBuildOnCVSS>8.0</failBuildOnCVSS>
        <formats>
          <format>HTML</format>
          <format>SARIF</format>
        </formats>
      </configuration>
      <executions>
        <execution>
          <goals>
            <goal>check</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
Code language: HTML, XML (xml)

Then:

export NVD_API_KEY="...set securely..."
mvn verify
Code language: JavaScript (javascript)

The check goal binds by default to Maven’s verify lifecycle phase when configured as a build plugin.

Maven build-failure default

The plugin’s failBuildOnCVSS default is 11, which means CVSS 0-10 findings do not fail the build unless you configure a threshold.

21. Gradle Integration

This section is for a Gradle project.

Current Dependency-Check Gradle plugin compatibility documentation states:

• Gradle 7.6.4 through 9.x
• Gradle running on Java 11+
• Plugin version 13.0.0

Apply the plugin

Groovy DSL:

plugins {
    id 'org.owasp.dependencycheck' version '13.0.0'
}

dependencyCheck {
    failBuildOnCVSS = 8.0
    formats = ['HTML', 'SARIF']
    nvd {
        apiKey = System.getenv('NVD_API_KEY')
    }
}
Code language: JavaScript (javascript)

Run:

./gradlew dependencyCheckAnalyze

Current Gradle plugin documentation places reports under the build reporting directory; the current plugin README describes the default as:

build/reports/dependency-check

The older documentation wording ${buildDir}/reports is less specific; when teaching 13.0.0, follow the current plugin README/build reporting configuration.

Gradle build-failure default

Like Maven, failBuildOnCVSS defaults to 11, so you must configure a 0-10 threshold if you want vulnerability severity to fail the build.

22. Basic CI/CD Integration

Conceptual flow

Developer
   |
   v
Git push / pull request
   |
   v
CI runner
   |
   v
Checkout
   |
   v
Set up Java
   |
   v
Install Dependency-Check 13.0.0
   |
   v
Scan
   |
   +----> HTML/SARIF artifacts
   |
   v
CVSS gate
   |
   v
Build pass/fail -> next pipeline stage
Code language: JavaScript (javascript)

Why this lab does not rely on an old wrapper example

Many Dependency-Check GitHub Action examples found online use old major versions of actions/checkout and actions/upload-artifact. This lab deliberately uses the official OWASP CLI release plus current first-party GitHub actions instead of copying stale workflow snippets.

As of the research date:

• actions/checkout@v7 is current.
• actions/setup-java@v6 is current; its documentation marks v1-v4 deprecated.
• actions/upload-artifact@v7 is current.

Current GitHub Actions example

name: dependency-check

on:
  push:
  pull_request:

jobs:
  sca:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v7

      - name: Set up Java
        uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: '17'

      - name: Install OWASP Dependency-Check 13.0.0
        shell: bash
        run: |
          curl -fL \
            "https://github.com/dependency-check/DependencyCheck/releases/download/v13.0.0/dependency-check-13.0.0-release.zip" \
            -o "$RUNNER_TEMP/dependency-check.zip"
          unzip -q "$RUNNER_TEMP/dependency-check.zip" -d "$RUNNER_TEMP"
          chmod +x "$RUNNER_TEMP/dependency-check/bin/dependency-check.sh"
          echo "DC_HOME=$RUNNER_TEMP/dependency-check" >> "$GITHUB_ENV"

      - name: Run Dependency-Check
        env:
          NVD_API_KEY: ${{ secrets.NVD_API_KEY }}
        shell: bash
        run: |
          "$DC_HOME/bin/dependency-check.sh" \
            --project "${{ github.repository }}" \
            --scan "." \
            --out "dependency-check-reports" \
            --format "HTML" \
            --format "SARIF" \
            --nvdApiKey "$NVD_API_KEY" \
            --failOnCVSS 8.0

      - name: Upload reports
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: dependency-check-reports
          path: dependency-check-reports/
Code language: JavaScript (javascript)

Action/tool ownership

CI production note

This minimal workflow is for teaching. For repeated CI usage, cache or centrally mirror Dependency-Check data instead of having every ephemeral job repopulate/update independently. Also separate report publishing from gate behavior so reports are retained even when the security step fails.

23. Hands-On Exercises

Exercise 1 – Install and verify

Do: Install 13.0.0 and run --version.
Pass: Version is 13.0.0; Java is 11+.

Exercise 2 – Clone and pin NodeGoat

Do: Clone OWASP/NodeGoat and checkout 9336e34.
Pass: git rev-parse --short HEAD prints 9336e34.

Exercise 3 – Identify dependencies

Do: Inspect package.json and package-lock.json.
Pass: Student identifies marked 0.3.5 plus at least four other direct dependencies.

Exercise 4 – First scan

Do: Generate an HTML report.
Pass: HTML file exists and opens.

Exercise 5 – Highest-severity finding

Do: Locate the highest-severity finding in the current report.
Pass: Record dependency, version, CVE, CVSS version, score and severity.

Exercise 6 – Validate component identity

Do: Check the reported identifier/CPE/PURL and evidence for the selected finding.
Pass: Student can state whether the component match appears correct and why.

Exercise 7 – Generate JSON and SARIF

Do: Generate HTML + JSON + SARIF.
Pass: All requested output files are non-empty.

Exercise 8 – Suppression

Do: Generate one lab-only suppression from the HTML report, rerun and compare.
Pass: Only the intended finding is suppressed; student then removes the lab rule.

Exercise 9 – Security threshold

Do: Choose a threshold based on an observed finding and run with --failOnCVSS.
Pass: Student records a non-zero exit when a finding meets/exceeds the threshold.

Exercise 10 – Build integration

Do: On a separate Maven or Gradle sample project, add Dependency-Check 13.0.0 and generate an HTML report.
Pass: Scan runs from the build tool and the report is generated.

Exercise 11 – Explain the result

Do: Give a 2-minute explanation of one finding.
Pass: Explanation separates detection, identity validation, affected-version validation and exploitability/applicability.

24. Troubleshooting

24.1 Java version problem

Problem
Dependency-Check fails at startup with Java/runtime errors.

Cause
Java is missing or older than 11, or the shell uses a different Java than expected.

Solution

java -version
command -v java

Install/select Java 11+; Java 17 LTS is recommended for this lab.

Verification

"$DC_HOME/bin/dependency-check.sh" --version
Code language: JavaScript (javascript)

24.2 Command not found

Problem
dependency-check is not found.

Cause
CLI bin directory is not on PATH, or you are using the ZIP install without calling its full path.

Solution

"$DC_HOME/bin/dependency-check.sh" --version
Code language: JavaScript (javascript)

Verification
Version prints successfully.

24.3 Permission denied

Problem
Shell script cannot execute.

Cause
Execute permission was not preserved.

Solution

chmod +x "$DC_HOME/bin/dependency-check.sh"
Code language: JavaScript (javascript)

Verification

"$DC_HOME/bin/dependency-check.sh" --version
Code language: JavaScript (javascript)

24.4 NVD update failure / HTTP 403

Problem
NVD update fails, especially in CI.

Cause
Invalid key, rate limiting, many concurrent builds sharing a key, blocked egress, or service disruption.

Solution

• Confirm the API key is valid.
• Use a persistent Dependency-Check data cache.
• Avoid many simultaneous full updates using one key.
• Check corporate proxy/firewall policy.
• For operational environments, consider the project’s recommended NVD mirroring/caching approach.

Verification

"$DC_HOME/bin/dependency-check.sh" --updateonly --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

24.5 Network / proxy issue

Problem
Timeouts or connection failures downloading data.

Cause
Proxy/firewall/DNS configuration.

Solution
Use the documented proxy parameters, for example:

"$DC_HOME/bin/dependency-check.sh" \
  --updateonly \
  --nvdApiKey "$NVD_API_KEY" \
  --proxyserver proxy.example.com \
  --proxyport 8080
Code language: JavaScript (javascript)

Verification
Update completes.

24.6 API key appears unset

Problem
The command runs as if no key is supplied.

Cause
Environment variable was not exported in the current shell/CI step.

Solution

test -n "$NVD_API_KEY" && echo set || echo missing
Code language: PHP (php)

Set it securely.

Verification
Run update again and inspect normal execution logs without printing the key.

24.7 First scan is slow

Problem
The initial run is much slower than later runs.

Cause
The local vulnerability database must be populated/processed. Official Maven documentation notes that the first run can take 20 minutes or more; actual duration depends on network, API key use and machine resources.

Solution
Use an NVD API key and persist the data directory between runs.

Verification
A later run reuses local data and performs only needed updates.

24.8 Local database/cache issue after an upgrade

Problem
Dependency-Check data is incompatible or errors after a major upgrade.

Cause
Dependency-Check 11 introduced an incompatible H2 database change; other data problems can also require a clean repopulation.

Solution
Use purge when documentation/release notes indicate it is required:

"$DC_HOME/bin/dependency-check.sh" --purge
"$DC_HOME/bin/dependency-check.sh" --updateonly --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

Verification
Update completes and a fresh scan succeeds.

Do not make --purge your first response to every error; it forces re-download/reprocessing.

24.9 No vulnerabilities detected

Problem
Report is unexpectedly empty/clean.

Cause
Wrong scan path, missing manifests/artifacts, stale/no data, analyzer prerequisite missing, or genuinely no current matches.

Solution

pwd
ls package.json package-lock.json
npm --version
"$DC_HOME/bin/dependency-check.sh" --version
Code language: JavaScript (javascript)

Confirm you are scanning the pinned NodeGoat directory and have current data.

Verification
Re-run and inspect the HTML dependency list, not only the vulnerability summary.

24.10 Too many findings

Problem
Report contains many findings and appears noisy.

Cause
The target is intentionally old/vulnerable, transitive dependencies expand the surface, or some CPE matches may be false positives.

Solution
Triage by component identity, CPE confidence/evidence, version range, severity and application applicability. Suppress only validated false positives/approved exceptions.

Verification
Each suppression has a narrow match and written rationale.

24.11 Report not generated

Problem
No report appears in the expected directory.

Cause
Wrong --out path, permission issue, invalid option, or scanner error.

Solution

mkdir -p reports
test -w reports && echo writable
Code language: PHP (php)

Run with a log:

"$DC_HOME/bin/dependency-check.sh" \
  --scan "." \
  --out "./reports" \
  --format HTML \
  --log "./reports/dc.log" \
  --nvdApiKey "$NVD_API_KEY"
Code language: JavaScript (javascript)

Verification

find reports -maxdepth 1 -type f -print
Code language: PHP (php)

24.12 Incorrect project path

Problem
Dependency-Check completes but analyzed the wrong content.

Cause
Relative path was resolved from a different working directory.

Solution

pwd
realpath .

Prefer an explicit path when automation is ambiguous.

Verification
HTML dependency list contains the expected NodeGoat/npm components.

24.13 False positive

Problem
A CVE is associated with the wrong component/CPE.

Cause
Evidence-based identification is imperfect.

Solution
Validate the component/CPE first. If it is incorrect, generate a narrow suppression from the HTML report and document the reason.

Verification
Rerun with the suppression file and confirm only the intended match is removed/suppressed.

25. Lab Validation Checklist

[ ] Java 11+ installed
[ ] Git installed
[ ] Node.js/npm available for npm analysis
[ ] Dependency-Check 13.0.0 installed
[ ] Dependency-Check version verified
[ ] NVD API key obtained and stored securely
[ ] NVD/Dependency-Check data updated
[ ] OWASP NodeGoat cloned
[ ] NodeGoat pinned to commit 9336e34
[ ] package.json and package-lock.json inspected
[ ] First scan completed
[ ] HTML report generated
[ ] At least one finding investigated
[ ] Component/CPE identity checked
[ ] CVE understood
[ ] CVSS version/score understood
[ ] Severity vs risk distinction understood
[ ] JSON report generated
[ ] XML or CSV report generated
[ ] SARIF report generated
[ ] Lab suppression tested and removed/documented
[ ] CVSS threshold tested
[ ] Maven or Gradle integration understood
[ ] CI/CD integration understood
[ ] Student can explain false positive vs false negative
Code language: JavaScript (javascript)

26. Knowledge Check

Questions

1. Multiple choice

What is Dependency-Check primarily designed to detect?

A. SQL injection in custom source code
B. Publicly disclosed vulnerabilities associated with application dependencies
C. Weak passwords in production databases
D. Runtime memory leaks

2. True/False

A Dependency-Check CVE finding proves that the vulnerable code path is exploitable in your application.

3. Short answer

What is the first thing the official report-reading guidance recommends checking when reviewing a potential false positive?

4. Multiple choice

What is the minimum Java version for Dependency-Check 13.0.0?

A. 8
B. 11
C. 17 only
D. 21 only

5. Short answer

Why is an NVD API key strongly recommended?

6. Multiple choice

Which option can make the CLI return a failing/non-zero exit status based on vulnerability severity?

A. --format
B. --log
C. --failOnCVSS
D. --prettyPrint

7. True/False

Suppressing a finding is equivalent to fixing the vulnerable dependency.

8. Practical

Your CI job receives repeated NVD 403 errors while 40 parallel jobs use the same key and each starts with an empty cache. Name two corrective design actions.

9. Multiple choice

Which set contains only currently documented CLI report formats?

A. HTML, XML, JSON, SARIF
B. HTML, DOCX, PPTX, SARIF
C. PDF, XML, JSON, YAML
D. HTML, SQLite, PARQUET, SARIF

10. Practical

A report associates your library with a CPE for a similarly named but different product. What should you do before suppressing it?

11. Short answer

What does --updateonly do?

12. Short answer

Why does this lab pin NodeGoat to commit 9336e34 instead of using master?

13. True/False

The default Maven/Gradle failBuildOnCVSS value of 11 means a normal CVSS 0-10 vulnerability will fail the build by default.

14. Practical

A student ran --scan . from their home directory rather than the NodeGoat directory and received an unexpected report. What should they verify?

15. Short answer

Give one reason a false negative can occur in Dependency-Check.

Answer key

1. B. Dependency-Check is SCA focused on publicly disclosed vulnerabilities associated with dependencies.
2. False. The match requires triage for identity, affected version and real applicability/reachability.
3. Validate the identified component/CPE. Wrong identity is a common source of false positives.
4. B – Java 11. Java 11 became mandatory in Dependency-Check 11.0.0+.
5. It improves practical NVD update performance and reduces problems caused by anonymous rate limits/default delays.
6. C – --failOnCVSS. It changes the CLI exit status when an unsuppressed finding meets/exceeds the threshold.
7. False. Suppression changes reporting; it does not patch code or remove the vulnerable dependency.
8. Reuse/persist the Dependency-Check data cache and reduce/consolidate update concurrency; for larger environments use the project’s recommended mirror/cache strategy.
9. A. All four are current supported formats. The full list also includes CSV, JUNIT, JENKINS, GITLAB and ALL.
10. Validate the dependency, CPE/PURL and evidence against the real component/version, then document why the match is wrong before making a narrow suppression.
11. It runs the update phase only; no scan and no vulnerability report are produced.
12. Reproducibility: the immutable commit fixes the exact dependency manifests/lock file used by the exercise.
13. False. CVSS tops out at 10, so default 11 effectively means “do not fail on CVSS findings” until configured.
14. Verify pwd, the actual scan path, and that expected manifests/artifacts are present in the target directory.
15. Examples: insufficient identifying evidence, naming mismatch, incomplete ecosystem mapping, or a vulnerability not yet represented/matched in the data source.

27. Key Takeaways

1. Dependency-Check is an SCA signal generator, not an automatic exploitability verdict.
2. Use a current release. For this manual that is 13.0.0.
3. Java 11+ is required; Java 17 LTS is a sensible lab runtime.
4. The modern NVD path is the NVD API, and an API key is strongly recommended.
5. Persist the data cache; do not make every CI job perform a cold NVD population.
6. Read the HTML report by validating component identity first.
7. CVSS measures severity; it is not a complete business-risk score.
8. Suppress only validated false positives/approved exceptions, with narrow scope and rationale.
9. Use --failOnCVSS when you need a simple severity gate, but design real policy with more context.
10. Pin training code and tool versions so the lab remains reproducible.
11. Keep GitHub Actions examples current; do not copy old workflows blindly.
12. Revisit this lab when Dependency-Check, NVD APIs, Java requirements, action majors or plugin versions change.

28. Sources & References

Official OWASP Dependency-Check / project sources

1. Dependency-Check active repository / README
   https://github.com/dependency-check/DependencyCheck
   Used for: SCA definition, active repository, Java 11 requirement, NVD API migration, 12.1.0+ mandatory upgrade, API-key guidance, npm tool requirement.
2. Dependency-Check 13.0.0 release
   https://github.com/dependency-check/DependencyCheck/releases/tag/v13.0.0
   Used for: stable version and release date.
3. CLI installation / usage
   https://dependency-check.github.io/DependencyCheck/dependency-check-cli/
   Used for: official ZIP/Homebrew installation and CLI usage.
4. CLI arguments – 13.0.0 documentation
   https://dependency-check.github.io/DependencyCheck/dependency-check-cli/arguments.html
   Used for: scan/output/report/update/proxy/data/suppression/failure options and current defaults.
5. How Dependency-Check works
   https://dependency-check.github.io/DependencyCheck/general/internals.html
   Used for: analyzers, evidence, confidence, CPE/CVE matching, false-positive/false-negative concepts.
6. How to read reports
   https://dependency-check.github.io/DependencyCheck/general/thereport.html
   Used for: report fields and recommended triage order.
7. Suppressing false positives
   https://dependency-check.github.io/DependencyCheck/general/suppression.html
   Used for: suppression workflow and current 1.4 suppression schema.
8. Maven plugin usage
   https://dependency-check.github.io/DependencyCheck/dependency-check-maven/
   https://dependency-check.github.io/DependencyCheck/dependency-check-maven/check-mojo.html
   https://dependency-check.github.io/DependencyCheck/dependency-check-maven/plugin-info.html
   Used for: plugin 13.0.0, Maven/JDK requirements, verify, report formats, NVD key handling and failBuildOnCVSS.
9. Gradle plugin usage/configuration
   https://dependency-check.github.io/DependencyCheck/dependency-check-gradle/
   https://dependency-check.github.io/DependencyCheck/dependency-check-gradle/configuration.html
   https://github.com/dependency-check/dependency-check-gradle
   Used for: plugin 13.0.0, task name, Gradle compatibility, report directory and gate configuration.

Official NVD / NIST sources

10. NVD data feeds / API guidance
    https://nvd.nist.gov/vuln/data-feeds
    Used for: NVD 2.0 APIs as preferred current interface.
11. NVD change timeline
    https://nvd.nist.gov/general/news/change-timeline
    Used for: 2.0 transition and 1.0 deprecation/retirement context.
12. NVD API key request
    https://nvd.nist.gov/developers/request-an-api-key

Sample application

13. OWASP NodeGoat repository
    https://github.com/OWASP/NodeGoat
14. Pinned lab commit
    https://github.com/OWASP/NodeGoat/commit/9336e34
15. Pinned package.json
    https://raw.githubusercontent.com/OWASP/NodeGoat/9336e34/package.json
16. Pinned package-lock.json
    https://raw.githubusercontent.com/OWASP/NodeGoat/9336e34/package-lock.json

GitHub Actions – first-party

17. actions/checkout
    https://github.com/actions/checkout
18. actions/setup-java
    https://github.com/actions/setup-java
19. actions/upload-artifact
    https://github.com/actions/upload-artifact

Node.js

20. Node.js release status
    https://nodejs.org/en/about/previous-releases

Vulnerability example / secondary verification

21. OSV record for CVE-2016-10531
    https://osv.dev/vulnerability/CVE-2016-10531
    Used only for the lab’s illustrative marked 0.3.5 example and fixed-version/severity context. Students should use the actual current Dependency-Check report plus primary advisory/NVD/CVE references during real triage.

Appendix A – Quick Lab Command Sheet

<em># 1) Variables</em>
export DC_VERSION="13.0.0"
export DC_ROOT="$HOME/tools/owasp-dc-$DC_VERSION"
export DC_HOME="$DC_ROOT/dependency-check"

<em># 2) Download/install</em>
mkdir -p "$DC_ROOT"
curl -fL \
  "https://github.com/dependency-check/DependencyCheck/releases/download/v${DC_VERSION}/dependency-check-${DC_VERSION}-release.zip" \
  -o "/tmp/dependency-check-${DC_VERSION}-release.zip"
unzip -q "/tmp/dependency-check-${DC_VERSION}-release.zip" -d "$DC_ROOT"

<em># 3) Verify</em>
java -version
"$DC_HOME/bin/dependency-check.sh" --version

<em># 4) NVD key</em>
read -rsp "NVD API key: " NVD_API_KEY; echo
export NVD_API_KEY

<em># 5) Update</em>
"$DC_HOME/bin/dependency-check.sh" --updateonly --nvdApiKey "$NVD_API_KEY"

<em># 6) Clone/pin lab app</em>
mkdir -p "$HOME/labs"
cd "$HOME/labs"
git clone https://github.com/OWASP/NodeGoat.git
cd NodeGoat
git checkout 9336e34

<em># 7) Scan</em>
mkdir -p reports
"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Training Lab" \
  --scan "." \
  --out "./reports" \
  --format "HTML" \
  --nvdApiKey "$NVD_API_KEY" \
  --log "./reports/dependency-check.log"

<em># 8) Multiple formats</em>
"$DC_HOME/bin/dependency-check.sh" \
  --project "OWASP NodeGoat - Multi-format" \
  --scan "." \
  --out "./reports/multi" \
  --format HTML \
  --format JSON \
  --format XML \
  --format CSV \
  --format SARIF \
  --prettyPrint \
  --nvdApiKey "$NVD_API_KEY"
Code language: PHP (php)

Appendix B – Instructor Notes

Expected learning behavior

Do not grade students on an exact vulnerability count. Grade them on whether they can:

• reproduce the pinned repository state;
• complete a scan;
• find the generated report;
• validate a component identity;
• interpret one real finding;
• distinguish severity from application-specific risk;
• explain false positives/negatives;
• demonstrate suppression safely;
• demonstrate a threshold gate;
• explain how the same capability moves into CI.

Pre-class validation

Before each delivery, the instructor should run:

"$DC_HOME/bin/dependency-check.sh" --version
"$DC_HOME/bin/dependency-check.sh" --advancedHelp | head -n 20
git -C "$HOME/labs/NodeGoat" rev-parse --short HEAD
npm --version
Code language: JavaScript (javascript)

Then perform one clean scan and confirm the report renders. Because NVD/advisory data is live, update screenshots and example finding screenshots only after confirming they still match the current report.

Maintenance trigger

Re-verify this manual if any of the following changes:

• Dependency-Check stable major/minor version;
• Java minimum version;
• NVD API compatibility guidance;
• suppression XSD version;
• report-format list;
• Maven/Gradle plugin version or minimum build-tool version;
• GitHub Actions major versions;
• NodeGoat training dependency manifests;
• NVD/advisory behavior for the sample finding.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.