Anyone else dealing with Amazon Q Developer flagging their own, reviewed code as a security vulnerability? It's becoming a noise generator in our PRs. We're using it for Java (Spring Boot) code analysis.
Example from a recent build:
```java
// Simple string concatenation for a log message
String userAction = "User " + userName + " performed action: " + actionId;
LOG.info(userAction);
```
Q flagged this as "Potential log injection." No user input here is unsanitized; `userName` and `actionId` are validated internal UUIDs and strings from our auth context.
* Is this just a sensitivity/config issue?
* Can you tune the rules without disabling checks entirely?
* How does this compare to GitHub CodeQL or GitLab SAST on false positive rate for custom code?
Looking for practical fixes, not theory.
It's a common pain point with SAST tools, especially when they don't have enough context about your data validation upstream. The tool sees string concatenation with variable values and throws the flag.
You can often tune these rules, but the granularity varies. In Q Developer, look for a way to mark specific validation patterns or trusted data sources. Sometimes annotating the method parameters with @NonNull or similar can help the analysis engine. Compared to CodeQL, I've found Q can be a bit more eager out of the box, but CodeQL's custom query writing is a steeper hill to climb for reducing false positives.
For that specific log line, a pragmatic fix might be to wrap the variables in a dedicated logger method that explicitly denotes them as sanitized, just to quiet the alarm. It's not ideal, but it cuts the noise.
—HR
Ah, the classic "annotate it into submission" approach. Sure, sprinkling @NonNull might quiet Q down for a moment, but you're just teaching the linter, not fixing the tool's fundamental blindness to your app's context.
Wrapping sanitized data in a special logger method is a band-aid that creates more code to maintain, just to appease a bot. The real irony is that now you've got a codebase littered with "trust me bro" markers because the SAST can't infer what a developer can see at a glance.
CodeQL's learning curve is steep, but at least its custom queries let you encode your actual validation logic. With Q, you're often stuck with their opaque, one-size-fits-all heuristics. The "eagerness" you mention feels less like thoroughness and more like a lack of configurability.
FOSS advocate
Preach. You're hitting on the exact frustration that turns a useful guardrail into background noise. I call it "alert fatigue by configuration."
The parallel in cloud cost tools is hilarious - you get flagged for a "spike" that's just your Tuesday batch job, so you end up creating a million custom CloudWatch dashboards and cost anomaly exclusions. You're not managing infrastructure anymore, you're just training the bot to ignore your normal schedule. Same energy.
There *is* a middle ground, but it's rarely in the UI. With AWS's own cost anomaly detection, the real tuning happens in the CLI or by tagging everything to death. I bet Q has similar buried JSON configs where you can define actual data flow boundaries, not just slap annotations on symptoms. The trick is finding the doc that isn't just marketing fluff.