From vulnerability to detection

AI scanners now read code, find real vulnerabilities, and in many cases confirm them with a working reproduction. On the vendor side, CISA's catalog of known exploited vulnerabilities stood at 1,734 entries this week, with 300 added in the last twelve months. Attackers have access to the same class of tools.

Patching has not sped up at the same rate. Change windows, regression testing, and vendor fixes that arrive late all set the pace. The result is simple arithmetic: at any given moment, more vulnerabilities are known and exploitable than are fixed.

Every vulnerability has a window. It opens when the vulnerability is known and closes when the fix is running in production and proven to work. What fills that window depends on whose code it is:

• Custom code: the fix exists, often an AI-generated patch, but it is still in review, testing, and the release cycle.
• Vendor code: you are waiting on the vendor to ship a patch, and then on your own change window to apply it.

Mitigations can reduce exploitability, but inside that window, detection is what tells the SOC whether someone is trying. By detection I mean a SIEM detection rule that matches an exploit attempt in the logs you collect; I'll call it a rule for short. Without it, you may hear about the attempt later, from the incident.

In Handling the Vulnerability Deluge Without Panic I argued for prioritizing the flood. This piece asks what the SOC can watch for while the fix is still coming.

I keep seeing the same gap from two directions:

• Custom code: an AI scanner confirms a vulnerability, it goes into a ticket, and everyone waits for the patch, increasingly an LLM-generated one. No one writes a rule for the meantime.
• Vendor code: an advisory says a CVE is exploited and indicators are published. Sometimes a rule follows. Often it exists only in another SIEM's language, or not at all.

In both cases the burden of turning a vulnerability into a detection lands on the customer's SOC, the team with the least time to do it.

To see how thin open coverage is, I checked every CVE on CISA's exploited list against four widely used open SIEM rulesets: SigmaHQ, Splunk, Elastic and Google SecOps community rules. A CVE counts as covered if any rule in any of the four mentions it.

Some of that gap is by design. Open rulesets favor behavior, like "web server spawns a shell," which catches many exploits without naming any. Network devices are often covered by IPS signatures and vendors' private content. Some vulnerabilities leave little in logs at all. But none of that answers the question a SOC gets the day a CVE lands: are we covered for this one, on these assets, with the logs we collect?

• A behavior rule still has to be mapped and tested against the CVE.
• Private content only helps if you bought it.
• A vulnerability with no log signature still needs a clear "patch only" answer.

All of that work lands on the customer, and for nine of every ten new exploited CVEs, there is no open rule to start from.

The pieces already exist. Scanners find vulnerabilities. Open rulesets hold a lot of detection content. Models can draft and translate rules. What is missing is the sequence that connects them, so that every vulnerability you find ends in one of three places: a rule you deploy, a log you start collecting, or a clear statement that only the patch will help.

Four design choices matter most:

• Every vulnerability, no triage gate. Nobody should have to decide first whether a vulnerability is exploited or important enough. Exploitation data can set the order of the queue, but it should not decide what gets a rule.
• Check coverage before writing anything. Often a rule already exists in another format and only needs translating, or it exists and the asset doesn't send the log it reads. That is a log pipeline fix, not a new rule.
• Verify every rule in layers before it alerts, covered in section 7.
• Keep the rule on after the patch as insurance, until the fix is proven and no unpatched copies remain, then retire it so the ruleset doesn't grow forever.

To test whether this holds up outside a diagram, I built it, and ran it on two targets:

• Custom code: a deliberately vulnerable open source web app, scanned by VVAH, Visa's open source vulnerability harness.
• Vendor code: a fictional company I called Example Corp, with real, publicly listed exploited CVEs mapped onto its assets.

For each vulnerability, the flow checks coverage against four open rulesets, has a model draft or translate a rule where none exists, and runs agentic checks on every draft. AI wrote the code under my direction; I set the requirements and made the calls on what went in. Everything uses public sources, and there are no exploit details on this page.

Custom code. VVAH confirmed 63 vulnerabilities in the test app, found and verified in a lab rather than seen exploited in the wild. The flow gave every one of them an answer:

• 18 covered by just 5 rules. One of them, the app spawning a shell, covered 12 on its own.
• 8 need request-body logging, which ordinary web logs don't record.
• 17 need behavioral baselines, because the attack looks like a normal request from the wrong person.
• 20 leave no signal at request time, so the patch is the only control.

Detection engineering cannot manufacture telemetry that does not exist, but knowing which bucket a vulnerability falls into is useful even when the answer is "patch it."

Vendor code. Example Corp had 99 exposures to known exploited CVEs. I started with these because that is where public detail exists to write a rule from; the flow treats every other vulnerability the same way.

The 11 surprised me most. A public rule already existed, written for Splunk or Elastic. They were still gaps, because a rule that isn't deployed detects nothing, and it has to be converted to whatever SIEM you run before it can be. But translating an existing rule is far cheaper than writing a new one, and a model is good at it. In the flow, the model translates it to Sigma, an open rule format that converts to most SIEMs.

A model can draft a rule in seconds, but a bad rule costs more than no rule. A noisy one burns analyst time. A silent one gives false confidence. Today every rule waits for a detection engineer to read it, and as volume grows, that review becomes the slowest step.

So I put layers of agentic checks in front of the reviewer. By the time a rule reaches a person, it has already been checked and questioned, and approval is quick. Each layer catches what the one before it cannot. I built the first two.

Layer 1Automated checks

Each rule must be valid Sigma, read a log the asset actually sends, and use only values that appear in the source material. That last check earned its place: in one case a model wrote a rule from what it remembered about a CVE instead of the sources it was given, and the check flagged every value as untraceable.

Layer 2An AI reviewer

A second model, separate from the one that drafted the rule, reviews it the way a detection engineer would. Would it fire on normal traffic? Is it really about this CVE? Did a translation change the logic? Do our logs carry the fields it needs? I first did this review in a working session, then automated it as a step in the flow. It caught:

• A rule that would have fired on every failed VPN login, not only the targeted one.
• A "CVE rule" that was really a generic Java-spawns-a-shell rule with a CVE name on it.
• A translation stricter than its source, which would have missed variants the original caught.
• Web-request rules for assets whose firewall logs contain no URLs, so they could never fire.
• Rules for hosts already on a fixed version, where a hit means an attempt, not a compromise.

All of this happened before any person looked at a rule. But the two reviews did not always agree on what to do with a rule. An AI reviewing an AI is still an opinion, not evidence.

Layer 3Prove it before it alerts

A natural extension is a third layer: proof. Many AI scanners already produce a working reproduction of the vulnerability. Replay that attack in your SIEM's development environment and confirm the rule fires. It never touches production, and it turns a reviewed rule into a proven one.

The standard is simple: a rule fires on the attack, in your own SIEM, on the logs you actually collect. The reviewer then approves on evidence and spends their time on the exceptions.

The repository has two programs, one per input:

• Custom code (vvah_to_sigma) works like a translator. It turns a known weakness type into a rule template. No model is needed, because VVAH has already done the analysis.
• Vendor code (exposure_to_sigma) works like a detective. It first asks whether a rule already exists and would fire on your logs, and drafts one with a model only when it does not.