Just read that provocative blog post making the rounds, "SonarQube isn't a SAST tool." The core argument seems to be that SonarQube is primarily a *code quality* and *maintainability* platform, and its security findings are more of a beneficial side effect, not a dedicated SAST suite.
This got me thinking about my own automation setups. I often pipe SonarQube results into other systems, and I've noticed the security rule coverage feels... different. For example, when I compare it to a dedicated SAST tool in a workflow, the findings are often about code smells that *could* lead to vulnerabilities, rather than pinpointing active exploits.
My typical glue-job looks something like this: using n8n to fetch SonarQube issues via webhook, then filtering and routing them.
```json
// A simplified n8n node for filtering SonarQube webhook data
{
"operation": "filter",
"fields": {
"type": "string",
"value": "SECURITY_HOTSPOT, VULNERABILITY"
}
}
```
But the blog post claims this is missing the point. It suggests we should treat SonarQube's security output as a robust quality gate that *indirectly* improves security, rather than a primary vulnerability scanner.
So my practical question for anyone else integrating it into their pipelines:
* Are you adjusting your automation logic to de-prioritize SonarQube for direct security alerts?
* Are you combining it with a true SAST tool downstream, and if so, how are you deduplicating or reconciling findings?
* Has this changed how you set your Quality Gate thresholds? Maybe focusing more on Reliability/Maintainability metrics for the gate, and treating Security findings separately.
Feels like a shift in how we're supposed to architect our review workflows. Curious if the community's automation scripts are evolving because of this perspective.
if it's manual, it's wrong