.svg){kind=icon}
The ZEST Digital Twin is now available. Autonomous Remediation in ZEST already traces piles of findings to their root cause, builds one fix for each and routes it to the AI-suggested owner, and now the Digital Twin simulates that fix against a model of your environment before it ships, so every plan arrives with a verdict, a confidence score and the reason behind it. Finding the fix stopped being the hard part a while ago. Shipping it without breaking production is where remediation stalls, and that is the part the Digital Twin was built for. Want to see it run end to end? Book a demo.
ZEST AI agents model your cloud and on-prem environment, including its workloads, dependencies and controls, and simulate each way of shipping a fix against that model before production sees a single change. The path that passes goes straight into Autonomous Remediation, which puts it in front of the AI-suggested owner with the three ways to move your team already uses:
- Kick a workflow runs the simulated plan through your deployment system now and notifies the owner when it is done.
- Ship to owner sends the plan to the owner to review and run.
- Open a ticket creates a Jira ticket in the owner's project, already assigned to them.
Why shipping is the hard part
Phil Venables put numbers on this in The Vulnpocalypse. In his experience, discovery, fix development, and testing and staging each take about a tenth of the effort to fix a vulnerability, while deployment takes the remaining 70%. He is careful to call that anecdote rather than data, but anyone who has run a vulnerability program will recognize the shape, and AI is about to make it more lopsided, because the early stages are exactly where AI tooling got good.
Deployment costs that much because one question has to be answered before every change window, which is whether the change will break production. The scanner says a package is vulnerable and the advisory says which version fixes it, yet neither says what happens to the thousands of pods running on the nodes you are about to touch, and a staging cluster rarely runs hundreds of nodes at production load under production's disruption budgets. Staged rollouts with fast rollback, which Phil recommends, limit the damage once a change is running. The Digital Twin answers the question before it runs.
Inside one simulation: 300 findings on an EKS cluster
Take one resolution plan end to end. The cluster is payments-prod-eks, with three managed node groups, 300 worker nodes and roughly 9,000 pods, and Tenable reports 300 findings across those nodes, which would become 300 tickets if they were filed one at a time. ZEST traces all of them to a single runtime root cause, the containerd 1.7.31 build baked into the worker node image, so the plan has one job, which is to move the workers to a patched image running containerd 1.7.32.
The twin simulated the two obvious ways to do it. Patching in place and rebooting every node failed fast, because rebooting without draining takes pods down with no disruption budget in the way, and draining every node at once leaves the evicted pods nowhere to run, so every service on the cluster degrades together. A staged node replacement passed. It follows the default update shape for an EKS managed node group, launching patched nodes first, cordoning and draining the old ones and terminating each only after its pods are evicted, and the twin ran it in ten batches sized so that no workload loses more pods than its disruption budget allows. That sizing matters on the real cluster too, since AWS lists overly strict disruption budgets among the causes of a stalled update: if pods do not leave a node within 15 minutes and the update is not forced, it fails with a PodEvictionFailure.
The verdict came back as staged replacement at 93% confidence, after the twin confirmed that replacement nodes boot and register with EKS, DaemonSets come up, every pod reschedules with zero disruption-budget violations, service health holds for the whole rollout, and the new nodes run containerd 1.7.32, which closes the Tenable findings on the next scan. The in-place reboot came back high risk with its reason attached, cluster-wide service degradation. The platform team gets one reviewed plan instead of 300 tickets and a gut call.
Built on the loop ZEST customers already run
The Digital Twin plugs into a loop that already runs in production. AI Sweeper Agents investigate every finding and dismiss the ones that cannot be exploited where they run, which across our customers is more than 90% of high and critical vulnerabilities. Preemptive Mitigation proves when a control you already run blocks the attack, and Autonomous Remediation fixes the rest at the root cause. This year alone, ZEST has dismissed more than 2.9 million vulnerabilities across our customers' environments as not exploitable, each with the AI's reasoning attached, marked more than 1.7 million as mitigated by controls already in place, and kept more than 4.7 million tickets from ever being opened. That builds on 2025, when our AI agents gave back more than 600,000 hours of security and engineering time (the 2025 numbers). In September, Gartner® named ZEST a Sample Vendor for Autonomous Exposure Remediation, and ZEST was the only vendor named in both that category and Preemptive Exposure Management (read more).
See it ship a fix
If your team has a backlog of fixes that are known but not shipped, that backlog is what we want to talk about. Book a demo and we will walk a resolution plan from its root cause to a simulated, owner-ready fix on the ZEST platform, then talk through how the Digital Twin would handle yours.
Keep reading
- Gartner® names ZEST twice in one report
- ZEST Security Announces AI Sweeper Agents
- Customer Wins: Agentic Exposure Management in Numbers
- Your WAF blocks everything except your CVE
- php2shell: mitigate PHP now, patch the moment it ships
Sources
- Phil Venables, The Vulnpocalypse: Good News and Bad News, and the LinkedIn post with his effort chart
- AWS, Understand each phase of node updates, Amazon EKS user guide
- Kubernetes, Disruptions
- Kubernetes, Safely Drain a Node
About The Author
.jpg)
