Mastering maven dependency check: A Quick Guide to Secure Builds

A proactive maven dependency check is more than just good practice—it’s a foundational part of securing your software supply chain. At its core, it’s about systematically scanning your project’s third-party libraries for known vulnerabilities, stopping security flaws from ever making their way into your codebase.

Why Dependency Management Is a Security Blind Spot

Let’s be honest, modern software development is built on the shoulders of open-source giants. We all pull in third-party libraries for everything from logging to database connections because it lets us build faster. But this convenience comes with a huge security blind spot: every single dependency is a potential door for an attacker.

When you add a library to your pom.xml, you’re not just importing features. You’re also inheriting its entire security history, both the good and the bad. This tangled web of dependencies makes up your software supply chain, and a single weak link can put your entire application at risk.

The Real-World Risks of Unchecked Dependencies

Ignoring dependencies just isn’t an option anymore, especially as regulatory pressure mounts. A vulnerable dependency can lead to anything from a minor data leak to a full-blown breach with serious legal and financial fallout.

Think about these all-too-common scenarios:

• A popular logging library has a critical remote code execution (RCE) vulnerability, basically handing attackers the keys to your servers. For example, the infamous Log4Shell (CVE-2021-44228) in Log4j allowed unauthenticated attackers to execute code on vulnerable servers.
• An old, forgotten JSON parsing library contains a flaw that opens you up to a denial-of-service (DoS) attack, bringing your application to its knees.
• A transitive dependency—a library your dependency relies on—has a known security issue that you don’t even know exists. If you want to get better at untangling these relationships, a good first step is learning to navigate your https://goregulus.com/cra-basics/maven-dependency-tree/.

These aren’t just hypotheticals; they are real incidents that have hit countless organisations.

The real danger is what you don’t know. Too many development teams are flying blind, with no clear inventory of their third-party components. When the next Log4Shell hits, they’re left scrambling, trying to figure out if they’re even affected. This reactive, fire-fighting approach is both inefficient and incredibly risky.

Meeting Compliance with Proactive Scanning

Regulations like the EU’s Cyber Resilience Act (CRA) are fundamentally changing the game. They place the responsibility for software security squarely on the shoulders of the manufacturers. The CRA demands that products with digital elements are secure by design and that vendors have solid processes for managing vulnerabilities throughout the product’s entire lifecycle.

Trying to track all your dependencies manually is a recipe for disaster; it just doesn’t scale. This is where automated tools become non-negotiable.

The OWASP Dependency-Check plugin for Maven is a powerful, open-source tool that slots directly into your build process. It automatically scans your project’s dependencies against the National Vulnerability Database (NVD) and gives you a clear, actionable report on any known security issues.

By embedding a maven dependency check right into your development workflow, you shift vulnerability management from a painful, periodic chore into a continuous, automated habit. Acknowledging this blind spot is the first step. The next is building a comprehensive security strategy, which includes a regular information technology security audit to ensure you stay compliant and resilient. This proactive stance is the only way to build software that’s not just functional, but truly secure and trustworthy.

Integrating the OWASP Maven Dependency Check Plugin

Getting the OWASP plugin running in your project is surprisingly straightforward. The first and most important step is to integrate it directly into your pom.xml. This simple action is your entry point to automating dependency checks and building a much more secure development lifecycle.

The OWASP logo represents a massive community effort to improve software security, and for Java developers, this plugin is one of its most practical contributions.

By adding this to your build, you’re handing off the tedious, error-prone task of manually checking libraries for known vulnerabilities to a powerful, automated tool.

Your First POM.xml Configuration

To get started, you’ll need to add the dependency-check-maven plugin to the <plugins> section of your project’s pom.xml file. It’s always a good idea to lock the plugin to a specific version—this ensures your builds are consistent and predictable, no matter where they run.

Here’s a clean, practical example of what that configuration looks like:

<build>
    <plugins>
        <plugin>
            <groupId>org.owasp</groupId>
            <artifactId>dependency-check-maven</artifactId>
            <version>9.2.0</version> <!-- Best practice: Lock to a specific version -->
            <executions>
                <execution>
                    <goals>
                        <goal>check</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

This simple block tells Maven to run the check goal as part of its standard build lifecycle. So, every time you run a command like mvn verify, the dependency scan will kick off automatically.

Configuring for Multi-Module Projects

If you’re working on a multi-module Maven project, which is typical for larger applications, you’ll want to switch from the check goal to aggregate. This goal is designed specifically for this scenario; it scans all your sub-modules and then conveniently rolls up the findings into a single, unified report in the root project’s target directory.

To set this up, place the plugin configuration in your parent pom.xml like so:

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.2.0</version>
    <executions>
        <execution>
            <goals>
                <!-- Use 'aggregate' for multi-module projects -->
                <goal>aggregate</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Using the aggregate goal is a game-changer for complex projects. It stops you from having to piece together fragmented reports from each module, giving you a single, clear view of your entire application’s vulnerability posture. This is absolutely essential for effective prioritisation.

Running Your First Local Scan

Once the plugin is configured in your POM, running a scan is as simple as executing one command from your project’s root directory. This on-demand approach is perfect when you just want a quick security check without triggering a full build.

Open your terminal and run this command:

mvn org.owasp:dependency-check-maven:check

The very first time you run this, be prepared for it to take a few minutes. The plugin needs to download the entire National Vulnerability Database (NVD) to build a local cache for its analysis. Don’t worry, subsequent scans will be significantly faster as they’ll only need to fetch updates.

You’ll see output in your console that looks something like this, showing the scan is underway and flagging vulnerabilities:

[INFO] --- dependency-check-maven:9.2.0:check (default-cli) @ your-project ---
[INFO] Checking for updates
[INFO] NVD CVE Data exists, checking for updates.
...
[INFO] One or more dependencies were identified with vulnerabilities:
[INFO]
[INFO] jquery-3.5.1.jar: cpe:/a:jquery:jquery:3.5.1 (CVE-2020-11022, CVE-2020-11023)
...
[INFO] Report Generated: /path/to/your-project/target/dependency-check-report.html

After the scan finishes, that last line of output points you straight to the HTML report. Open that file in your browser, and you’ll get a detailed, interactive breakdown of all the findings. You can find out more about what the OWASP Dependency-Check tool is capable of in our guide.

This kind of proactive scanning is especially critical for teams building products for the European market. In the European software manufacturing sector, companies are racing to meet Cyber Resilience Act (CRA) deadlines. Shockingly, a comprehensive analysis of Maven Central repositories shows that the OWASP Dependency-Check Maven plugin has been adopted in just nine artefacts hosted by EU vendors, revealing a significant gap in automated security practices. This low uptake increases compliance risks, as vulnerabilities in common libraries like jsch-0.1.55 persist unchecked, creating direct exposure for digital products. You can discover more insights about these compliance challenges on Arxiv.

How to Analyse Your First Vulnerability Report

Once your first scan finishes, you’ll get a detailed HTML report. It can feel like a data dump at first, but learning to navigate it is the key to turning that raw information into a solid security plan. Think of this report as your command centre for taming dependency risk.

The report is typically sliced into three main sections:

• The Dashboard: This is your 10,000-foot view. It gives you a quick summary, showing the total number of vulnerable dependencies and breaking them down by severity (Critical, High, Medium, and Low).
• Vulnerable Libraries List: Here’s where it gets specific. This section lists every single library found with at least one known vulnerability, along with a count of its associated CVEs (Common Vulnerabilities and Exposures).
• Detailed CVE Entries: When you click on a library, this section expands to show the specific CVEs affecting it. You’ll find descriptions, severity scores, and other critical details here.

Decoding the CVSS Score

One of the first things you’ll notice is the CVSS (Common Vulnerability Scoring System) score. It’s a number from 0.0 to 10.0 that sums up how bad a vulnerability is.

This score isn’t arbitrary; it’s calculated based on factors like how easy the flaw is to exploit and the potential damage it could cause. While the number is a good indicator, the severity rating is what usually drives the initial triage.

• Critical (9.0-10.0): These are the five-alarm fires. They’re often easy to exploit remotely and can lead to a full system takeover. Fix these first. No excuses.
• High (7.0-8.9): Still very serious. These flaws can result in major data theft or service outages. They might take a bit more work to exploit than criticals, but they need urgent attention.
• Medium (4.0-6.9): These vulnerabilities often depend on specific conditions, like user interaction or a non-default configuration, making them harder to exploit. Don’t ignore them, but they aren’t as pressing.
• Low (0.1-3.9): Usually minor issues with very limited impact.

Each CVE entry will have a link that takes you straight to its official record in the National Vulnerability Database (NVD). Clicking that link is essential for getting the full story. To get a better handle on how this massive database works, check out our guide on the National Vulnerability Database in our detailed guide.

A Smarter Way to Prioritise Fixes

Here’s a hard-earned piece of advice: you can’t fix everything at once. And just chasing the highest CVSS scores is a rookie mistake. Why? Because context is king. A vulnerability’s real-world risk is all about how that library is actually used in your application.

The most effective approach to remediation isn’t just about the severity score; it’s about the intersection of severity and exposure. A “medium” vulnerability in a core, internet-facing authentication library is infinitely more dangerous than a “critical” one in a dependency used only for running offline unit tests.

Let’s walk through a real-world scenario. Your report flags two issues:

1. A Critical (9.8) vulnerability in a test-scoped dependency, maybe an assertion library that only JUnit ever touches.
2. A Medium (6.5) vulnerability in an old version of jackson-databind, a JSON parser that handles data for your public-facing REST APIs.

The CVSS score screams that the test library is the bigger problem. But its actual risk to your production system is practically zero because that code never sees the light of day. Meanwhile, that medium-severity flaw in Jackson is a ticking time bomb, sitting in a critical data path where an attacker could potentially exploit it with a well-crafted API request.

In this case, fixing the Jackson vulnerability is your number one priority, hands down. Your triage process should always be guided by a few key questions:

• Where is this library used? Is it in a core, mission-critical service or some forgotten background utility?
• Is the vulnerable code path actually exposed? Can an attacker from the outside even reach it?
• What’s the worst-case scenario? If exploited, would it lead to data exposure, a system takeover, or a service outage?

By asking these questions, you stop reacting to scary-looking numbers and start making intelligent, risk-based decisions. This methodical approach is the hallmark of a mature security programme and is the foundation of any successful maven dependency check strategy.

Advanced Configuration and Handling False Positives

Once you have your initial scans running, it’s time to tune the OWASP plugin to fit how your team actually works. A default configuration is a great starting point, but the advanced settings are what turn a noisy report into a high-signal security tool that developers trust. This is where you elevate the maven dependency check from a simple scanner into a proper security gate.

One of the most powerful moves you can make is set a failure threshold. You can configure the plugin to intentionally break the build if a vulnerability is too severe, stopping high-risk code from ever getting merged.

Setting a Build Failure Threshold

To automatically fail your build for serious issues, just add the <failBuildOnCVSS> parameter to your pom.xml. This small change embeds a minimum security standard directly into your build process.

For example, if you set the value to 7.0, the Maven build will fail whenever a dependency has a known vulnerability with a CVSS score of 7.0 or higher.

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.2.0</version>
    <configuration>
        <!-- Fails the build if any dependency has a CVSS score of 7.0 or higher -->
        <failBuildOnCVSS>7.0</failBuildOnCVSS>
    </configuration>
    ...
</plugin>

This simple addition acts as a powerful gatekeeper, forcing the team to address critical and high-severity vulnerabilities immediately instead of letting them pile up in a backlog.

The Challenge of Managing False Positives

Let’s be realistic: no automated scanner is perfect. You will inevitably run into false positives—alerts for vulnerabilities that don’t actually apply to your project. This might happen if the scanner misidentifies a library or flags a flaw in a part of a dependency you don’t even use.

Dealing with these is critical. If your reports are flooded with irrelevant noise, your team will quickly develop “alert fatigue” and start ignoring everything. The goal is to create a clean, actionable report by systematically suppressing known false positives.

A clean report is a trusted report. Investing time in suppressing false positives pays off by ensuring that when a real alert appears, your team takes it seriously. It’s all about achieving a high signal-to-noise ratio.

Creating and Using a Suppression File

The OWASP plugin gives us a robust way to handle this: the suppression file. It’s just an XML file where you define rules to ignore specific CVEs for certain dependencies.

First, create a file named dependency-check-suppressions.xml. I usually put this at the root of the project or in a dedicated /config directory to keep things organised.

Next, you need to tell the plugin where to find this file. Add the <suppressionFile> tag to your configuration in the pom.xml.

<configuration>
    <failBuildOnCVSS>7.0</failBuildOnCVSS>
    <suppressionFile>dependency-check-suppressions.xml</suppressionFile>
</configuration>

Now for a practical example. Imagine the scanner flags CVE-2022-12345 in example-library-1.0.jar. After looking into it, your team confirms it’s a false positive because your application never calls the vulnerable part of the library’s API.

To suppress this specific alert, you would add an entry to your dependency-check-suppressions.xml file like this:

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
   <suppress>
      <notes><![CDATA[
      File: example-library-1.0.jar
      This CVE is related to the library's X-feature, which we do not use.
      Risk is confirmed to be zero. Suppressed by J. Doe on 2023-10-27.
      ]]></notes>
      <cve>CVE-2022-12345</cve>
   </suppress>
</suppressions>

This entry does two crucial things:

1. It tells the scanner to ignore CVE-2022-12345 from now on.
2. The <notes> section provides essential context, explaining why it was suppressed and by whom. This kind of documentation is invaluable for future audits and for anyone on the team who might wonder about it later.

By carefully managing your configurations and suppressions, you can transform the maven dependency check from a generic scan into a precise and reliable part of your secure development lifecycle.

Automating Dependency Checks in Your CI/CD Pipeline

Running a manual maven dependency check is a solid first step, but the real win comes when it’s an invisible, non-negotiable part of your team’s daily rhythm. This is where your Continuous Integration/Continuous Deployment (CI/CD) pipeline comes in. Integrating vulnerability scanning directly into your CI/CD transforms security from a periodic, manual chore into an automated habit that catches vulnerabilities before they even touch your main branch.

When you’re ready to automate, choosing from the Best CI/CD Tools is an important decision. For this guide, we’ll use GitHub Actions because it offers a clean, straightforward way to build a powerful security gate. The objective is simple: scan every single pull request and fail the build if a new, high-severity vulnerability pops up.

A Practical GitHub Actions Workflow

Here’s a complete, ready-to-use YAML configuration for a GitHub Actions workflow. This script automatically triggers on every pull request targeting your main branch, runs the OWASP dependency check, and archives the HTML report so you can review it easily.

name: 'Security Scan on Pull Request'

on:
  pull_request:
    branches: [ main ]

jobs:
  owasp-dependency-check:
    runs-on: ubuntu-latest
    steps:
    - name: 'Checkout Code'
      uses: actions/checkout@v4

    - name: 'Set up JDK 17'
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: 'maven'

    - name: 'Cache OWASP NVD Data'
      uses: actions/cache@v4
      with:
        path: ~/.m2/repository/org/owasp/dependency-check-data
        key: ${{ runner.os }}-owasp-nvd-${{ hashFiles('**/pom.xml') }}
        restore-keys: |
          ${{ runner.os }}-owasp-nvd-

    - name: 'Run OWASP Dependency Check'
      run: mvn -B org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7.0

    - name: 'Archive Dependency Check Report'
      uses: actions/upload-artifact@v4
      if: failure()
      with:
        name: dependency-check-report
        path: target/dependency-check-report.html

Notice the caching step for the NVD database? That’s a critical performance optimisation. It makes initial scans take a minute, but subsequent runs are dramatically faster, ensuring the check doesn’t become a bottleneck.

What to Do When the Pipeline Fails

When a vulnerability is found, your CI pipeline acts as a security gatekeeper, forcing a decision. This is a good thing. The process from here is usually quite straightforward.

The flow is simple: the build fails, and your team must decide whether to fix the issue, suppress a known false positive, or formally document and accept the risk.

Automated checks are especially important for compliance frameworks like the EU’s Cyber Resilience Act (CRA). The cascading nature of Maven dependencies means a single vulnerable library can pull in dozens of other high-risk CVEs. With over 30 million known relationships in the Maven ecosystem, these risks spread incredibly fast, making automated CI/CD checks a practical necessity.

When a pull request fails the dependency check, don’t just override it. Treat it as a genuine bug report. The archived HTML report is your first stop for diagnosis. It contains all the context needed to understand the vulnerability and start planning a fix.

Automating these scans isn’t just about catching bugs; it’s about building a security-first culture. When developers get immediate feedback, they learn to consider the security baggage of their dependencies right from the start. To dig deeper into this mindset, you can check out our guide on Git and CI/CD best practices. By making the maven dependency check an automated gatekeeper, you ensure security is always part of the conversation.

Frequently Asked Questions

When you start working with a new security tool like the OWASP Maven dependency check, a few practical questions always pop up. As teams get it wired into their daily workflows, some common challenges and queries are bound to surface. This section tackles the most frequent ones with clear, real-world answers.

How Can I Speed Up the Initial OWASP Dependency Check Scan?

The very first scan you run will always be the slowest—don’t be surprised if it takes several minutes. This is because the plugin has to download the entire National Vulnerability Database (NVD) to build a local cache for its analysis. The good news is that subsequent scans are much, much faster because they only need to pull down the latest updates.

To make a real difference, especially in a CI/CD pipeline, you need to set up a persistent data directory. Inside your pom.xml, find the plugin’s <configuration> block and add the <dataDirectory> tag. The trick is to point it to a location outside your project’s target folder. This stops the cache from getting wiped every time you run a mvn clean command.

On your CI server, the best practice is to cache this data directory between pipeline runs. If you do this, the plugin will only download new NVD data, slashing scan times from minutes down to just a few seconds.

You might also notice warnings about a missing NVD API key. The plugin works without one, but you’ll be running into NIST’s heavy rate-limiting for anonymous requests (around 5 requests per 30 seconds). If you register for a free NVD API key, that limit jumps to 50 requests per 30 seconds—a tenfold increase that makes a huge difference in how fast your NVD data updates.

It’s easy to configure in your POM by referencing an environment variable:

<configuration>
    <nvdApiKey>${env.NVD_API_KEY}</nvdApiKey>
</configuration>

What Is the Difference Between the Check and Aggregate Goals?

This is a critical distinction, particularly for larger projects. Whether you use check or aggregate comes down entirely to your project’s structure.

• The check goal is built for single-module projects. It only analyses the dependencies of the specific module it’s run in. If you run it from the root of a multi-module project, it will simply ignore all the child modules.
• The aggregate goal is what you need for multi-module projects. When you run it from the parent project’s root directory, it recursively scans the dependencies across all sub-modules and spits out a single, comprehensive report.

Using aggregate is almost always the right move for any non-trivial application. It gives you a complete, unified view of your entire project’s vulnerability surface, which is essential for accurate risk assessment and prevents dangerous blind spots.

How Do I Handle Vulnerabilities in Transitive Dependencies?

Transitive dependencies—the libraries your direct dependencies pull in—are a classic source of vulnerabilities. The OWASP report will flag them, but fixing them takes a bit of detective work.

Your first move should be to find out which direct dependency is bringing in the problematic library. The mvn dependency:tree command is your best friend here. It prints out a full tree of your project’s dependencies, making it easy to trace exactly where that vulnerable JAR is coming from.

Once you’ve found the culprit, check if a newer, patched version of that direct dependency is available. Upgrading it is the cleanest solution. If there’s no update, your best bet is to use Maven’s <dependencyManagement> section in your pom.xml to explicitly override the transitive dependency’s version with one you know is safe.

For instance, if library-A is pulling in vulnerable-lib-1.0, you can force Maven to use vulnerable-lib-1.2 (the fixed version) by adding this to your <dependencyManagement> block:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.example</groupId>
            <artifactId>vulnerable-lib</artifactId>
            <version>1.2</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Just remember to run your full suite of regression tests after a change like this. Forcing version overrides can sometimes introduce unexpected breaking changes.

Can I Use This Tool for Non-Maven Projects?

Absolutely. While this guide is all about the Maven dependency check plugin, the OWASP Dependency-Check project is a versatile toolset that supports a wide range of ecosystems.

The project comes in several different flavours:

• A powerful command-line interface (CLI) that can scan any directory of dependencies, making it a great fit for nearly any project type.
• Dedicated plugins for other major build systems, including Gradle and Ant.
• Integrations for popular CI servers like Jenkins.

The core scanning engine and vulnerability data sources are the same across all versions. That means you get the same high-quality analysis and protection no matter what your tech stack looks like, giving you a consistent way to manage dependency security across your whole organisation.

---

Navigating vulnerability management is a core requirement for CRA compliance, and getting it right is crucial. Regulus provides a structured platform to map these security obligations, manage documentation, and turn compliance requirements into an actionable roadmap for your product teams. Learn how Regulus can help you prepare for EU regulatory deadlines.