Open StFS opened 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.
@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).
@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?
@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.
@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.
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
SonarQube version: 7.0
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:So is there any way to make the sonar-bitbucket-plugin realize this problem?