# dependency-check-sonar-plugin: feeding OWASP findings into SonarQube as issues

> The Dependency-Check SonarQube plugin reads a JSON report produced by OWASP Dependency-Check and turns its findings into SonarQube issues, metrics, a weighted Inherited Risk Score and a Vulnerable Component Ratio, for SonarQube Server 2025.x and up. It suits a pipeline that already scans dependencies and wants the results in the dashboard, and it does nothing if you have not run a scan.

**dependency-check/dependency-check-sonar-plugin** — Integrates Dependency-Check reports into SonarQube

- Repository: https://github.com/dependency-check/dependency-check-sonar-plugin
- Stars: 696 · Forks: 149
- Language: Java
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dependency-check-dependency-check-sonar-plugin

## It reads a report, it does not scan anything

The most important sentence in the project documentation is the note under the heading about Dependency-Check itself: this SonarQube plugin does not perform analysis, rather, it reads existing Dependency-Check reports. You have to use one of the other available methods to scan project dependencies and generate the necessary JSON report, which can then be consumed by the plugin.

So the shape of the integration is two tools in sequence. Dependency-Check, the OWASP utility that detects publicly disclosed vulnerabilities in project dependencies, runs the scan and writes a JSON file, and the plugin reads that file and turns its contents into SonarQube issues.

Dependency-Check itself works by determining whether there is a Common Platform Enumeration identifier for a given dependency, and if it finds one, it generates a report linking to the associated CVE entries. It supports the identification of project dependencies in a number of different languages including Java, .NET, Node.js, Ruby and Python.

That division of labour has a consequence worth stating plainly. If your pipeline does not already produce a Dependency-Check report, this plugin does nothing for you, and no amount of configuration will change that. The plugin is a translator from one report format into a code quality platform's issue model, and it is deliberately not a scanner.

The ecosystem section lists what Dependency-Check is available as: a command-line utility, an Ant Task, a Gradle Plugin, a Jenkins Plugin, a Maven Plugin and a SonarQube Plugin. So the scanner side has a wide range of entry points, and the SonarQube plugin is one peer among them.

## The metrics are the interesting part, and the Inherited Risk Score is a weighted sum

The plugin keeps track of a set of statistics, and the readme lists them plainly. The total number of dependencies scanned, the total number of vulnerabilities found across all dependencies, the total number of vulnerable components, and the total number of critical, high, medium and low severity vulnerabilities.

Two of those are defined as their own metrics, and they are where the design thinking shows.

The Inherited Risk Score is a weighted sum:

```java
 (high * 5) + (medium * 3) + (low * 1)
```

The readme is careful about what this number means. It is simply a weighted measurement of the vulnerabilities inherited by the application through the use of vulnerable components, and it does not measure the application's actual risk due to those components. The higher the score, the more risk the application inherits. That caveat is the whole point of the metric, since the components in question are usually inherited rather than chosen, and a quality gate that treats a transitive library finding as equivalent to a flaw in your own code would be unworkable.

The Vulnerable Component Ratio is vulnerabilities divided by vulnerableComponents, expressed as a percentage, and the direction of good is stated too: a higher percentage indicates that a large number of components contain vulnerabilities, and lower percentages are better. It answers a different question from the IRS. The score tells you how bad the findings are, and the ratio tells you how spread out they are across your dependencies. A project with one library carrying many CVEs and a project with a dozen libraries carrying one each can produce a similar score and a very different ratio.

## Installing the plugin and pointing it at a report

The install is a file copy or a Marketplace install, and the documentation gives both.

Copy the plugin jar file to $SONAR_INSTALL_DIR/extensions/plugins and restart SonarQube, or install it via the SonarQube Marketplace. Ready to use binaries are available from the GitHub releases page, and the compiling instruction is a single command, mvn clean package.

Using it is three steps in the documentation's own phrasing. You create aggregate reports with Dependency-Check, Dependency-Check outputs a file named dependency-check-report.json, and the plugin reads that existing JSON report.

The configuration parameter is a path to that file:

```ini
sonar.dependencyCheck.jsonReportPath=${WORKSPACE}/dependency-check-report.json
```

The example assumes a Jenkins workspace, and the documentation notes it can easily be altered for other CI/CD systems.

There is one wrinkle that catches people out, and the documentation calls it out directly. The plugin tries to add SonarQube issues to your project configuration files, for example pom.xml, the gradle files or package-json.lock, and you have to make sure those files are part of sonar.sources. If they are not, the issues get created but have no file to attach to, which in most dashboards means they do not show up where you expect.

The plugin is versioned against SonarQube rather than on its own schedule, and the compatibility table is explicit about it.

## Version compatibility is a table, and the guidance is to use the newest

The compatibility table is one of the more useful pieces of documentation in this repository, because the plugin is tightly bound to a platform it does not control.

The guidance is stated before the table: use the newest version, and keep in mind that the plugin only supports the latest SonarQube LTS version and the latest non-LTS version. The table then gives the history.

Plugin version 6.0.0 and up works with SonarQube 2025.x and up. Version 5.0.0 works with SonarQube 10.2 to 10.8. Versions 4.0.0 to 4.0.1 work with SonarQube 9.9 LTS to 10.2, and 3.0.0 to 3.1.0 with 8.9 LTS to 9.9 LTS. Below that, 2.0.6 to 2.0.8 with 7.9 LTS to 8.9 LTS, 1.2.x to 2.0.5 with 7.6 to 7.9 LTS, 1.1.x with 6.7 LTS, and 1.0.3 with 5.6 LTS.

Two things follow from that. First, the plugin is a fast follower of the platform, so an upgrade of SonarQube is also a decision about this plugin, and the readme is telling you to upgrade both together. Second, the range is narrow by design: only the latest LTS and the latest non-LTS are supported, which in practice means a SonarQube version that is one cycle behind is already outside the support window for the newest plugin, and an organisation that lags on SonarQube upgrades has to stay on an older plugin release as well.

The release history matches the table's shape. The most recent release is 6.0.0 from 2025-08-22, before it 5.0.0 from 2024-02-27 and 4.0.1 from 2023-12-12, and the last push to the repository was on 2026-10-15 with the repository not archived.

## Severity mapping, summarising, hotspots and the skip switch

The optional configuration parameters are where you decide how findings land in your dashboard, and each one has a documented default.

The severity thresholds let you set the minimum score for each severity, and a score of -1 completely disables a severity:

```ini
sonar.dependencyCheck.severity.high=7.0
sonar.dependencyCheck.severity.medium=4.0
sonar.dependencyCheck.severity.low=0.0
```

Those three numbers are the SonarQube severity scale boundaries, so the mapping from a Dependency-Check severity to a SonarQube issue severity is a threshold on that scale. Leaving them alone gives you the platform's default mapping, and -1 is the escape hatch for a severity you do not want to see at all.

The summarize option is the one that changes the shape of the result. In large projects you have many dependencies with, hopefully, no vulnerabilities, and this configuration summarizes all vulnerabilities of one dependency into one issue. The default is false, which means one issue per vulnerability.

The securityHotspot option is for teams that want a review process rather than a defect list, and it works with Security-Hotspots to enable a review process in your team. The skip option turns the plugin off, and the useFilePath option makes the plugin use the complete jar file path instead of the name, which matters when you have several versions of the same dependency in one build.

## Where dependency-check-sonar-plugin is the wrong tool

The first limit is the one the project states most prominently. If you have no Dependency-Check report, the plugin has nothing to work with, and the scanner is a separate project with its own documentation, its own setup and its own runtime cost. Dependency-Check maintains a large vulnerability database, and the scanning step is the expensive part of this pipeline, not the translation.

The second is what the Inherited Risk Score is not. The readme says outright that it does not measure the application's actual risk due to those components. A quality gate keyed on IRS treats every transitive finding as equal weight regardless of whether your code calls the vulnerable function, and the score is a count with weights, not a model of exploitability. Teams that set a threshold on it will find themselves either blocked by a finding they cannot fix or ignoring the gate.

The third is the version coupling in practice. Only the latest SonarQube LTS and the latest non-LTS are supported, so the plugin's release cadence is dictated by SonarQube's, and a team that upgrades SonarQube quarterly has to upgrade the plugin in the same window or pin the older one. The 6.0.0 release is from August 2025, which tells you the major version line has not moved for over a year, which is a slower cadence than the platform.

The fourth is the issue-to-file attachment. The plugin tries to add issues to your project configuration files, and those files have to be in sonar.sources. A project whose build files are generated, or excluded from analysis, will produce issues that cannot be located, and the documentation's instruction to make sure they are included is a real operational dependency rather than a formality.

The fifth is the licensing, and it needs care. The licence is recorded as not classified, and the project documentation states that permission to modify and redistribute is granted under the terms of the LGPLv3. It also carries two separate copyright statements, one for the Dependency-Check Sonar Plugin and one for Dependency-Check itself, which is the usual arrangement for a plugin that ships another project's output but worth reading rather than assuming.

## Conclusion

dependency-check-sonar-plugin is worth adding to a pipeline that already runs OWASP Dependency-Check and needs the results visible where the team already looks, because it converts a report into issues, quality gate metrics and a severity mapping you can tune, without a second dashboard. It is the wrong tool if you have no scanner running, since the plugin explicitly does not perform analysis, and it is the wrong tool if you want the findings fixed rather than tracked. Before you deploy it, check the three things the documentation is explicit about: that the plugin version must match your SonarQube version, with 6.0.0 and up requiring SonarQube 2025.x and up, and the instruction to use the newest version and the latest SonarQube LTS plus the latest non-LTS release; that the JSON report path has to point at the file Dependency-Check actually writes, dependency-check-report.json, and that the project configuration files the plugin tries to attach issues to must be part of sonar.sources; and that the severity thresholds default to the SonarQube scales, with a score of -1 disabling a severity entirely, so a mapping you do not think about becomes a mapping you inherit.

## FAQ

### Does the dependency-check-sonar-plugin scan my dependencies itself?

No. The project documentation states that this SonarQube plugin does not perform analysis, it reads existing Dependency-Check reports. You need to run Dependency-Check through one of its other integrations, such as the command-line utility, the Gradle Plugin, the Maven Plugin or the Jenkins Plugin, to produce the JSON report the plugin consumes.

### Which SonarQube versions does the dependency-check-sonar-plugin support?

The guidance is to use the newest version and to keep in mind that the plugin only supports the latest SonarQube LTS version and the latest non-LTS version. The compatibility table maps 6.0.0 and up to SonarQube 2025.x and up, 5.0.0 to SonarQube 10.2 through 10.8, and earlier plugin versions to earlier SonarQube releases.

### What is the Inherited Risk Score in the dependency-check-sonar-plugin?

It is a weighted sum of the vulnerabilities inherited through vulnerable components, calculated as (high * 5) + (medium * 3) + (low * 1). The documentation is explicit that it does not measure the application's actual risk from those components, only how much risk the application inherits, so a higher score means more inherited risk.

## Sources

- [dependency-check/dependency-check-sonar-plugin on GitHub](https://github.com/dependency-check/dependency-check-sonar-plugin)
- [Issues](https://github.com/dependency-check/dependency-check-sonar-plugin/issues)
- [README](https://github.com/dependency-check/dependency-check-sonar-plugin/blob/master/README.md)
- [Releases](https://github.com/dependency-check/dependency-check-sonar-plugin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dependency-check-dependency-check-sonar-plugin