Security Hotspot Workflow

I’d like to advocate a change to the Security Hotspot review workflow. It would be beneficial to be able to resolve a hotspot as a vulnerability type issue. With the review done, the reviewer uses own judgement in the context of the project to formally note it’s a must-be-fixed item.

Based on the discussion in

it seems like there’s ongoing development. Is there a development roadmap you can share?


Hi @keith_CLSC

Indeed, the security-hotspot workflow has recently changed, the documentation too and we are currently working to improve security-hotspots rules.

The intention with security-hotspots is to suggest additional layers of security controls/protections that can increase, depending on the context, the security of the application, such as the use of:

  • httpOnly/secure flags for cookies.
  • CSP http headers.
  • prepare statements when querying databases.
  • auto-escaping template engines features.
  • etc.

Security-hotspots are no longer vulnerabilities, you can “fix” them if you think, for instance the httpOnly flag for a newly created cookie is relevant in the context of your application or close them as “safe” in the opposite case.

About the 5 rules mentioned in the other topic:

  • Make sure that executing SQL queries is safe here.
  • Make sure that this http request is sent safely.
  • Make sure this file handling is safe here.
  • Make sure that exposing this HTTP endpoint is safe here.
  • Make sure that using a regular expression is safe here.

Only one (about SQL queries/dynamical queries/prepare statements) will be kept without major changes the others will be deprecated or completely improved to better adapt to the new security-hotspot workflow.


Thanks for the quick feedback. The issue I’m raising is related to the current workflow (in version 8.3). The workflow as described seems to assume the reviewer is the developer, and not strictly a reviewer. There’s no option to state that the Hotspot has been reviewed and needs to be fixed, it’s either “fixed” or “safe”. I want to be able to conduct my review and then assign the worrying Hotspot to a bug or vulnerability based on my evaluation. I’d like to be able to set the Security Hotspot as “reviewed” with a link to the new issue. Having only the ability to conclude a Hotspot review as “fixed” or “safe” is limiting.

1 Like

@keith_CLSC, let’s say you found a security-hotspot, as a reviewer, that needs to be fixed:

You can add a comment, to explain to developers why you think it should be fixed:

Then, you can assign the security-hotspot to a specific developer:


The developer will be notified and start a discussion with you, then if everything is clear he will agree to fix the security-hotspot and will change the status to “fixed” when it is done.

Does this cover your use case?

PS: As I said before, hotspots are not vulnerabilities, I’m sure you are bothered by the current workflow because the existing hotspot rules mostly target the old workflow, it will be easier, in your case, to see the value of the new workflow when we will deprecate some existing hotspots and replace them with new ones very soon.


We are facing the same issue and would also like to see a 4th status option like “ToBeFixed” or something like that (I can live with Reviewed).
In our case we would add a Jira ticket link in the comments.

Adding that status is very important to us for internal workflow but also for security reporting.
It seems fundamentally flawed to set it to Fixed or Safe since that is not the truth. It is also not in state ToReview since it has been reviewed.