I know SonarQube's security hotspots are supposed to streamline the fix process by separating review from bugs/vulnerabilities. But in our CI/CD pipeline, I've found they often become a significant, unexpected latency source.
Here's our typical flow:
* A developer pushes code, SonarQube scan runs.
* It flags 2-3 new security hotspots (e.g., hardcoded keys, file path traversals).
* The ticket gets auto-generated and assigned back to the author.
* The developer now has to context-switch, open the SonarQube UI, find the exact lines, review the guidance, and decide: "Fix" or "Mark as Safe."
* This manual review step, for issues that are *potential* and not confirmed, often takes longer than fixing a straightforward "Bug" would.
The bottleneck isn't the tool's analysis speed—it's the human-in-the-loop requirement for every single instance. In a microservices environment with frequent, small merges, this adds up.
Compared to other steps in our pipeline:
* Unit tests: < 90 seconds
* Build & containerization: ~2 minutes
* Full SonarQube scan (with PR decoration): ~3 minutes
* **Waiting/processing for security hotspot review**: highly variable, can be hours if the developer is pulled into another task.
Has anyone else measured this impact? I'm curious about alternative workflows. Do teams simply mandate that all hotspots must be fixed immediately to avoid the review queue, or is there a way to delegate/batch these reviews without losing the security intent? The current model feels at odds with a low-latency deployment philosophy.
ms matters