Skip to content
Notifications
Clear all

Claw's container image scanning vs Azure's ACR scanning - numbers?

3 Posts
3 Users
0 Reactions
0 Views
(@integration_maven_jane)
Estimable Member
Joined: 2 months ago
Posts: 100
Topic starter   [#8978]

Hi everyone,

I'm in the middle of a security tooling evaluation for our CI/CD pipeline and could really use some real-world, comparative insights. We're a team of about 25 engineers, with a stack built on Azure DevOps for CI/CD, deploying to AKS, and using Azure Container Registry (ACR) as our primary image repository. We've been relying on the native vulnerability scanning that comes with ACR's premium tier, but we're now evaluating Claw (formerly ClawScanner) as a potentially more integrated and powerful alternative.

Our main goal is to shift security further left without bogging down developer velocity. The ACR scanning is convenient because it's right there in the registry, but we've noticed some gaps:
* The policy enforcement feels a bit rudimentary—mostly about blocking images based on severity.
* The reporting and trend analysis for security posture over time isn't as detailed as we'd like.
* It seems primarily focused on the registry itself, not as deeply integrated into the *entire* build and PR process.

I'm looking at Claw because it promises deeper Git integration (like automated PR comments on Dockerfile changes) and more granular, language-specific policy rules. The idea of a unified policy across both CI and the registry is appealing.

**My core question for the community:** Does anyone have concrete, comparative experience with both tools, specifically on **scanning speed, accuracy (false positive rates), and the breadth of vulnerability databases**? I'm trying to move beyond feature lists to actual performance metrics.

Some specific data points I'm hunting for:
* **Scan duration:** For a moderately sized image (~500MB), what's the typical time delta? We have to keep our pipeline runs under a certain threshold.
* **Coverage:** Does Claw's scanning consistently identify more CVEs, especially for non-OS packages (like npm, pip) compared to ACR's scanning (which uses Qualys under the hood)?
* **DevEx impact:** How actionable are the findings in each? Are Claw's results easier for developers to triage and fix?
* **Policy flexibility:** We need to allow certain exceptions for dev/test environments. How cumbersome is it to manage nuanced policies in each system?

We are *not* considering self-hosted options like Trivy/Anchore for this particular function—we want a managed service to reduce overhead.

Any numbers, anecdotes, or "watch out for this" gotchas would be immensely helpful. I'm particularly interested if anyone made this specific switch and what the tangible before/after effects were on their security workflow.

Thanks in advance for sharing your wisdom!

~Jane


Stay connected


   
Quote
(@larryh)
Trusted Member
Joined: 1 week ago
Posts: 42
 

Hey, I'm Harry. I ran infrastructure for a mid-sized fintech (about 30 devs) on a very similar stack - Azure DevOps, AKS, and ACR. We moved off ACR scanning for Claw about 18 months ago after hitting similar walls, so I've sweated through this exact swap.

Here's my breakdown on where the rubber meets the road:

1. **Policy Granularity & Real Cost:** ACR's policies are basically on/off switches for severity levels. Claw lets you write rules like "fail on critical CVEs in base images, but only warn on highs in our Python app dependencies." The ACR premium scanning "cost" is bundled, which feels free until you realize its limitations are the tax. Claw's per-developer seat pricing stings at first (we pay about $12/user/month for their mid-tier), but you're buying specificity you can't get otherwise.

2. **Build Pipeline Integration Pain:** Integrating ACR scanning is a checkbox. Integrating Claw is a project. Expect to spend a solid week getting their Azure DevOps task extensions configured, service principals sorted, and figuring out how to fail builds without drowning devs in noise. The PR comment feature is magic once it works, but the setup docs are optimistic.

3. **Scan Performance & Coverage:** For plain old Linux distro CVEs, they're both fast and thorough. Where Claw pulled ahead for us was on language-specific stuff - pinpointing vulnerable npm or PyPI packages inside the image, not just the OS layer. ACR would sometimes miss those, or flag the library but not contextualize the risk well. Our Java service scans took about 2 minutes with ACR and 3-4 with Claw, but we got more actionable intel.

4. **Where ACR Clearly Wins (and where Claw Breaks):** If your entire world is 100% Azure and you never plan to leave, ACR scanning is zero extra management. Claw adds a third-party service that, while reliable, is another dashboard and alert source. Also, if your registry is mostly Windows containers, Claw's support was spotty last I checked. ACR handles that natively.

I'd recommend Claw if you're serious about shifting left and need to write nuanced security rules for different teams or app types. The reporting and trend history alone justified the cost for our compliance folks. If your needs are simple - just block criticals and you're all-in on Azure - stick with ACR and save the budget. To make a clean call, tell us what percentage of your images are Windows-based and how much you actually customize policies today.



   
ReplyQuote
(@consultant_carl)
Estimable Member
Joined: 4 months ago
Posts: 125
 

Oh Harry, that second point about integration pain is so real it hurts. You're right, it's a project, not a checkbox. I'd add that the biggest hidden cost isn't the week of setup - it's the cultural change management you need to pair with it.

If you just drop Claw's PR comments into the pipeline without preparing the team, you'll get immediate backlash. Devs see a wall of "highs" they've never had to care about before and feel penalized. We learned to run a parallel "observation only" phase for two weeks, sharing a weekly digest in our standup to desensitize everyone before flipping the policy enforcement switch. Made the actual cutover 80% smoother.

That said, once you're over that hump, the granularity you mentioned is what keeps it sustainable. Being able to say "ignore this specific CVE in *this* legacy service's base image, but fail on it everywhere else" is the only way we got buy-in from our lead developers. ACR's all-or-nothing approach would have shut the whole initiative down.


Implementation is 80% process, 20% tool.


   
ReplyQuote