> ## Content Index > Fetch the complete content index at: https://blog.previdian.com/llms.txt > Use this file to discover other available public pages before exploring further. # Virtual patches that evolve with attackers - URL: https://blog.previdian.com/virtual-patches-that-evolve-with-attackers/ - Published: 2026-10-02T15:11:56.000Z - Updated: 2026-10-02T15:16:43.000Z - Author: Ryan Dewhurst [Previdian Virtual Patches](https://previdian.com/virtual-patches?ref=blog.previdian.com) are now autonomously generated and updated from real attacker traffic hitting our global honeypot network. When the exploitation patterns we observe change, the rules available to our Enterprise users can change with them. We’ve had virtual patches in Previdian for a while. What’s new is the autonomous generation and updating of those patches based on attacker behaviour. An attacker starts using a different endpoint, changes a payload or introduces a new bypass technique? When we observe that behaviour, Previdian can use it to generate a new virtual patch or update an existing one. ## Why creating a rule is only the beginning A [virtual patch](https://owasp.org/www-community/Virtual%5FPatching%5FBest%5FPractices?ref=blog.previdian.com) is a compensating control, typically a web application firewall rule, that helps reduce exposure to a vulnerability without changing the vulnerable application’s code. It gives defenders another option while the permanent fix is being tested and deployed. But a rule is only useful against the traffic it actually matches. Consider a rule that matches exploitation requests sent to one endpoint. If the same vulnerability can be reached through another endpoint outside the rule’s scope, that rule may miss the alternative request. Changes to request encoding and payload structure can create similar gaps. [OWASP’s virtual patching guidance](https://owasp.org/www-community/Virtual%5FPatching%5FBest%5FPractices?ref=blog.previdian.com) highlights this problem: a rule built too narrowly around one exploit example can miss other ways of exploiting the same vulnerability. Creating the first rule is therefore only part of the job. Keeping it relevant as exploitation techniques change matters too. ## From attacker traffic to a deployable rule Our global honeypot network provides the input. Real exploitation attempts targeting internet-facing services. Previdian uses that traffic to autonomously generate virtual patches and update them as new exploitation patterns appear. Our [virtual patch pipeline](https://previdian.com/virtual-patches?ref=blog.previdian.com) also tests rules against cases that should be blocked and cases that should be allowed before delivering deployable rules to Enterprise users. **Attacker traffic → sensor observation → rule generation or update → testing → ready to deploy.** This connects the observations from our sensors with a practical defensive action. For defenders, the useful output is not simply a notification that an attacker has changed their approach. It is a new or updated rule they can assess and deploy through their existing security infrastructure. That is what we mean by **virtual patches that evolve with attackers**. ## ModSecurity, AWS WAF and Cloudflare Previdian provides [deployable virtual patches for ModSecurity, AWS WAF and Cloudflare](https://previdian.com/virtual-patches?ref=blog.previdian.com). For Cloudflare, patches can be published with a single click. Autonomous generation and deployment are separate steps. Your team decides when to publish a rule or incorporate an update into its deployment workflow. An updated rule needs to be deployed before it changes the behaviour of your live WAF. ## Available through our API All virtual patches are available to Enterprise users through our API. The [virtual patch endpoint](https://previdian.com/virtual-patches?ref=blog.previdian.com) provides programmatic access to the deployable rules: ``` GET /api/v2/enterprise/virtual_patches ``` Teams can retrieve the rules and incorporate them into their existing security and deployment workflows. The API provides the delivery mechanism. Your workflow can handle the review, testing and rollout appropriate for your environment. ## A temporary control, not a replacement for patching A virtual patch does not remove the underlying vulnerability. Its purpose is to help reduce exposure while permanent remediation is underway. Teams should continue to prioritise vendor fixes, test rules against their own application traffic and monitor their effect after deployment, in line with [virtual patching best practices](https://owasp.org/www-community/Virtual%5FPatching%5FBest%5FPractices?ref=blog.previdian.com). Coverage also has limits. Not every exploited vulnerability can be addressed by a WAF rule, and [virtual patch availability](https://previdian.com/virtual-patches?ref=blog.previdian.com) depends on whether the exploitation pattern can be addressed reliably. An evolving rule should not be treated as a guarantee that every possible bypass is covered. The value is in maintaining a connection between observed exploitation and the controls available to defenders, rather than treating the first rule as the end of the response. ## Turn exploitation intelligence into defensive action Previdian’s honeypots help us understand how attackers are attempting to exploit vulnerabilities. Autonomous virtual patch generation and updates turn those observations into rules teams can use. Not just a rule created once, but a defensive control that can evolve as the attacker behaviour we observe changes. [Explore Previdian Virtual Patches](https://previdian.com/virtual-patches?ref=blog.previdian.com) for supported platforms and Enterprise access.