[NEW PLUGIN] dependencycheck - Requesting inclusion in SonarQube Marketplace


(Brad Flood) #1

Hello,

We would like to request addition of the dependency-check-sonar-plugin to the SonarQube Marketplace.

Description: Integrates Dependency-Check reports into SonarQube
Home page url: https://github.com/stevespringett/dependency-check-sonar-plugin
key: dependencycheck
SonarCloud url: https://sonarcloud.io/dashboard?id=org.sonarsource.owasp%3Asonar-dependency-check
Issue Tracking: https://github.com/stevespringett/dependency-check-sonar-plugin/issues
Plugin Binary URL: https://github.com/stevespringett/dependency-check-sonar-plugin/releases

This plugin has been under development for over three years. I believe the plugin meets the technical requirements outlined here.

Are there any questions or concerns that we can address now, before we cut our next release?


(G Ann Campbell) #3

Hi,

We can check off the bureaucratic requirements for this plugin. I’ve stepped through them and they look good.

I have some concerns about your examples, and what I see in SonarQube as a result of them.

First, the single-module example pins a rather old version of the Maven analyzer that’s now 404. Once I removed that plugin, I was able to analyze by taking your README instructions with a grain of salt.

You wrote:

mvn clean dependency-check:check
mvn sonar:sonar

But with the modern versions of SonarJava which are shipped with modern versions of SonarQube, you must provide binaries to analysis. So you have to do some variation of this instead

mvn clean dependency-check:check
mvn install sonar:sonar

On a similar note, your multi-module example advises this workflow

mvn clean dependency-check:check
sonar-runner

Again, you’ve got to get a compile in there somewhere, but also it makes no sense to me to advise analysis with the vanilla SonarQube Scanner when the Maven scanner handles so much of the boilerplate configuration for you.

Beyond that, once I ran analysis on the single-module project I got this in the measures space:

As a user, I have no idea what this is or what I’m supposed to do with it.

Let’s just posit that your example project had included some High Severity Vulnerabilities (not a bad idea…). What would I see here? Just a number at the top and no details, like with Total Dependencies? And if so… what am I as a user supposed to do with that?

As it stands, I wouldn’t be comfortable adding this to the Marketplace because I fear the user experience would be poor at best.

I suggest that you consider restructuring this slightly. SonarJava runs some rules against pom files. Why don’t you use the same methods to raise issues against the pom file(s)? Ideally you’d raise them on the lines holding the problem dependencies, but if nothing else, you could raise them at file level. That would allow you to raise Blocker (High Severity), Critical (Medium Severity), and Major (Low Severity) Vulnerabilities against the project, which would have a far more visible impact on the project homepage and also give users some idea of where to go to address the problems. Having the opportunity to set an issue message also gives you the ability to reference the particular CVE or provide other relevant information.

 
Ann