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?
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