SonarCloud properly decorates bugs, vulnerabilities, and code smells in Azure DevOps pull requests. But it doesn’t add any comments about security hotspots.
Is there a way to configure SonarCloud to also decorate security hotspots?
If there isn’t then can some security hotspots be saved as vulnerabilities as a workaround? This question raised because we used to have the S1525 rule (“debugger” vulnerability in TypeScript) that has been marked as deprecated and became a part of a security hotspot now which is not decorated in pull requests.
@mickaelcaro - has there been any updates on including security hotspots in Azure DevOps pull requests?
We are trying to shift as many issues to the left as possible and notifying developers of newly introduced security hotspots in a PR as soon as possible would be ideal.
FYI, the company I work for is in the middle of a 14 day trial of sonarcloud and this is something that has been brought up.
Hi @robatilho and thank you for your message.
We are currently in the process of reevaluating the relevance of throwing Security Hotspots in PR.
Why?
Because we consider that Security Hotspots are not issues, they are points of attention. We already know that it might be nothing, but we still want to draw your attention. And this is different than issues (code smells, bugs, vulnerabilties, etc) where we know for sure that there is something wrong.
Keeping that in mind, I’d be interested in knowing why your developers still want them in PRs.
Here is the proposed scenario and workflow that brought me here.
A developer hard codes a username and password into a checked in configuration or hard coded in c#. We would like for that to automatically flag in a PR for that particular security hotspot in order for the developer to be alerted as soon as possible.
While I understand the desire to reduce noise for developers, having the ability to enable Security hotspots in PRs would be ideal.
@Christophe_Havard - Ideally, it would be nice to set it as a global organization setting (I don’t think these exist?) that projects can inherit from and then possibly enable/disable it on the project level should there be a reason for that particular project.
We utilize the Azure DevOps Sonarcloud extension for our YAML CI pipelines. I can see value in being able to set it on the fly as an extra property in the task: SonarCloudPrepare@1extraProperties input field.
Thanks for your input @robatilho , that’s helpful
If you have 2min, we are currently running a survey related to security hotspots in PR. Would you be able to take a look? https://forms.gle/Zyyi9TH397tkXt2P8
I’d also be very much interested in adding security hotspots to the PR. We can configure which rules to apply and the security gate levels. Additionally the PR decoration only applies to what has changed. It would be good to shift left and force reviewers to check the potential issue and provide either a fix or a justification in resolving the comment before a merge can proceed
Hi!
I also just noticed that the security hotspots don’t show up as PR annotations. I think it’s important that developers are made aware of this as soon as possible and that they have to at least give a reason as a comment in PR.
Are there any updates on the subject?
Hi ,
I have also the same question, is there any update on the subject ?
have a clear understanding of the reason why Quality Gate failed is important, and I believe PR annotation is the way to mention it. hence, security hotspots should be added also .
Thanks
