We have Jenkins that uses the SonarQube extension and scan the project.
In the properties, the developers are allowed to set sonar.exclusion and provide folders/files to exclude. Thus giving developers freedom to exclude any of the source code files as per their choice, thus posing a security risk of few files being excluded which may contain a vulnerability from being scanned. Is there a feature in SonarQube where this can be centralized and controlled by security team or overridden by the config on SonarQube dashboard configurations set by security team, or by other means?
1 Like
Hi,
Welcome to the community!
In fact, you’re the first person in recent memory to push for centralizing this on the server. Most people cite “configuration as code” and want to specify every aspect in the properties file.
While I do advise people to do their configuration on the server, there’s no way to enforce that.
The only thing you can do, as I see it, is to audit the exclusion settings that were applied server-side.
You’ll find docs on the web service that feeds that data to the UI in the Web API link in the page footer. You may toggle ‘Show internal API’.
HTH,
Ann
Hi Ann,
@swetan27 raises a very important point.
As Sonarqube Enterprise admin for several years now, i’ve learned:
you must activate the Track uses of “NOSONAR” comments rule
you must also activate the Track uses of “@SuppressWarnings” annotations rule with an appropriate
whitelist that only contains code smells but no rules with severity CRITICAL.
Our developers are mostly eager to keep their code clean, but there are also external developers involved with their own opinions. Some don’t give a shit on our styleguide and claim they know better.
From the rule description of the Track uses of “NOSONAR” comments rule =
Any issue to quality rule can be deactivated with the
NOSONARmarker. This marker is pretty useful to exclude false-positive results but it can also be used abusively to hide real quality flaws.
This “but it can also be used abusively to hide …” is also relevant to the sonar.exclusion property,
which may be used i.e. in pom.xml for maven builds.
To be sure it’s not used abusively i need to check whether:
sonar.exclusions is used
and
sonar.exclusions has more than the global exclusions or the project exclusions.
If this is the case i would need to break the pipeline.
This should be more convinient for Sonarqube admins, means i’m pushing for centralizing this on the server, otherwise it opens the gates for abuse.
Gilbert
Hi Gilbert,
Thanks for chiming in. We’ve started tracking this need internally, and the more users we hear from, the easier it will be to prioritize it.
Ann
Hi Gilbert,
That ticket is about server settings, not analysis settings. I’m not aware of anything (yet) that would address this concern. And as I pointed out above, it’s now a bit of a tug-of-war. For a couple years now people have been demanding configuration-as-code: “let me set everything in analysis properties” and now we’re seeing the other side of the coin: “nothing should be configurable via analysis properties”. So this becomes a Big Topic probably requiring some Deep Thinking because both sides have valid points.
Ann
And BTW, we’re considering providing analysis configuration reporting. I know there aren’t details here yet. They should come soon:
Ann