We are using OWASP Dependency Check tool during our sonar scan run. We do define it as a sonar scan parameter using the sonar.dependencyCheck.htmlReportPath parameter. However, it seems like this report itself is scanned by SonarQube which is not expected… Do I really need to explicitly add this report to the exclusion patterns list? I thought since sonar scanner is aware of it, it would understand not to scan it and treat it as “our code”? I don’t remember this being an issue earlier, so not sure what has changed… We have updated the Dependency Check version, but the filename of the report generated is the same so I don’t think it should matter, we have never had to exclude this file manually
EDIT. Found these in the CI/CD log mentioning the file. I honestly don’t know if these help or not, but here they are…
Report was generated just before dotnet scanner end (not sure why there is a dot in the path…)
[INFO] Writing HTML report to: /builds/ppcloud/ppx/Tests/./dependency-check-report.html
[INFO] Writing JSON report to: /builds/ppcloud/ppx/Tests/./dependency-check-report.json
$ dotnet sonarscanner end /d:sonar.login=$SONAR_TOKEN
It is mentioned as a “Test path” in post processing
INFO: Indexing files of module 'Tests'
INFO: Base dir: /builds/ppcloud/ppx/Tests
INFO: Test paths: dependency-check-report.html, dependency-check-report.json, obj...
INFO: Excluded sources: **/Migrations/*.sql, TestResults/**/coverage.opencover.xml
INFO: Excluded sources for coverage: ./**/**, ../Backend/StorageManager/Migrations/**/**, ../Tools/**/**, ../Examples/**/**
This could be something??
WARN: Missing blame information for the following files:
WARN: * Tests/dependency-check-report.html
WARN: This may lead to missing/broken features in SonarQube
This doesn’t have a bearing on the problem at hand. And it may be helpful if you added the file to your .gitignore file.
In fact… that would kill two birds since we read your Git exclusions to automatically ignore some files.
In fact, without going code-diving, I suspect this is how we avoid analyzing as code most of the reports we import: they’re generated to automatically-ignored directories, or are already listed in .gitignore.
Interesting point about the .gitignore file… We probably don’t have it there, as it is never “close” to being committed as it is only generated during CI/CD run.
I did get it working by using the sonar.test.exclusions property. It was apparently being recognized as a test file for some reason. This is what I used to work around the issue (parameter to dotnet sonarscanner begin: /d:sonar.test.exclusions="**/**/dependency-check-report.*".
That being said, this definitely was not needed earlier and I have no clue what has changed as we have not changed anything in CI/CD. We may have updated the sonarscanner version fairly recently but I feel like the issue arouse last week whereas we bumped that before christmas… The SonarQube Server version may have changed, as that is in the hands of our IT department.
I will check if the .gitignore-way would work instead. It would be a bit tidier than start listing files in the CLI command, if we get similar issues with other files…
@ganncamp is most probably right. Your scanner must have been upgraded from pre v8 to v8 or v9, and this file was automatically discovered and analyzed.
We purposefully ignore some well-known HTML/JS artifacts (coverage reports), but we were not aware of this one. We do rely on .gitignore to weed out artifacts, and on manual exclusions as a last resort.
I will add that to our backlog so we can try and add an automatic exclusion in a future version. Thanks for reporting this!
As mentioned in the original post, we are using dotnet sonarscanner 9.0.2. I checked the git log and it seems like I did bump this tool version from 6.2.0 -> 9.0.2 in one go, though this was back in 26th of November of last year. It is of course possible we just did not notice it for a month…
Thanks for noting this and adding it to the backlog!
I will also add that I believe this report should actually be supported as an input (maybe via plugin on the SQ server) to the sonar scan itself. Due to this fact, I assumed that it would be automatically ignored in the scan, as I am explicitly giving it as input to the dotnet sonarscanner begin command:
dotnet sonarscanner begin /k:<hidden>
.......
/d:sonar.dependencyCheck.jsonReportPath=Tests/dependency-check-report.json
/d:sonar.dependencyCheck.htmlReportPath=Tests/dependency-check-report.html
.......
I have inherited this CI/CD pipeline around two years ago and have not touched this command at all, so I am not sure exactly about the situation for the dependencyCheck plugin support and availability on our SQ server personally (we have jumped instance). Anyway, from there you see I give it as an input to the tool, which is why I thought that it would also be implicitly ignored.
PS. Is there any way to see what plugins an instance have, without instance admin access? Or do I just need to ask our IT to ensure the Dependency Check SQ Server plugin is available on our new instance?
Okay, thank you. I did not mean you should now about the tool in particular, I just thought that all files that were given as parameters to the scanner would be automatically ignored somehow, no matter what plugin they actually go to. It was just a theory
Nice to hear though that this tool’s output could be supported as default ignored in the future
