Security Hotspots are not marked (in editor) or reported (in Security Hotspot View) in Visual Studio. It seems this was discussed before:
And the feature removed:
As far as I can tell the rationale being that this issues should be reviewed by human (Security Auditor). The workflow we’re using would greatly benefit if developers could be notified of the potential issues (as they do for non-security related potential bugs). All of those are reviewed by humans as well. the benefits being:
Developers can proactively remove security issues themselves.
Developers learn about potential security issues.
Adding comment about the shortens the code reviewing process.
The whole workflow is optimized as currently we’re discovering these potential issues very late in development process.
Currently we can see the issues in the Sonar portal, click open in IDE. Then the issue is underlined and added to the list. After restarting the IDE, the issues are no longer underlined and no longer in the list. I’m guessing an option to populate and keep the list would not be that hard to add?
Is there any other rationale for not having this feature (or option) I’m not aware of?
Hi @GoranSiska and welcome to the SonarSource community!
Thanks for the submitting this request, I agree with your reasoning - in fact supporting Security Hotspots in the IDE does make sense, moreover it is something we are already considering and there are chances we’ll work on this during 2022. You can find two features ideas around Hotspots in SonarLint roadmap page:
If you subscribe to those cards, you’ll get notified when there will be updates on them.
The workflow for Hotspots is a little different w.r.t. to code issues; for example when a Security Hotspot is detected, I don’t expect a developer to immediately stop coding in order to review the Hotspots; I’d rather review all the new Security Hotspots in my project from time to time, for example before committing or before sending a Pull request; in other words Security Hotspots deserve a dedicated UX design and this is one of the reasons why we introduced them in SonarQube and SonarCloud first. On the other hand, we do not believe that only Security Auditors should be in charge of reviewing Hotspots, at the contrary we’re promoting a developer-led approach on security (you can read more here ), and by bringing Hotspots to SonarLint we’d help the very people introducing Hotspots - developers - to review them and fix if needed, as early as possible in the development process.