How do I avoid developers to bypass SonarQube rules using NOSONAR
as mentioned in the SonarQube documentation - FAQ it will suppress/ bypass the issue by simply typing //NOSONAR at the end of the line since, developers are having access to write code in a file, they are adding that word in every line.
Let’s say we have a scenario –
There is a code (a line) that I want to mark it as false positive or won’t fix, what options do we have in SonarQube? as per my observation issues which are marked as won’t fixed or false positive in the lower branch example Dev branch will get reopened in the UAT higher branch. We don’t want to fix the same issues again and again since it was already marked as false positive in Dev branch “Lots of repetitive work”. if you suggest NOSONAR or @SupressWarning to bypass that line of code/file, then it is a loophole in SonarQube because anybody can bypass Sonar analysis.
We need a more granular way of doing it.
I need your attention on “How do we avoid developers to use NOSONAR”.
In all seriousness: when you say “anybody” can bypass analysis, who is contributing to your project? “Anybody” can also add code to send user passwords to their Russian botnet or format your hard drive – maliciously avoiding quality analysis falls into the same category. It’s a people/management problem. I would argue that this falls outside the scope of this forum.
There is a rule implemented for 8 languages to allow you to track use of NOSONAR: C, C++ PL/SQL, T-SQL, PHP, COBOL, Objective-C, Java. You probably want to add it to your relevant Quality Profiles.
If you’re concerned with other languages, please list them.
Don’t you think anybody stands for developers doesn’t matter junior, senior, or architect, My question to you is that why should I use SonarQube ? when it can be bypassed by any dev.
We are using SonarQube for understanding our code specifically bug, duplications, code smells etc. right?
Maybe you are right its a management problem, what solution do you have apart from
Since in the SonarQube FAQ, it is clearly available and I really don’t want to track how many people are bypassing, it’s not the solution again it’s a problem.
I don’t think so you have read my question I have mentioned we need a more granular way of doing it, maybe a feature where only senior or architect developers can bypass it, even we don’t want to bypass so all we want is a way where if I fixed something in dev env then it should automatically replicate in higher env (UAT) when PR is raised.
I apologize if my snarky comment came off as rude rather than silly, but I do maintain that this is a business problem with a business solution. The point is that inline NOSONAR statements are in code because they are code, just like anything that executes on the server or in a client – this just happens to be code that affects how your static analysis runs. So, you should use the same business process to prevent the introduction of unwanted NOSONAR statements that you do to prevent the introduction of any other bad / unwanted code.
Maybe that’s a formal code review, maybe it’s the PR workflow you use for approving changes. If you have a team divided into junior/senior positions and you’re worried about junior devs adding a NOSONAR to get a “clean build”, make a formal (business!) policy that all NOSONAR statements must be accompanied by a comment explaining why it’s needed, and set up an approval workflow where the reviewer enforces the policy. There are dozens of books out there on git workflows for organizations of varying sizes, if you need help with that.
If you still aren’t happy with this and want an automated solution, what would that look like? As Ann mentioned, there are rules to create a Sonar issue when somebody uses a NOSONAR flag, but if you’re getting a Sonar issue either way, wouldn’t it make more sense to set up a pre-commit hook to reject any use of it at all? At least that way, you get an issue for the actual code and you have the opportunity to explain why the flagged section isn’t an issue using Sonar’s comment system.
