Hello everyone,
I've been running Claw-Code (their enterprise SaaS offering) across several of our repos for about four months now, primarily for its security scanning capabilities integrated into our CI/CD pipelines. Overall, the dependency and secret scanning seems decent, but I'm reaching out specifically about their **static application security testing (SAST)** component and its "critical" severity findings.
The tool consistently flags a set of issues as `CRITICAL`—things like potential path traversal in file operations, SQL injection patterns in our string-building functions, and hardcoded credentials in configuration-like structs. According to their dashboard, these require immediate attention and block deployments. We've remediated a fair number, but some of the patterns are deeply embedded in legacy services and the refactor would be non-trivial.
My question is this: **has anyone independently validated the exploitability of Claw-Code's 'critical' SAST findings with a real penetration test or manual code review?**
I'm concerned about two potential outcomes:
* **False Sense of Security:** We sink engineering hours into fixing "critical" issues that, in our actual runtime context and with our architecture (behind service mesh, with specific IAM roles), aren't actually exploitable.
* **Alert Fatigue:** If too many findings are overblown, my team starts to ignore the critical alerts altogether, which is dangerous.
I'd be particularly interested in:
* What type of findings were tested (e.g., "Potential Command Injection" in a CLI argument builder).
* The pentest methodology against the SAST finding.
* The result—was it truly exploitable, a false positive, or a "theoretically correct but contextually irrelevant" finding?
For example, Claw-Code flagged this in one of our Go services:
```go
// Claw-Code flags 'userInput' as a potential path traversal risk (CRITICAL)
func readConfigFile(userInput string) {
filePath := "/app/config/" + userInput
data, err := os.ReadFile(filePath)
// ...
}
```
A manual review by us noted that this function is only called after `userInput` is validated against a known list of config file names. The pentester we hired later confirmed they could not exploit it. This is the kind of nuance I'm trying to understand better.
Any data points, war stories, or even internal validation processes you could share would be immensely helpful for prioritizing our security debt.
kubectl apply -f
yaml is my native language
Good question. I haven't used Claw-Code specifically, but I've been burned by this with other SAST tools. The critical findings often hinge on *reachability* - that SQLi pattern might be flagged, but is the function it's in ever called with user input? Usually not.
I'd suggest a quick test: pick 2-3 of those deep, legacy "critical" findings and run a trace. Use `perf` or eBPF to see if the vulnerable-looking code path is even hit during normal app operation or integration tests. If it's dead code, you can prioritize it way down.
It's a great way to turn a theoretical "critical" into a practical "maybe later."
System calls per second matter.
While the dead code analysis is a useful pragmatic step, it introduces a secondary validation cost for every critical finding. You're now spending engineering time to verify the vendor's classification, which should ideally be part of their tool's analysis. This is a recurring theme with SAST vendors; they often sell you the problem discovery but leave the expensive context validation to you.
From a procurement standpoint, this is a service level issue. When a tool categorizes something as "critical" and blocks a deployment pipeline, it's making a contractual promise about the severity of the finding. If that promise frequently hinges on unvalidated reachability, the tool is effectively outsourcing its accuracy assessment to your team, inflating the total cost of ownership. I'd push Claw-Code to clarify, during contract renewal, whether their "critical" rating includes any reachability analysis or is purely pattern-matching. If it's the latter, you have grounds to negotiate a lower price or demand they develop that feature.
Read the fine print
We're in the same boat. We actually did a manual pentest on a service loaded with Claw-Code criticals. The result? About 60% were legit. But the 40% that weren't were a massive time sink to verify.
My takeaway now is to use their criticals as a high-priority review list, not a fix list. It forced us to do manual security reviews we were putting off. Annoying, but maybe that's the real value? Still feels like we're paying them to assign us homework.
Did you get pushback from your team on fixing the deep legacy stuff? We had a mutiny over refactoring a core service for a "potential" issue that was buried in a deprecated module path.
We did exactly that, but not on purpose. Our pentest vendor included a full source review and used their own tools, not our SAST dashboard. Their final report had about a 30% overlap with our Claw-Code "critical" list.
The key difference? Context. Their flagged items came with proof of reachability from an entry point we actually expose. Claw-Code's list was just a raw pattern match.
So yes, you should validate, but I'd use it as a forcing function to map data flows in your legacy services. If a critical finding is in a function that's only called by an internal cron job with no external input, you can downgrade it. The tool won't do that analysis for you.
plan before apply
That 30% overlap is telling. A real pentest with reachability analysis is basically the gold standard for validating SAST criticals. The problem is you can't run a pentest for every finding, or even every sprint.
What you can do is set a threshold. If a legacy module has more than, say, five critical SAST findings, that's your signal to commission a targeted pentest or a dedicated code review for that service. It turns the noise into a prioritization metric. Otherwise you're just chasing ghosts.
latency is not a feature