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. Usually nobody does, 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. So the gap sits open: the advisory is triaged, the ticket is filed, the fix is scheduled, and for weeks there is nothing in front of the vulnerable code at all.
We were already holding the one thing that closes it. Every exploit published for a vulnerability is in the Vulnetix database, because we collect them for exploit intelligence. What was missing was the step that turns an exploit into something deployable.
Two families, eleven formats
Virtual patches stop the attack before it lands: Snort, Suricata, nginx ModSecurity, AWS WAF, Cloudflare WAF and the layer 7 patterns underneath them. Countermeasures catch it once it has: Sigma for your SIEM, YARA for your endpoints, STIX 2.1 for your threat platform and OpenIOC for a host sweep.
Which family a vulnerability gets is not a preference. It is decided by what the published exploits actually leave behind: an exploit carried in an HTTP request admits a WAF rule, a local privilege escalation does not and admits a Sigma rule instead, some admit both, and some admit neither. That last case is recorded rather than papered over, because a rule that never fires reads as coverage you do not have.
Who this is for
Platform and network operations
A critical advisory lands on a Friday. The fix needs a release. What you can do today is put a rule in front of it, and now that rule already exists, written for the sensor or the edge you already run.
SOC detection engineering
The detections you have not written yet are the ones tied to vulnerabilities nobody has exploited near you. These arrive with the exploit attached, so you tune from evidence rather than from a paragraph of prose.
Risk, GRC and audit
A deployed rule with named coverage limits is a far stronger artifact than a promise to patch next quarter, and it is what an auditor asks for when a remediation deadline slips.
Three ways to use it
Every finding in the console now has a Defence tab listing what can be deployed for that vulnerability, the mode it is safe to start in, and what it will not catch. Curate rules into a feed and point your sensor, edge or SIEM at the URL. Or take them one at a time from the CLI, which hands you any rule in its native format, named the way its tool wants it.
Available now
Included from Pro, in the console, the API and the CLI. The count of what exists for any vulnerability is visible on every plan, because knowing a defence is available for something you are running is a safety message and not a paid feature. See Virtual Patching, Countermeasures and pricing.