What is a security hotspot?

It is a piece of code that touches something security sensitive, like a password check, a database query, or a piece of encryption. It is not automatically a bug. Someone has to read it and decide whether the code is safe in its particular context, which is exactly why hotspots pile up.

How is this different from a security bug or vulnerability?

A vulnerability is a confirmed problem and usually shows up on your quality gate, so it gets attention. A hotspot is a judgement call that sits quietly in a review queue until a person makes a decision, so it can go untouched for months without anyone noticing.

Will this flood our GitHub with issues?

No. It creates at most five new issues per run, and it reads the existing open issues in each repository first so it does not file the same hotspot twice.

Do we need a paid SonarCloud plan?

Any plan that lets you view your projects will work, including the free tier for public projects. You just need a login with access to the projects you want covered.

What happens if a hotspot turns out to be fine?

A reviewer marks it as reviewed and safe in SonarCloud, and it drops out of the waiting queue. Later runs will not raise it again, so closing things out genuinely shrinks the backlog.

SonarCloud security hotspot chaser for GitHub and Slack

Every weekday at 9am, run on a cron trigger and chase down the SonarCloud security hotspots that are still sitting unreviewed, so they do not stay in the TO_REVIEW queue forever.

Start by finding the hotspots that need attention. Use the SonarCloud "Projects — Search" operation to list the projects in our organization, then use "Hotspots — Search" filtered to status TO_REVIEW for each project. For every hotspot that comes back, use "Hotspots — Show" to pull the full detail, including its security category, its file path and line, and the date it was raised.

Prioritize what you found. Rank by vulnerability probability, taking HIGH first, and within that favour anything that has been waiting more than 14 days. Keep the framing right: a hotspot is a judgement call rather than a confirmed bug, so the goal is to get a human to make a decision, not to claim something is broken.

For the top few, file GitHub issues. Before creating anything, call the GitHub "List Repository Issues" operation on the target repository and scan the open issues so you do not file a duplicate for a hotspot that has already been raised. Then use "Create an Issue" in the repository the hotspot belongs to. Each issue must state the file path, the line number, the security category (for example SQL injection or weak cryptography), a link back to the hotspot in SonarCloud, and the specific question the reviewer has to answer, such as whether the input reaching this query is already validated or whether this algorithm is acceptable for this data. Create at most five new issues per run so the backlog never gets flooded.

Finish by posting one consolidated summary to our security channel using the Slack Bot "Send a Message" operation. Include the total number of hotspots still awaiting review, name the repositories carrying the oldest unreviewed hotspots and how long they have been waiting, and list the issues you just created with links. Post a single message rather than one per hotspot. If there was nothing new worth filing, still post a short status so the team knows the queue was checked.

What it does

Checks your SonarCloud projects each weekday morning for security hotspots that are still waiting on a human review
Ranks them by how likely they are to be a real risk, putting the highest risk and longest waiting items first
Opens a GitHub issue in the right repository for the top few, spelling out the file, the line, and the exact question a reviewer needs to answer
Posts one consolidated summary to your security channel in Slack, naming the repositories sitting on the oldest unreviewed items
Caps itself at five new issues per run so nobody wakes up to a flooded issue tracker

What you’ll need

A SonarCloud login that can see the projects you want covered
A GitHub account with permission to create issues in the relevant repositories
A Slack workspace with your bot added to the channel you want the summary posted in
A channel where your security or engineering team actually reads updates

How to customize it

Change the timing, currently 9am on weekdays, or the channel the summary is posted to
Raise or lower the cap of five new issues per run as your backlog shrinks
Adjust the fourteen day waiting threshold, or widen it to include medium and low likelihood items

Use cases

Daily Digests
Notifications & Alerts

Daily chase-up for unreviewed SonarCloud security hotspots

Integrations

Type

Categories

What it does

What you’ll need

How to customize it

Use cases

FAQs

Related prompts