mibexsoftware / sonar-bitbucket-plugin

SonarQube plug-in to create pull request comments for found issues in Bitbucket Cloud
Other
122 stars 72 forks source link

Adding a vulnerable dependency in a PR does not trigger a warning comment by the plugin #79

Open StFS opened 6 years ago

StFS commented 6 years ago

Expected Behavior

I just set up this plugin as part of our Jenkins / SonarQube / Bitbucket / java+gradle setup. I tested it by creating two pull requests, one who had vulnerable code (InputStream that wasn't being closed properly) and another where I added a new library dependency (which was not in the project before and not a part of any transient dependency) that I know has a reported vulnerability on it (I fixed the version to a vulnerable one). The library that was added is "org.apache.hadoop:hadoop-client:2.7.0" which has multiple CVE reports on it (https://nvd.nist.gov/vuln/search/results?adv_search=true&form_type=advanced&results_type=overview&query=Apache+Hadoop&queryType=phrase).

I would have expected both PRs not to be approved by this plugin. The first one because of the code vulnerability and the second one because of the library vulnerability.

Actual Behavior

The first PR (with the code vulnerability) does not get approved by the plugin and comments are added in proper places to indicate the vulnerabilities involved.

However, the second PR gets approved with only a comment that everything is fine and I should have a chocolate.

Plug-in version, SonarQube version, CI system, build type

Plug-in version: 1.2.3 image

SonarQube version: 7.0 image

CI system: Jenkins

Build system: gradle

I have the dependency-check plugin (version 1.1.0) installed in SonarQube.

When I run ./gradlew :dependencyCheckAggregate I can see that the dependency-check plugin actually picks up the library that I added and knows about the vulnerability. See relevant output:

Found 206 vulnerabilities in project gorsm

One or more dependencies were identified with known vulnerabilities:

[...]
hadoop-annotations-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-annotations:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-auth-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-auth:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-client-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-client:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-common-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-common:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-hdfs-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-hdfs:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-mapreduce-client-app-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-mapreduce-client-app:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-mapreduce-client-common-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-mapreduce-client-common:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-mapreduce-client-core-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-mapreduce-client-core:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-mapreduce-client-jobclient-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-mapreduce-client-jobclient:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-mapreduce-client-shuffle-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-mapreduce-client-shuffle:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-yarn-api-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-yarn-api:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-yarn-client-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-yarn-client:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-yarn-common-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-yarn-common:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-yarn-server-common-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-yarn-server-common:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
hadoop-yarn-server-nodemanager-2.7.0.jar (cpe:/a:apache:hadoop:2.7.0, org.apache.hadoop:hadoop-yarn-server-nodemanager:2.7.0) : CVE-2017-3166, CVE-2017-15713, CVE-2016-5393, CVE-2016-5001, CVE-2016-3086, CVE-2015-7430
[...]

See the dependency-check report for more details.

So is there any way to make the sonar-bitbucket-plugin realize this problem?

StFS commented 6 years ago

I'm wondering whether this issue, #58 and #70 are all the same thing?

Does this plugin not report any "project level issues"?

@mrueegg can you comment on this? I'd really appreciate some feedback on this and whether there is any chance for us to fix this problem.

mrueegg commented 6 years ago

@StFS Hi. Could you please describe what you mean by "project level issues"? The plug-in only adds comments for issues on file-level and which are found on changed lines of the code (pull request diff).

StFS commented 6 years ago

@mrueegg thanks for your reply.

What I mean by project level issues is something like I describe in the issue description above.

I have a Java/Gradle project and one of my PR adds a library that has a known vulnerability. The change certainly has a file and a line number but the way SonarQube performs the scan, it doesn't associate this new issue with a specific file or line number (which would be the line in the gradle file where the vulnerable library dependency is added)... rather, the new issue that's found is just a generic issue with the project... it is now using one more vulnerable library than it was before the PR.

So I would have liked to see this plugin report that as a top level comment on the PR since there is no way for it to figure out that the library is being added by the change to the gradle build file.

But maybe I'm mistaken... maybe your plugin isn't getting any information about that there is a new library vulnerability?

mrueegg commented 6 years ago

@StFS Thanks for your feedback. AFAIK, we can only access Sonar issues on file-level inside a plug-in but not issues on the project-level. I'll investigate this in more detail and get back to you soon.

StFS commented 6 years ago

@mrueegg thank you. Much appreciated. I'm more than willing to help out if I possibly can. I tried looking at the source code but had very limited time and couldn't quite pinpoint how SQ issues were being passed into your plugin.