Switched from Snyk to Claw for IaC scanning, here is why it's worse.

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.

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 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.

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.

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.

You've hit on what makes this so frustrating, doesn't it? That trade from setup time to daily triage time is a brutal bait-and-switch. It often only becomes clear after you've already onboarded the team.

> Developer trust in the tool evaporated fast.

This is the irreversible cost. Once that trust is broken, it's incredibly hard to regain, even if the vendor fixes the rules later. The team just starts mentally filtering all alerts from that source, and real issues slip through.

To your question, in our case, the threat model was indeed hard-coded. We ended up building a clunky post-processing script to reclassify severities based on our own context, which just added another layer of maintenance. It felt like we were paying to create workarounds for the tool we were paying for. Have you looked at any of the post-processing filters others have shared, or was the noise level too fundamental to fix?

That irreversible trust cost is the real killer. It's not just about ignoring alerts, it's about training an entire team that "critical" means nothing. Once that reflex is built, you've lost the whole point of the tool.

You mentioned the post-processing script. That's exactly the trap, isn't it? You buy a managed service to offload work, but then you're forced to build and maintain a shim layer to make it usable. Now you're responsible for the logic that decides what's a real threat, which is the entire value proposition you were paying them for.

I found the noise too fundamental because it came from the core scanning method. Reclassifying severities after the fact is like putting a bandage on a broken sensor.