[NEW PLUGIN] dependencycheck - Requesting inclusion in SonarQube Marketplace

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?

2 Likes

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

2 Likes

Hi @ganncamp,

we worked hard to make this plugin better. Can you please review our plugin again.
The plugin is now located under an other organization. https://github.com/dependency-check/dependency-check-sonar-plugin

Hi Philipp,

as a fellow community member (not afiliated with SonarSource), I had a quick look at the documentation and stumbled over this definition:

Vulnerable Component Ratio
(vulnerabilities / vulnerableComponents)

So if I have 10 artifacts in my dependency tree and 2 are vulnerable because they each have 3 vulnerabilities, the ratio would be 6 / 2 = 3 = 300%? Note that the 10 does not appear in the formula.

Either I’m misreading the definition, or this value is not very useful. I would expect a definition that (for the numbers above) leads to a value of 20% (because 2 out of 10 artifacts are vulnerable), or maybe 60% (because 6 total vulnerabilities in 10 total artifacts), though that seems less intuitive.

Best regards,
Jens

Hi Jens,

thanks for looking to the plugin. You missunterstand the calculation. Every vulnerability has at least one vulnerable component. A vulnerable component in general is a CVE number (e.g. CVE-2018-11307, CVE-2017-7525). So if you have a project with 10 artificats in your dependency tree and 2 are vulnerable, because they each have 3 vulnerable components, the ratio would be 2/6 = 0,333333333 = 33%. It’s correct that the 10 doesn’t appear in the formula.

A higher percentage indicates that a large number of components(artifacts) contain vulnerabilities. Lower percentages are better.

Best regards,
Philipp

Hi Philipp,

Nice work! I’m touched to see that you took my advice to heart! In fact, it looks like you followed every one of my recommendations. :blush:

Double-checking the bureaucratic requirements, since you’ve moved the project and it has been a year:

  • I’m not seeing release notes on your versions…?
  • I need you to point me to SonarCloud analysis (the old project isn’t being analyzed any more)

Also, and this one is new since your initial request, I need a PR on the metadata repo, as described in the docs

After we’ve checked off those things, I think you’re good to go! :smiley:

FYI, I’ll be gone from the 18th to the 6th. If you can turn those things around to me before then I’ll do my best to get this processed before I leave for the holidays. If not, and if I don’t come back to you within the first couple weeks of January, please @ me to bring my attention back to this thread.

 
Ann

Hi Ann,

Thanks for reviewing this plugin again.
We have a separate CHANGELOG.md. Is that acceptable?

Link to SonarCloud analysis -> https://sonarcloud.io/dashboard?id=dependency-check_dependency-check-sonar-plugin

Currently I’m working for a better nodejs integration. I would create a PR on the metadata repo, if that feature is released.

Happy new Year and best regards
Philipp

Hi Philipp,

Happy New Year!

If I’m looking at a release on your repo, how am I supposed to get from there to the appropriate section of your changelog? For that matter, aren’t you just working your issues? If so, I suspect the GitHub workflow makes it really easy to collect a ticket list for each release, and looking at your manual changelog I think that would save you some work…

But I guess you could just add a link to your release that went to an anchor in the changelog.

Okay, so when that release is ready we’ll move forward (assuming you’re still passing your QG on SonarCloud. :smiley:)

 
Ann

Hi Ann,
thanks for your fast response. I have setup github-release drafter, the integration seems really good. Thanks for the hint.

I’ll notify you, when the release is ready.

Philipp

1 Like

Hi Ann,
the release is out. I created a PR in metadata repo: https://github.com/SonarSource/sonar-update-center-properties/pull/85
Travis fails because of an android plugin. Is this related to my PR?

QG is still green :smiley:

Philipp

Hi Philipp,

The failure is unrelated to your plugin, but is instead related to the archiving of old SonarQube versions. It has been fixed and the Marketplace updated.

 
:smiley:
Ann

Edit I mixed up my threads/plugins. You’re not in - yet. I’ve asked for changes on your PR.

Wow! This has been a long time coming.

YOU’RE IN!

 
:joy:
Ann

1 Like

Thanks Ann for your help and your patience :smiley:

Hello, my understanding is that the dependency checker plugin is available only for SonarQube. Can you please clarify ? Does that mean that we won’t have OWASP-Dependency-Check in SonarCloud ? We have private projects and SonarCloud license. Thank you

Hi @acnaa77,

That’s correct. SonarCloud only runs SonarSource-provided analyzers.

 
HTH,
Ann