With the recent addition of the Security Hotspot issue type, we started seeing many issues that require code review with acknowledgment. Such issues usually start with a "Make sure ..." comment from SonarQube, such as "Make sure this file handling is safe here.". As the SonarQube documentation specifies:
Security Hotspot rules are purposefully designed to draw attention to code is security-sensitive. It is expected that more than 80% of the issues will be quickly resolved as "Won't Fix" after review by a Security Auditor
The problem is that when such issues occur in dev branches with the preview analysis mode, the build fails because of the Security Hotspot issues and there is no way to go to SonarQube and say "Won't Fix", because the changes are not merged to the master yet and issues are raised in the preview mode.
Is there a way to say that Security Hotspot issues should not fail the build, without reducing their criticality, so that the Security Auditor can go to SonarQube and acknowledge that no fix is required?
+1 for this issue.
Our workaround is to add // NOSONAR everytime we encounter that kind of issue, that goes against the purpose of Security Hotspot rules.
With the recent addition of the Security Hotspot issue type, we started seeing many issues that require code review with acknowledgment. Such issues usually start with a "Make sure ..." comment from SonarQube, such as "Make sure this file handling is safe here.". As the SonarQube documentation specifies:
The problem is that when such issues occur in dev branches with the preview analysis mode, the build fails because of the Security Hotspot issues and there is no way to go to SonarQube and say "Won't Fix", because the changes are not merged to the master yet and issues are raised in the preview mode.
Is there a way to say that Security Hotspot issues should not fail the build, without reducing their criticality, so that the Security Auditor can go to SonarQube and acknowledge that no fix is required?