The detections nobody gets to. A detection backlog is never short of ideas; it is short of the hours to write and tune them. The ones that slip are the detections tied to vulnerabilities that have not yet been used against you, which is precisely the set worth having before they are.
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? Many leave nothing on the wire and act only on the device, leaving a process spawned, a file written, a key set or a payload resident in memory.
That answer decides the format
Behaviour on a host is a Sigma rule. Content in a file or in memory is a YARA rule. Infrastructure the exploit reaches out to is an indicator your threat platform can pivot on.
We build only what fits
Each rule is validated against its own format before publication. The failures that matter most are the quiet ones, a rule that converts cleanly and then matches nothing, and those are exactly what we check for.
Four formats, written for their tools
Sigma
A rule your SIEM converts to its own query language. Every search identifier the logic names is declared, so it converts to something that actually matches.
YARA
For the endpoint and for memory. Every string the condition references is declared, because a missing one stops the whole file compiling, not just that rule.
STIX 2.1
A bundle your threat platform imports, with the vulnerability, the indicators and the relationships between them intact.
OpenIOC
A document for a host sweep, with real artifact terms rather than free text.
Which means they load into what you already run: Splunk, Microsoft Sentinel, Elastic Security, IBM QRadar, OpenCTI, MISP, Cortex XSOAR, Tines, and any YARA-capable endpoint agent. See the STIX integrations for the per-tool setup.
Subscribe to it, do not copy and paste it
Curate the detections you want into a feed, publish it, and point your SIEM or your threat platform at the URL. Sigma publishes as a document stream your tooling reads directly; STIX publishes as one bundle rather than a directory of them. Detections you are not ready to run publish inert and switch on when you are.
What we will always tell you
Every rule states how likely it is to misfire and what a false positive would look like, and what it does not cover including the variants it would miss. Detection is not prevention: these tell you it happened, which is worth a great deal, and is not the same as stopping it. For the vulnerabilities that can be stopped at an edge, the blocking side is Virtual Patching.
Countermeasures FAQ
What is a countermeasure?
Detection content for a vulnerability, built from the exploits actually published for it. Where a virtual patch blocks the attack at an edge, a countermeasure observes and reports it on the device, so it covers everything the network never sees: local privilege escalation, weaponised documents, payloads that only unpack in memory, and anything behind a VPN.
Which formats do you produce?
Sigma for a SIEM, YARA for an endpoint or memory scan, STIX 2.1 for a threat platform, and OpenIOC for a host sweep. Each is written for its own target: the Sigma rule declares every search identifier its condition references, and the YARA rule declares every string, because a missing one stops the whole file compiling rather than just that rule.
What can consume them?
Anything that reads those formats. Splunk, Microsoft Sentinel, Elastic Security and IBM QRadar for Sigma; any YARA-capable EDR; OpenCTI, MISP, Cortex XSOAR and Tines for STIX. You can also subscribe your tooling to a published feed rather than copying rules by hand: Sigma publishes as a document stream and STIX as a single merged bundle.
How is this different from a generic threat intelligence feed?
It is keyed to vulnerabilities rather than to campaigns, and every artifact names the exploit it was derived from. That means you can tune from the evidence rather than from a description, and you can prioritise by which of these vulnerabilities your own findings say you carry.
Do these replace detections my team writes?
No. They are a starting point for the detections tied to vulnerabilities nobody has yet exploited near you, which is exactly the part of a detection backlog that never gets written. Every rule states how likely it is to misfire and what it does not cover, so tuning it is the expected next step rather than an afterthought.