Security Hotspot decoration in Azure DevOps pull requests

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.

4 Likes

Hi @kron,

No this is not currently possible.
We will assess the need to bring them back onto PR since they live their own life now.

You can try to convert them as vulnerability yes, but that’s not something we support in terms of best practice for sure.

HTH,
Mickaël

@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.

1 Like

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.

Thanks. Kind regards,
Christophe - DevOps platforms PM

1 Like

Hey Chris,

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.

Thanks!

2 Likes

Thanks for your feedback @robatilho , it’s super valuable :slight_smile:

having the ability to enable Security hotspots in PRs would be ideal.

Do you consider it necessary to be able to disable them on-the-fly?

@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@1 extraProperties input field.

3 Likes

Thanks for your input @robatilho , that’s helpful :slight_smile:
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

Thanks!
Christophe

1 Like

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

1 Like

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?

1 Like