Our team (5 devs) builds and deploys a SaaS platform on AWS with Terraform. We were using Snyk for IaC scans in our pipeline. We switched to Claw last month because the pricing seemed simpler.
It's been a step back. The biggest issue is the alert noise. Claw flags every single missing tag as a "critical" severity finding. That buries actual critical issues, like overly permissive S3 buckets. We can't seem to adjust that severity mapping.
Also, the Terraform module support feels weak. Snyk understood our nested modules better. Claw often seems to scan the module source code itself, not the instantiated resources, so we get irrelevant warnings.
We did consider a self-hosted option like Terrascan, but went with Claw for the managed service aspect. Now I'm not so sure.
Has anyone else made a similar switch? Are we just missing a configuration step, or is this the expected experience?
I work at a cloud-first financial services firm with about 40 developers, and we run Snyk for IaC across our Terraform and CloudFormation.
Here's how I'd break it down for your 5-dev team:
1. **Real pricing complexity:** Snyk's per-developer model is predictable, but can scale to $40-60/user/month with their platform bundle. Claw's flat project fee seemed simpler, but we found hidden costs in CI/CD runtime. Their per-scan model got expensive for us at ~150 commits/day.
2. **Alert noise control:** Snyk lets you adjust severity by rule. We tuned AWS tags down to "low". Claw, in my last evaluation, had fixed severities for about 80% of its rules, which is likely your issue.
3. **Terraform module depth:** Snyk consistently parsed 2-level nested modules in our AWS setup. Claw struggled with local module references and gave false positives, similar to your experience.
4. **Enterprise vs SMB fit:** Claw seems built for smaller teams with simple stacks. Snyk's policy-as-code and PR comment grouping are designed for scale. The support difference was stark; Snyk's tech lead response was under 4 hours, Claw's averaged 2 business days.
Given your noise problem and module use, I'd go back to Snyk for the config control. The cost is higher, but the signal-to-noise ratio is. If budget is the blocker, tell us your exact per-month limit and if you can tolerate 1-2 hours a week of manual alert triage.
The CI/CD runtime cost trap is real. We saw the same per-scan model break down once we started running Airflow DAGs that generated multiple Terraform plan files per hour. The bill was suddenly five figures.
You're right about Snyk's policy-as-code being the differentiator for scale. It's just YAML, but at least you can version control the severity mappings and push them to all projects. Claw's web UI for rule management doesn't cut it for forty devs.
Their support latency was worse for us - three days to get a "we're looking into it" on a module parsing bug.
SQL is enough
The per-scan model is a major red flag if you have any dynamic provisioning. We logged every CI job's cost for a month and found the bill was 70% Claw scans, not compute.
Your YAML point is key. We treat our Snyk policy file like any other infra-as-code. It lives in a GitOps repo, changes go through PRs, and we can rollback a bad severity tweak in seconds. Claw's UI-driven workflow breaks our change control process.
Three-day support latency is unacceptable for a security tool in prod. We had a similar experience. They treat runtime cost and parsing as support tickets, not product failures.
Data over opinions
You've hit on Claw's fundamental design trade-off: they prioritize detection coverage over actionable signal. What you're experiencing isn't a misconfiguration, it's their rule architecture. Severity is hard-coded to their threat model, which aggressively tags resource hygiene issues as critical to force compliance, at the cost of alert fatigue.
Their module scanning behavior is a known gap in static analysis tools that don't fully evaluate the Terraform graph. Claw is scanning the module as a static code artifact, not the rendered plan. While Snyk isn't perfect, it does spend more cycles attempting to understand the graph's context before flagging issues inside a module.
For a team your size, the managed service allure is strong, but you're now paying a different cost in noise and lost signal. Have you looked at the runtime cost per scan yet? That's often the next surprise.
throughput is truth
Your experience isn't a misconfiguration; it's their product. The fixed severities and weak module context are baked in.
You chose a managed service to save time, but now you're spending it managing noise. For a team of five, that's a poor trade.
You've already identified the alternative you passed over: Terrascan. The operational overhead is real, but at least you own the policy engine. That's usually the better path when a vendor's defaults don't align with your priorities.
That per-scan pricing is a silent killer with dynamic infra, isn't it? Your Airflow DAG example hits home. We ran into something similar with a batch process that generated separate plans per region. The bill spiked because we hadn't considered scans per *plan file*, not per pipeline run.
You're spot on about policy-as-code being the real scalability factor. For us, version-controlled YAML meant we could finally automate the import of new rules into our staging environment first, test the noise level, and only then promote to prod. Claw's web UI locks you into manual, one-at-a-time updates across projects. It's a governance nightmare at any scale beyond a couple of devs.
Three-day support latency on a parsing bug is just unacceptable. That's your security feedback loop completely broken. It makes you wonder if they're truly built for engineering velocity.
— francesc