The gap nobody owns. Ask a security team what they do about a critical vulnerability with a public exploit and no available patch and you will usually hear that someone will write a WAF rule. Sometimes that happens. Usually it does not, because writing one means reading the exploit, working out what it looks like on the wire, and knowing the quirks of whichever product sits at the edge. That is a specialist afternoon per vulnerability, and nobody has one per vulnerability.
How we decide what to build
We obtain the exploit
Every proof of concept, exploit script and weaponised payload published for a vulnerability is collected into the Vulnetix vulnerability database, from roughly twenty five sources.
The Vulnetix Team evaluates it
Each exploit is read and one question is answered: where can this actually be caught? Some leave a signature on the wire, in a request an edge or a sensor can inspect. Some act only on the device. Some do both, and some leave nothing observable at all.
That answer decides the format
An exploit carried in an HTTP request admits a WAF rule. One speaking a raw protocol admits a packet signature and not a WAF rule. An exploit that admits neither is recorded as admitting neither.
We build only what fits
Each rule is written for its own target and validated against that target rules before publication. A signature the sensor would reject, or a rule referencing logic it never declared, does not reach you.
Written for the tool, not translated into it
Snort
Signatures for the sensors already watching your north-south traffic.
Suricata
Application-layer aware rules that use the protocol parsers Suricata gives you.
nginx ModSecurity
SecRule directives in an id range that cannot shadow the OWASP Core Rule Set you already run, and a snippet that includes inside an existing server block rather than opening its own.
AWS WAF
A single WAFv2 Rule object, so it merges into your WebACL instead of replacing it.
Cloudflare WAF
One expression in the Rules language, ready for a custom rule.
Layer 7 regex
The underlying pattern, checked so hostile input cannot turn it into a denial of service.
Deploy it the way you already deploy rules
Curate the rules you want into a feed, publish it, and point your sensor or your pipeline at the URL. It fetches the file it expects, with a checksum beside it. Rules you are not ready to enforce publish commented out and switch on when you are. Or take them one at a time: the console, the API and the CLI all hand you the rule body in its native format, named the way its tool wants it.
What we will always tell you
Every rule states the mode it is safe to start in, and what it does not cover including the evasions it would not survive. A virtual patch is a control, not a fix: it buys you the time to patch properly, and it does not replace patching. Where an exploit admits no blocking rule at all, we record that rather than publishing something that would never fire.
For the vulnerabilities nothing at the edge can see, the detection side is Countermeasures.
Virtual Patching FAQ
What is virtual patching?
Deploying a rule that blocks the exploit for a vulnerability while the actual fix is still pending. It does not change the vulnerable software; it stands in front of it at an edge, a proxy or an inline sensor, so the attack never reaches the vulnerable code.
Where do the rules come from?
From the exploits themselves. Vulnetix collects every proof of concept and exploit script published for a vulnerability, and the Vulnetix Team evaluates each one for where the attack can actually be observed. That answer decides which formats the exploit admits, and only those are built.
Which products can load them?
Snort and Suricata sensors, nginx with ModSecurity, AWS WAF, Cloudflare WAF, and anything that takes a layer 7 regular expression. Each rule is written for its own target rather than translated into it: the AWS rule is a single WAFv2 Rule object that merges into your existing WebACL, and the nginx snippet is written to be included inside a server block you already have.
Is it safe to deploy in blocking mode straight away?
Every rule states the mode it is safe to start in. Where we judge that a rule could misfire it arrives recommending log only, with the reason stated, and every rule documents what it does not cover including evasions it would not survive. A virtual patch is a control that buys time to patch properly; it is not a replacement for patching.
What if a vulnerability has no virtual patch?
That is recorded rather than papered over. A logic flaw with no signature, an authenticated action indistinguishable from ordinary use, or a proof of concept too thin to build from will admit no blocking rule, and we say so. A rule that never fires reads as coverage you do not have, which is worse than knowing there is none. Many of those vulnerabilities admit a countermeasure on the endpoint instead.