The recent Security Hotspots feature is one that I would like to use as part of our Pull Request process; however, the only branch where the Security Hotspots can be viewed is our project’s master branch (a.k.a. post merge of a PR).
Ideally I would like to have PR reviewers able to see all Security Hotspots that are a part of the changed portions of the feature branch and make assessments on all of them prior to approval and merge to master.
When viewing any branch results other than master the Security Hotspots filter is greyed out.
Is there a setting that I’m missing to enable Security Hotspots for review on feature and merge branches?
There is no hidden feature to activate the “Security Hotspot” facet on PR. “Security Hotspots” are only available on Branches/Master, this is per design.
“Security Hotspots” are targeting Security Auditors, a position that may not exist inside a team/company and that is generally provided by specialized companies. We believe it would slow down the merge velocity if you need to request a review of the Security Hotspots before being authorized to merge. Also, you may not have enough files in the PR to decide if there is a security risk while reviewing a Security Hotspot.
In a nutshell, we could activate this feature, but we did not because we believe most of the developers will consider this as noise or won’t know what to do with these type of issues highlighting security-sensitive pieces of code.
FYI: Security Hotspots are also not visible on IDEs thru SonarLint.
Hi Alex,
Thanks for the response. It would be tremendously helpful if there were an option that would enable the Security Hotspots feature for feature branches. While a reviewer may not have the full view in the PR window, our reviewers always have access to the full source code and can dig to make sure that all is in order at the time of the pull request. To the greatest extent possible, we want to catch security issues prior to being merged into any of our long running branches.
Being able to see the flagged security hotspots prior to merge would be a tremendous help to streamlining our pull request checklist as it would be built into a tool that we are already using.
I hope you and your team will consider at least making this an option, if not the default.
Thanks,
Dave Wolff
(Also, I have seen security hotspots in the IntelliJ SonarLint tool and I actually like seeing them there until they are marked as a non-issue)
I agree with @David_Wolff, we would like the option for security hotspots to be reviewed before code gets merged into master.
In the meantime, is there a suggested workflow for security auditors to be notified of these new security hotspots? The notification settings do not seem sufficient for this scenario.
Update on this thread: we are about to start making security hotspots first class citizens, and therefore have them on PR for review => https://jira.sonarsource.com/browse/MMF-1653
This should meet your needs
Thanks again for your feedback!
Any comments on this suggestion? I too would love to see Security Hotspot in SonarLint as well because we are writing a SonarQube plugin that does not just flag vulnerabilities but also security hotspots as well. Somehow that feature was there but then taken away by some people’s opinions https://github.com/SonarSource/sonarlint-visualstudio/issues/727. How about making it optional (with a check box to show Security Hotspot or not) instead of taking it away?
@Alexandre_Gigleux@Fabrice_Bellingard
I found the answer in your response. However, I added the reasoning of the other side in the previous thread so you can understand why we need it. Also, making it optional is also a way to resolve this and satisfy the needs of both side. One does not use it but other one needs it (like @David_Wolff and I and potentially many other devs)
Hi @ToanKst, you might have seen that we recently started an effort to make security hotspots first class citizens. So I believe that at some point we’ll make them available in SonarLint too, because obviously the sooner developers are aware of a sensitive piece of code, the easier it is for them to review it and potentially fix it. However, this needs to be carefully thought in terms of user experience, because security hotspots are by nature different from other issues.
