To resolve code issues, nothing is more powerful than concentrating on new code. Hence why we are promoting the Clean as You Code methodology. For Security Hotspots, there is no reason to not follow the same workflow and to not review them as soon as they are introduced. This is why we will help developers follow this process in the context of pull requests with
At SonarSource, we struggled in 2019 to review Security Hotspots raised on our code by our own analyzers until we started to enforce Security Reviews on New Code and until we made it a mandatory step, enforced by a condition in our Quality Gates.
- As a developer, I want to make sure all my New Security Hotspots are reviewed before I accept that a new piece of code is merged into "master" (the main branch).
- At SonarSource, we want to share best practices through concepts implemented in SonarQube, in particular that reviewing New Security Hotpots helps increase the Security Review Rating with a small investment.
It's possible, since SonarQube 8.2, to configure the Quality Gate to fail if there are open New Security Hotspots. It's also possible to set a threshold for the level of "Security Review Rating On New Code" to A, B, ...
The default Quality Gate "Sonar Way" should be updated and the following condition added:
By doing so, we will share with our community (that is trusting us by relying on the "Sonar Way" QP) what is the SonarSource's recommended way to review Security Hotspots: focus first on the HS introduced in new code.
Update the default Quality Gate "Sonar Way"
The default quality gate needs to be changed so that it includes a condition based on the new metric.
The condition should fail the Quality Gate if the % of Security Hotspots reviews is less than 100%.
Upgrade notes should mention this change to the default QG so that people using the default QG are not surprised by QG failing due to the new condition.