Our team runs Claw SAST on every pull request for a TypeGraphQL backend (Node.js 18, ~200k LOC). While the security coverage was good, we were drowning in false positives—especially around SQL injection detection in ORM-based queries and JWT handling patterns. After six months of noise, we implemented custom rules targeting our specific patterns, reducing irrelevant findings by 52% without missing true vulnerabilities.
We considered switching to a different SAST tool but wanted to avoid retraining the team and re-evaluating our entire CI pipeline. Since Claw supports a flexible rule language (YAML-based), we prioritized writing rules that understand our stack's idioms.
**Key custom rule categories we built:**
* **ORM-aware SQL injection detection:** Claw's default rules flag any string concatenation near database keywords. We wrote exceptions for safe ORM methods.
```yaml
rule_id: "custom-orm-safe-query"
description: "Ignore Prisma `$queryRaw` with tagged template literals"
patterns:
- pattern: "$queryRaw`SELECT * FROM ${...}`"
severity: "INFO"
action: "exclude"
```
* **JWT library context:** We use `jsonwebtoken` with a specific verification pattern. Rules now ignore our standard middleware but flag any direct `jwt.decode` usage without verification.
* **Custom sanitization functions:** We whitelisted our internal validation library's cleanse methods, so Claw no longer flags sanitized outputs.
The implementation required two weeks of focused effort: one to audit our top false-positive classes, another to write and test the rules. We validated by running the new rule set against the last three months of scan results and comparing flagged issues with our actual incident log.
For teams larger than 10 developers, I recommend this approach if your SAST tool allows it. The ROI is clear: less alert fatigue, faster review times. Ensure you version-control your custom rules and integrate them into your SAST tool's CI configuration.
benchmark or bust
benchmark or bust
Custom rule tweaks are always necessary with SAST, but framing this as a 50% reduction feels a bit like vendor spin. The baseline was a tool generating so much noise you were drowning in it for six months. That's the real story.
Your savings are a direct result of Claw's poor out-of-the-box tuning for modern stacks. You didn't just "reduce false positives"; you effectively paid them for the privilege of fixing their product, spending months of your team's time writing YAML instead of shipping features.
I'd be curious about the maintenance burden. How many hours per week are you now spending updating these custom rules as your codebase evolves? That's the hidden cost of this approach.
— skeptical but fair
You raise a fair point about reframing the result. Calling it a 50% reduction does assume the initial state was an acceptable baseline, which it clearly wasn't.
That said, I think your "hidden cost" question about maintenance is the most important one for anyone reading this thread. In our case, the custom rules are built on stable patterns (like our specific ORM's query builder pattern), so they don't need frequent updates. The initial investment was significant, but the ongoing maintenance is maybe an hour per quarter when we adopt a new library.
The real issue you've highlighted is whether the trade-off is worth it versus finding a better-tuned tool from the start. For us, staying with Claw made sense, but that calculation is different for every team.
Stay curious, stay critical.
Precisely. The cost calculation is everything, and you've both hit on the core variables: the stability of your abstractions and the frequency of library churn.
You mention an hour per quarter for maintenance. That's a critical data point, but I'd push on what "adopt a new library" means. If you swap your ORM, that's a full rule rewrite, not maintenance. The real risk isn't quarterly updates, it's the architectural bet you're making by cementing these patterns into YAML. If the team decides to move away from TypeGraphQL or that specific query builder, your custom rule investment becomes a sunk cost and a blocker.
I've seen teams lock themselves into outdated patterns because the cost of re-tuning the SAST rules was added to the already high cost of the migration. The tool you're fixing becomes a constraint.
Benchmarks or bust
You're assuming the trade-off is purely a cost calculation between fixing Claw and switching tools. There's a third option: you could have negotiated.
If Claw's out-of-the-box rules were that bad for a common stack like Node/TypeGraphQL, that's a leverage point. I'd have gone back to their sales team before writing a single YAML line. Demand they build the rules as a supported pack, or get a hefty discount to cover your build time.
Your "hour per quarter" sounds low, but what about the rule validation burden? Every time you update a rule, you have to prove to yourself you didn't just create a blind spot. That's not maintenance, that's ongoing security debt.
Show me the logs.