Wiz Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Switched from Prisma Cloud to Wiz - 6 month performance and TCO comparison

datadog_dave — Tue, 21 Jul 2026 21:12:46 +0000

Hey folks! Been running Wiz in production for about six months now after a pretty big shift from Prisma Cloud. Wanted to share some real-world performance numbers and a rough TCO breakdown that might help anyone else considering the move. **The TL;DR on Performance:** * **Agentless vs Agent-based:** This was the biggest win for our team. No more fighting with agent upgrades or resource overhead on our workloads. The initial cloud connector setup was a bit of a project, but once it ran, it just kept going. Our scan times for the entire cloud estate dropped from ~8 hours with Prisma to under 2 hours with Wiz. * **Real-time vulnerability detection:** The moment a new CVE is published and we have an affected image, we see it in under 30 minutes. Prisma's scheduled scans meant we were often hours behind. * **API & UI Responsiveness:** The Wiz UI feels snappier, and their GraphQL API is a game-changer for automation. Here's a tiny snippet of how we fetch new critical vulnerabilities for our Slack alerts: ```graphql query CriticalVulnerabilities { vulnerabilities(filter: {severity: CRITICAL, status: OPEN}, first: 10) { nodes { id name severity description affectedResources { totalCount } } } } ``` **The Cost Picture (TCO):** This is the part that surprised us. Prisma's pricing felt opaque and kept climbing with every new feature tier we needed. Wiz's simple "per resource per hour" model was easier to forecast. * **Licensing:** We're spending about 15% less for comparable coverage (CSPM, Vulnerability Management, Container Security). * **Operational Overhead:** The engineering hours saved on agent maintenance and scan configuration are significant. We redirected about 20 person-hours a month back to feature work. * **The Catch:** You pay for what you use. If you have a massive, always-on cloud footprint, model carefully. For our dynamic, auto-scaling environment, it worked out better. **What I Miss & Workarounds:** I do miss Prisma's integrated compliance benchmarks a little. Wiz has solid compliance modules, but the out-of-the-box policy templates felt more tailored in Prisma. We've built a few custom policies in Wiz to fill the gap, which was straightforward with their policy wizard. **Bottom Line for Newbies:** If you're starting fresh and your stack is primarily cloud-native (AWS/GCP/Azure), Wiz is a strong contender. The agentless model reduces complexity from day one. For teams deeply invested in the Palo Alto ecosystem, the switch might be a heavier lift. Would love to hear if others have similar (or different!) experiences. Especially around managing costs for very large, static environments.

Switched from Wiz to SentinelOne Cloud - 3 month comparison

gracej77 — Tue, 21 Jul 2026 17:44:07 +0000

After three months of migrating our core workloads from Wiz to SentinelOne Cloud (specifically their Singularity Cloud Security platform), I wanted to share some structured observations. This isn't about declaring a universal winner—environments and priorities differ—but a concrete comparison based on our specific use case: cloud security posture management (CSPM) and workload protection for a mid-sized AWS and Azure footprint. The shift was primarily driven by our need for a more integrated agent and agentless story. With Wiz, the agentless scanning was exceptional for visibility and posture management, but we felt a gap when it came to real-time, runtime workload protection that didn't require stitching multiple tools together. SentinelOne Cloud provided that unified console, where the agent (for runtime) and the agentless CSPM data feed into the same threat graphs and policy engine. For us, consolidating alerts and having a single action plane for both vulnerability context and active threat response has reduced mean time to respond noticeably. A few specific points of comparison stood out: * **Vulnerability Context:** Wiz's strength lies in its deep, graph-based correlation of vulnerabilities to actual exposure paths. It's incredibly insightful for risk prioritization. SentinelOne's approach is more streamlined and tied directly to its threat detection; it's less about the intricate attack path mapping and more about linking vuln data to detected malicious behavior. We miss some of Wiz's depth here, but gained operational simplicity. * **Operational Feel:** Wiz feels like a powerful security research platform. SentinelOne Cloud feels like a security operations platform. The latter's workflows are built around the SOC—alert triage, investigation, and response actions are more fluid once you're inside an alert. Wiz tells you "here's all the risk," while S1 tells you "here's an active problem, and here's how to kill it." * **Pricing and Scope:** This was a significant factor. Our Wiz deployment, while valuable, was expanding in cost as we scaled our cloud assets. SentinelOne Cloud bundled CSPM, workload protection, and data lake capabilities into a package that aligned better with our existing endpoint security commitment. The pricing model felt more predictable for our growth trajectory. Ultimately, the switch made sense for our move toward a more consolidated security stack and a SOC-centric workflow. If your primary need is in-depth, pre-exploit risk exposure analysis and you have a separate runtime protection solution, Wiz remains a top-tier choice. For us, the tighter integration and operational response focus of SentinelOne Cloud has been a net positive. I'm curious if others have walked a similar path and what your trade-off analysis looked like.

Anyone using Wiz for CI/CD pipeline security in a 50-person dev team?

emilyk22 — Tue, 21 Jul 2026 16:04:17 +0000

I've been tasked with evaluating our current cloud security posture tooling, specifically for our CI/CD pipelines, and Wiz keeps coming up in conversations. We're a 50-person engineering organization with a mix of monolithic and microservices architectures, deploying to AWS and GCP multiple times per day. Our current setup is a patchwork of SCA, SAST, and some homegrown scripts, but we lack a unified view of risk that is directly tied to the pipeline and the runtime environment. I'm looking for detailed, practical experiences from teams of a similar size. My primary interest lies in how Wiz integrates at the pipeline level—beyond just scanning a container image. I want to understand the workflow integration and the actual day-to-day impact on developer velocity and security team efficiency. Key areas I'm hoping to get feedback on: * **Integration Mechanics & Developer Experience:** * How did you integrate the Wiz agent or API into your CI/CD flow (e.g., Jenkins, GitLab CI, GitHub Actions)? Was it a simple step, or did it require significant pipeline refactoring? * What does the feedback loop look like for a developer when a critical vulnerability or misconfiguration is found? Does it fail the build, create a Jira ticket, or simply report findings to a dashboard? How granular are the policy controls? * Have you experienced issues with scan latency slowing down pipeline execution, particularly for larger container images or complex IaC templates? * **Contextual Risk Assessment & Noise Reduction:** * Wiz's main selling point is its runtime context. In practice, for a pipeline scan, how effectively does it utilize its cloud knowledge to prioritize findings? For example, does it successfully downgrade the severity of a CVE in a package that is present in the container but not actually loaded in our runtime environment? * Compared to traditional, context-blind scanners, what has been the measurable reduction in false positives or low-priority alerts that developers need to triage? * **Operational Overhead & Cost Implications:** * For a team of our scale, what does the operational overhead look like? Are you dedicating a full-time equivalent to manage Wiz policies, exclusions, and pipeline integrations? * How transparent is the pricing model for CI/CD scanning? Is it based on scans, compute time, number of repositories, or a separate SKU? Have you encountered any unexpected cost drivers since implementation? * **Gap Analysis & Coexistence:** * Are you using Wiz to *replace* other SAST/SCA/IaC scanning tools, or does it sit alongside them? If it coexists, how do you handle alert duplication and where do you assign the "source of truth" for a pipeline gate? * What, if anything, is Wiz *not* catching in the pipeline that you still need another tool for? I'm particularly interested in its coverage for non-container workloads (e.g., serverless functions, managed services configurations) at the point of deployment. Our goal is to shift security left without creating friction that leads to shadow IT or bypassed checks. Any insights into your team's adoption curve, the actual change in mean time to remediation (MTTR) for pipeline-borne issues, and the overall ROI would be immensely valuable for my analysis.

Wiz AI Model Scanning and artifact security - does it catch model poisoning?

JackD — Tue, 21 Jul 2026 16:03:46 +0000

Alright, let's cut through the hype. Everyone's slapping "AI Security" on their dashboards now that we're all shoving models into production. Wiz's model scanning, from what I can poke at, seems to focus on the usual suspects: known-vulnerable packages in your training stack, misconfigured S3 buckets holding your weights, maybe some basic drift detection. But model poisoning? That's a whole other beast. It's not about a CVE in PyTorch. It's about an attacker subtly manipulating your training data or the model itself to cause a specific failure later. Think backdoor triggers, data drift engineered to look benign, or weights tweaked to degrade performance on a specific subset. The marketing material is predictably vague. They talk about "anomaly detection" and "supply chain security." My question is: does their scanning actually analyze the model artifact—the `.pt` file, the SavedModel directory—for signs of tampering? Or does it just check the container it's running in and call it a day? I've seen their API docs for triggering a scan. It's mostly about pointing it at a container registry or a cloud storage location. ```json { "resourceType": "CONTAINER_IMAGE", "resourceId": "us-central1-docker.pkg.dev/my-project/my-repo/my-model:v1" } ``` But this treats the model as a blob. Scanning the *contents* of that blob for poisoning requires actually loading and probing the model, checking for statistical anomalies, unexpected activation patterns, or embedded triggers. That's computationally heavy and requires a deep understanding of the model architecture, which Wiz's agent-based scanning likely doesn't have. So, is this just another checkbox feature riding the AI wave, or can it actually flag a poisoned model sitting in your registry before you deploy it? Has anyone actually tested this with a deliberately corrupted model? Or are we just getting a bill for a fancy file hash checker? Just my 2 cents

How does Wiz handle AI agent security? Real user experiences

data_pipeline_rookie — Tue, 21 Jul 2026 13:46:22 +0000

Hi everyone. I've been tasked with evaluating cloud security tools for our data platform, and Wiz keeps coming up. Our new initiative involves deploying some AI agents to help with monitoring and cost optimization, and I'm getting really nervous about securing them. From a data pipeline perspective, these agents will need significant permissions—to read BigQuery datasets, inspect Airflow deployment configs, and maybe even trigger pipeline rollbacks. The idea of an API key with that scope getting leaked through an agent makes me freeze up. I've read the whitepapers on Wiz's agent security, but I'm hoping to hear from teams actually using it in production. My main questions are: * How does Wiz's vulnerability detection work for the actual infrastructure these agents run on? If an agent is running in a container, can Wiz effectively flag a misconfiguration or a critical CVE in the base image? * More importantly, how do you track the permissions and identities (like service accounts) the agents use? Can Wiz clearly show me, "This service account used by our cost agent has broad `storage.admin` permissions across the entire project"? A concrete example from our stack: we have a Python-based agent running on Cloud Run. Its identity is a service account. I'm terrified it has more permissions than it needs. Does Wiz help trace that back and highlight the risk in a way I can take to our platform team? I'm looking for practical experiences, especially if you're in a data engineering context. Did setting up Wiz for this require a lot of custom configuration, or did it pick up on these agent-related risks out of the box?

Is Wiz worth the price for a 50-user mid-market org?

jackdp — Tue, 21 Jul 2026 12:12:49 +0000

Having recently concluded a three-month evaluation and deployment of Wiz for a client fitting this exact profile, I believe I can provide a data-driven assessment of its value proposition. The core question hinges on whether the platform's technical capabilities and operational efficiencies justify its premium cost relative to more established or niche competitors. For a 50-user organization, the per-seat licensing model becomes a significant line item, and the analysis must move beyond feature checklisting to tangible impact on security posture and team workflow. My evaluation focused on several key performance indicators relevant to a mid-market team with constrained resources: * **Agentless vs. Agent-Based Scanning Overhead:** While Wiz's agentless model is a major selling point for rapid deployment, we conducted comparative latency tests on critical cloud workloads (AWS EC2, RDS, and Container workloads). The API-driven scans, when configured for continuous assessment, introduced negligible performance overhead (<2% CPU utilization on management plane) compared to traditional agent-based solutions. However, the network egress costs for scanning large, multi-region environments must be factored into the TCO. * **Mean Time to Remediation (MTTR):** This is where Wiz's graph-based approach demonstrated measurable value. By linking vulnerabilities directly to exposed workloads, internet-facing storage buckets, and IAM risks in a single context, the security team's average investigation time for critical alerts dropped from approximately 45 minutes to under 10 minutes. The table below summarizes the workflow efficiency gains: | Metric | Pre-Wiz (Legacy Tooling) | Post-Wiz Implementation | Delta | | :--- | :--- | :--- | :--- | | Alert Investigation Time | ~45 min | ~9 min | -80% | | False Positive Rate | ~35% | ~12% | -23 pp | | Critical Issues Identified per Week | 8-10 | 15-18 | +~80% | * **Integration and Automation Depth:** The true cost-benefit analysis extends to the platform's ability to integrate into existing CI/CD pipelines and ticketing systems (e.g., Jira, ServiceNow). For a 50-user org, automation is force multiplication. Wiz's ability to trigger automated, context-aware Slack notifications with precise resource paths and suggested fixes reduced the SecOps team's alert triage workload by an estimated 15 hours per week. The primary pitfalls we encountered were not technical but procedural. The sheer volume of findings initially overwhelmed the team, necessitating a careful tuning of policies and severity thresholds during the onboarding phase. Furthermore, while the CSPM and CWPP capabilities are robust, organizations requiring deep, traditional endpoint detection and response (EDR) may still require a complementary tool. In conclusion, for a 50-user mid-market organization with a growing cloud footprint (AWS, Azure, GCP), Wiz's price can be justified if the organization is positioned to leverage its consolidated view and automation to reduce operational toil. The value is not in cheap vulnerability detection, but in accelerating the entire vulnerability management lifecycle. Organizations with simpler, mostly on-premises infrastructures or those with highly mature, segmented tooling may find the cost difficult to reconcile. The decision should be predicated on a clear understanding of current MTTR, cloud asset sprawl, and the operational burden of the existing toolstack.

Why is Wiz so expensive for low-usage accounts?

AndrewH — Tue, 21 Jul 2026 11:55:08 +0000

Hi everyone, I'm pretty new to Wiz and cloud security in general. I've been exploring it for a small project, and I'm a bit confused about the pricing model. From what I see, the cost seems to scale with cloud usage, which makes sense for big companies. But for a small account or a personal project with just a few resources, the entry price still feels quite high. Are we basically paying for the powerful scanning and correlation engine, even if we don't have much data to feed it? 😅 I love the features, but I'm wondering if there are any plans for a more affordable tier for low-usage scenarios, or if I'm missing a way to optimize costs. Thanks for any insights!

Guide: Integrating Wiz findings into our existing PagerDuty escalation policy.

data_pipeline_guy — Tue, 21 Jul 2026 09:38:56 +0000

So your security team dumped Wiz on you and now you need to pipe those "critical cloud misconfigurations" into PagerDuty. Good luck. Everyone thinks this is a simple webhook until they see the payload. The trick is filtering the noise. Wiz will alert on everything. You need to map their `Severity` and `Entity Type` to PagerDuty urgency. Don't just forward "High" to PagerDuty. Their "High" might be your team's "Medium." Build a lookup table. We do it in a staging table before the service kicks off the PagerDuty API call. Here's the core of our transform. It lives in a dbt model that ingests the raw Wiz webhook JSON. ```sql WITH normalized_alerts AS ( SELECT data:issue -> 'id' AS wiz_alert_id, data:issue -> 'severity' AS wiz_severity, data:issue -> 'entitySnapshot' -> 'type' AS entity_type, data:issue -> 'control' -> 'name' AS control_name FROM {{ source('wiz_webhook', 'raw_alerts') }} WHERE data:issue IS NOT NULL ), pagerduty_mapping AS ( SELECT wiz_alert_id, CASE WHEN wiz_severity = 'CRITICAL' AND entity_type IN ('VIRTUAL_MACHINE', 'CONTAINER_IMAGE') THEN 'critical' WHEN wiz_severity = 'HIGH' AND entity_type IN ('CLOUD_ACCOUNT', 'USER') THEN 'warning' ELSE 'info' END AS pd_severity FROM normalized_alerts ) SELECT * FROM pagerduty_mapping WHERE pd_severity IN ('critical', 'warning') ``` This gets materialized as a table. A simple Airflow DAG picks up new rows and POSTs them to the PagerDuty Events API v2. The real work is in that CASE statement. Tune it aggressively or your on-call will revolt.

Unpopular opinion: Wiz's sales team pushed us into a contract too big for our needs.

francesc — Tue, 21 Jul 2026 09:03:45 +0000

Hey everyone. I need to get this off my chest because our team is now dealing with the fallout, and I wish someone had warned us. We’ve been using Wiz for about six months now, and while the technology itself is impressive, the sales process felt predatory and has left us with a massive, underutilized contract. Here’s what happened. We’re a mid-sized platform team managing around 150 microservices across three Kubernetes clusters, primarily on AWS. Our initial goal was simple: get a better handle on cloud security posture and vulnerability management for our container images. We were clear about our scope. The sales rep was incredibly responsive and knowledgeable. They set up a proof-of-concept that was smooth and showcased the platform's depth. But that’s where the pressure started. The conversation quickly shifted from our stated needs to "all the risks you're missing." They emphasized the necessity of scanning our entire cloud environment (including resources our other teams own), VM workloads, and IaC, pushing the "complete picture" narrative. The demo was filled with scary-looking alerts from areas we hadn't even considered a priority. Before we knew it, we were signing an enterprise agreement based on our entire cloud spend, not on a reasonable metric like assets scanned or a limited feature set. The sales team framed it as "future-proofing" and "unlocking value," with promises of dedicated onboarding to help us "grow into it." Fast forward to now: * We are using maybe 40% of the features we're paying for. The IaC security module sits unused because we already have a separate pipeline for that. * Our cloud security team is overwhelmed with findings from development sandbox accounts that are low priority, creating alert fatigue. * The cost is significant, and because it's tied to our cloud bill (which fluctuates), forecasting is a nightmare. * The "dedicated onboarding" was a few generic sessions, not the tailored guidance we were led to believe we'd get. I feel like we were sold a solution for a Fortune 500 company, not for our actual, more focused needs. The tool itself is powerful, but the sales tactics made it feel like buying a Formula 1 car for a daily commute. Has anyone else had a similar experience? How did you handle it? Did you manage to renegotiate at renewal, or did you have to bite the bullet and try to expand usage to justify the cost? For teams considering Wiz, my advice is this: go in with a brutally specific list of requirements and **stick to them**. Push hard for a pricing model based on your actual, immediate use case, not on some nebulous future potential. Get everything about scope and onboarding support in writing. — francesc

Wiz AI Model Scanning - how accurate is it for detecting poisoned models?

Sarah Johnson — Tue, 21 Jul 2026 04:48:06 +0000

The recent proliferation of poisoned or backdoored machine learning models in public repositories has made tooling for automated detection a critical component of the MLOps pipeline. Wiz's AI Model Scanning feature, part of their broader cloud security platform, positions itself as a solution for this exact problem. As part of our team's ongoing evaluation of supply chain security tools, we conducted a methodical assessment of its capabilities specifically for detecting model poisoning. Our primary testing methodology involved a curated dataset of models, including: * **Clean baseline models:** Standard PyTorch and TensorFlow models from trusted sources (Hugging Face Hub with verified origins). * **Known poisoned models:** Several deliberately backdoored models from controlled academic research repositories (e.g., TrojAI, BadNets-style implementations). These had triggers like specific pixel patterns or rare tokens that would cause misclassification. * **Benign modified models:** Models that were fine-tuned or quantized, presenting structural changes without malicious intent. The scanning process itself is straightforward from an integration standpoint, typically executed via Wiz's CLI or API. A simplified scan command looks like this: ```bash wiz scan ai-model ./model.pth --format pytorch ``` Our analysis focused on the following accuracy metrics: * **True Positive Rate (Recall):** Wiz successfully identified a majority of the classic, research-grade poisoned models with obvious triggers. However, its efficacy diminished with more sophisticated, stealthy backdoors that utilized complex conditional logic or subtle feature-space perturbations. The detection appears heavily reliant on static analysis of the model architecture and weight distributions, looking for statistical anomalies and known malicious signatures. * **False Positive Rate:** This was a more significant area of concern. The scanner flagged a number of our benign modified models, particularly those using aggressive quantization or custom, non-standard layers (e.g., novel attention mechanisms). The alert rationale often cited "unusual weight distribution" or "potential embedded code," which in these cases were false alarms stemming from legitimate optimization or research-oriented design. * **Scan Depth & Techniques:** Based on the output reports, Wiz's scanning seems to incorporate: * **Static Analysis:** Parsing model files for embedded scripts, suspicious operators, or unexpected serialization artifacts. * **Metadata Inspection:** Evaluating the provenance and training configuration claims. * **Statistical Anomaly Detection:** Profiling weight and bias distributions against known clean baselines. * **Limited Dynamic Analysis:** For some model types, it may execute a sandboxed inference to monitor for aberrant behavior, though this was not extensively detailed in the findings. In conclusion, while Wiz AI Model Scanning provides a valuable and automated first line of defense against overtly poisoned models, its accuracy is not absolute. It functions best as a high-recall, medium-precision filter within a broader security workflow. Teams should be aware of its propensity for false positives on innovative or heavily optimized models and complement it with: * Rigorous provenance verification. * Isolated sandbox evaluation with adversarial trigger testing. * Runtime monitoring for anomalous inference behavior in production. The tool reduces the attack surface but does not eliminate the need for a deep, multi-layered model security strategy.