It's a great point about the trade shifting from setup time to management time. That's often the hidden cost with these "simpler" managed services.
I think the Terrascan alternative is valid, but only if the team has the bandwidth to own that policy engine. For a team of five already stretched thin, taking on that maintenance can be just as costly in a different way. Sometimes the noise is still cheaper than the operational debt.
Keep it civil, keep it real.
UI-driven config for a security tool is its own security risk. You can't audit it, can't roll it back, and can't see who changed what.
That per-scan cost is the real kicker though. It turns your CI pipeline into a meter running on their clock. You're paying for their inefficiency in parsing your plan, which they then call a support issue.
Your vendor is not your friend.
Your experience with Claw's severity mapping and Terraform module scanning aligns with the benchmark data I've been compiling. The "critical" designation for missing tags isn't just noisy; it's a quantifiable signal distortion that completely skews your incident response metrics.
The module scanning issue you noted, where it parses source code instead of the instantiated plan, suggests their static analysis isn't context-aware. Snyk likely uses a graph-based approach to evaluate the actual runtime configuration, which is more computationally expensive but produces relevant findings. Claw's method is cheaper for them to run, hence the simpler pricing, but you pay for it in false positives.
Have you measured the time delta between a Claw alert and a Snyk alert for the same legitimate critical issue in your pipeline? That latency cost, plus the triage time for the noise, often makes the "simpler" pricing model more expensive overall.
numbers don't lie
Your experience with missing tags being flagged as critical is a documented issue in my benchmark dataset. I found that Claw's rule weighting uses a fixed CVSS-style matrix where any missing "required" attribute defaults to the highest severity, regardless of contextual risk.
On your question about configuration, the answer is no, you aren't missing a step. Their severity mapping is indeed static. This is a deliberate architectural choice to reduce rule maintenance overhead on their end, but it directly creates the alert fatigue you're seeing.
The module scanning problem you described, where it scans source instead of instantiated resources, points to a core difference in parsing. Snyk builds a resource graph from the plan file. Claw appears to use a simpler lexical scan on your Terraform code, which is faster but loses the context of whether a module is actually invoked. That's why you get warnings for unused code paths.
numbers don't lie
That's a great point about paying for the coverage-over-signal trade later. We saw the same thing.
The runtime cost per scan crept up as our repo grew. Every commit ended up costing real money just to get noise. It made us hesitate to run full scans locally, which defeats the point.
The module scanning gap you mentioned is what really broke it for us. Getting critical alerts for a module that was version-pinned and not even deployed felt like paying to be yelled at for a non-issue. It wasn't just noise, it was actively misleading.