When a critical CVE drops, the clock has started before your team finishes reading the advisory. Proof of concept exploits are typically circulating within 24-48 hours of disclosure. The response sequence has become familiar: check with the WAF vendor for a fix, and if they don't have one available, assign an engineer to write a custom rule. That work can stretch for days and assumes the organization has someone on the team who knows how to write WAF rules well in the first place. Many organizations don't.
The gap between knowing about a threat and protecting against it has always carried risk. At the current pace of disclosure and exploitation, it’s become operationally dangerous.
Mitigation, through AI-generated WAF rules, seems like the right approach. However, generating a WAF rule that blocks the often multiple and changing exploits, and that doesn’t block legitimate traffic, doesn’t duplicate existing coverage, and is optimized for your platform’s evaluation constraints is a much bigger challenge.
By reading this blog, you'll come away with a concrete view of how Miggo engineered a CVE-to-WAF-rule pipeline that produces auditable, false-positive-tested, platform-optimized rules – and a checklist to hold any AI-generated rule (ours or anyone else's) to the same bar.
Why AI-Generated WAF Rules Fail
When we started building WAF Copilot, the temptation was to do what most AI-assisted security tools do: take a CVE ID, summarize the advisory, and produce a detection pattern. The output looks plausible, and it would even pass a quick sanity check. However, that approach fails in the ways that matter most.
A rule generated from a CVE summary alone is derived from a description of the vulnerability, not from the vulnerability itself. It just covers the canonical exploit form documented in the advisory.
A rule generated from a CVE summary alone has three problems:
- It doesn't model evasion variants, such as encoding tricks, obfuscation patterns, or the dozen ways an attacker modifies a payload to bypass a naive signature.
- It hasn't been tested against a real WAF instance to verify the logic actually works as deployed, rather than as written.
- It hasn't been checked against valid traffic to confirm it won't fire on legitimate requests that happen to resemble the attack pattern.
That last failure mode, false positives, is the most critical. Rules that incorrectly block legitimate user traffic are often worse than no rule at all. It creates incidents, erodes trust in WAF-based defenses, and results in rules being deployed in log-only mode indefinitely, which is the security equivalent of having no rule.
We've seen this pattern consistently: teams that have been burned by false positives become extremely conservative about deploying new rules, even when the rules are necessary.
We realized that the solution wasn’t writing a better prompt. We needed to rethink the architecture.
8 Steps to Build a Shippable Rule
Miggo WAF Copilot's rule generation runs every CVE through an eight-stage AI pipeline before a rule is considered shippable. The stages aren't sequential steps in a script – each one produces a verifiable artifact that gates the next. A failure at any stage returns the rule for revision, not to the queue.
Step 1: Root cause research. The AI research agent doesn't stop at the CVE advisory. Where source code is accessible, it reads the vulnerable code path directly. The goal is understanding why the vulnerability exists – the specific code pattern, the execution flow, the input surface – not just what the advisory says. A rule grounded in the actual vulnerable code path is more precise than one derived from a description of it.
Step 2: Exploit collection and variant modeling. Public proof-of-concept exploits are collected and analyzed. More importantly, the agent explicitly models evasion variants: URL encoding, Unicode normalization, header injection points, obfuscation patterns that produce the same attack behavior while evading pattern-based detection. If a rule only catches the textbook exploit, it fails the moment an attacker makes a trivial modification.
Step 3: Rule logic generation. The rule is written in WAF-native syntax for the target platform: AWS WAF regex and condition logic, or Cloudflare rule expressions. This is not a generic signature translated post-hoc. Detection logic built for the platform it will run on handles edge cases that platform-agnostic patterns miss, and avoids evaluation behaviors specific to each engine.
Step 4: WAF instance testing. The exploit scenarios from Stage 2 are fired against a live WAF instance, before and after rule deployment. Block and pass results are confirmed empirically. This is a hard requirement; a rule that looks correct in isolation but doesn't actually block on the target WAF platform doesn't ship.
Step 5: LLM-as-judge validation. A separate model, running in a different context from the rule generator, reviews the rule logic for correctness, completeness, and edge case coverage. A model reviewing its own output has a well-documented tendency to confirm what it generated. Using a separate evaluator breaks that loop.
Step 6: False positive analysis. This determines whether a rule is safe to deploy in block mode. More on this below.
Step 7: Rule deduplication. Before the rule is finalized, it's cross-checked against the existing rule set, both Miggo-generated rules and the WAF platform's managed rule groups. A rule that duplicates existing coverage adds evaluation overhead without adding protection, and isn’t shipped. A rule that conflicts with an existing rule gets flagged for resolution.
Step 8: Rule optimization. The rule's logic is analyzed against the target platform's evaluation constraints. On AWS WAF, this means Web ACL Capacity Units – the measure of rule complexity that determines what fits within a rule group's capacity budget. On Cloudflare, it means expression complexity and evaluation order. In both cases, if equivalent detection can be achieved with lower evaluation cost, the logic is restructured. Precision is not traded for efficiency; if the optimization changes the detection behavior, it doesn't happen.
The False Positive Problem, in Concrete Terms
Take CVE-2020-8163, a remote code execution vulnerability in Ruby on Rails. The vulnerability is in how Rails handles user-controlled input passed as locals to a rendered template: under certain conditions, ERB processes the locals hash as Ruby code, allowing an attacker to execute arbitrary commands on the server.
The canonical exploit looks like this:
curl -X GET '/pages/show?[system(%27id%27)end%00]'The system('id') call is URL-encoded, terminated with a null byte, and injected into the query parameter in a position where Rails' ERB engine will evaluate it. On a vulnerable application, this executes the id command on the server.
The false positive problem becomes clear when you look at what legitimate traffic to the same endpoint looks like:
curl -i 'http://target.example/pages/show?locals[user_name]=alice'This is a completely valid request. Rails applications routinely accept locals[] parameters as part of normal query-string handling. A rule that blocks on bracket notation in query parameters, or on the string locals[, will fire on this request just as readily as on the exploit. That's a false positive waiting to happen, and on a high-traffic Rails application, it would happen thousands of times a day.
The right rule doesn't match on bracket notation. It matches on the specific conditions that indicate ERB injection: the presence of Ruby method calls, system command patterns, and null byte terminators in positions where the ERB engine would process them. Getting this precision requires understanding the vulnerability at the code level, not the advisory level.
For the FP analysis stage, Miggo generates a corpus of semantically valid requests, requests that a real application would receive, including edge cases that superficially resemble the attack pattern, and fires them against the rule. The locals[user_name]=alice example is exactly the kind of request in that corpus: legitimate use of bracket notation that a naive rule would incorrectly block. Any rule that produces a false block on the valid traffic corpus is returned for revision. The rule doesn't ship until the valid corpus passes cleanly.
This isn't a guarantee of zero false positives in production. However, it provides documented evidence that the rule has been tested against a realistic valid traffic model, and the results were reviewed before deployment. That evidence is available. You can see the corpus and the results. That's what a white-box approach means in practice.
Vendor Opacity Is a Significant Problem
The major WAF platforms are beginning to explore AI-generated rules and AI-assisted vulnerability research. This is directionally correct – the manual approach doesn't scale, and the pace of CVE disclosure isn't slowing down. But there's an important distinction between a platform vendor applying AI to their own infrastructure and a platform vendor shipping AI-generated rules to customers through a transparent, auditable pipeline.
When a managed rule update arrives in your WAF, it includes a rule name, a description, and a block action. It doesn’t include the exploit corpus the rule was tested against, the false positive analysis results, or the evasion variants the rule covers. The pipeline that produced the rule is opaque by design and the vendor's methodology is their proprietary process, not something they're obligated to expose.
While opacity is a reasonable business decision, it’s also a significant trust problem for security teams who need to understand what they're deploying. A rule in block mode, deployed across production traffic, based on a pipeline you can't inspect, is a significant operational risk, especially in environments where a false positive is a sev-1 incident.
Security teams need to demand that custom, CVE-specific rules come with documented methodology. What exploit variants does the rule cover? What valid traffic corpus was used for FP testing? Was this tested on a live WAF instance? These are reasonable questions. A rigorous pipeline has documented answers.
Five Questions Worth Asking
If you're evaluating any AI-generated WAF rule, these questions separate a rule with documented methodology from a rule with a good description.
- What exploit variants does the rule cover? The canonical exploit form is the baseline. Evasion variants – URL encoding, Unicode normalization, obfuscation – are the harder and more important test. Ask to see the variant corpus.
- What valid traffic corpus was used for false positive testing? Specifically, does it include near-miss patterns – requests that superficially resemble the exploit but represent legitimate application behavior? The locals[user_name] example above is the kind of near-miss that exposes naive rules.
- Was this tested against a live WAF instance in before/after mode? Rule logic that looks correct and rule logic that actually blocks correctly when deployed are different things. Empirical testing is not optional.
- Has the rule been checked against existing coverage? A new rule that duplicates a managed rule group adds evaluation cost without adding protection. A new rule that conflicts with an existing rule can produce unpredictable behavior. Deduplication and conflict checking should be part of the generation process, not an afterthought.
- Has the rule been optimized for your platform's evaluation constraints? On AWS WAF, complex rules consume WCU capacity that affects what fits in a rule group. On Cloudflare, expression complexity affects evaluation performance. A rule that achieves the same detection with lower evaluation cost is strictly better, as long as the optimization is validated not to change the detection behavior.
Want to put these five questions to your own CVE inventory and see the pipeline in action? Request a POV.
