About Sigma Watch

The question that started it

A CVE drops. It trends. Within a day somebody on your team is asking whether we need to write a detection for it — and the honest answer is usually "let me go look." That means opening several repositories, each with its own file format and its own conventions, and grepping around for a CVE ID that may not appear in any structured field at all. I have burned afternoons on that lookup, and the worst part is that the answer was frequently "yes, SigmaHQ shipped one four days ago."

So I built the thing that answers it in two seconds. Sigma Watch continuously tracks seven public detection ecosystems - SigmaHQ, Elastic detection-rules, Splunk ESCU, YARA (Yara-Rules/rules), Microsoft Sentinel analytics rules, and the Snort/Suricata network signatures in Emerging Threats Open - extracts every CVE and ATT&CK technique each rule actually covers, and cross-references all of it against NVD, CISA KEV, and the MITRE ATT&CK catalog. One search box, one answer.

The half I actually care about

Coverage lookups are useful. The gap list is the reason I kept building. Filter to CVEs that CISA has confirmed are being actively exploited and that have no rule in any of these repositories, and you get a short, specific list of vulnerabilities where writing your own detection is demonstrably worth the hours. That list is not published anywhere else that I know of, and it is the part of this tool I would check on a Monday morning.

How coverage is determined

Each source exposes its metadata differently, and this matters more than you would expect — so here is exactly what happens rather than a vague claim about "parsing rules":

Where a structured field exists, I read it. Where it does not — Elastic and Sentinel always for CVEs, Sigma most of the time, YARA essentially never for either — I pattern-match CVE IDs and ATT&CK technique IDs out of whatever free text the rule actually has. Every link is stored with how it was found, so the distinction is preserved in the data even though the interface presents both the same way. In practice the inferred matches are reliable, because rule authors put the CVE in the title when the rule is about a CVE. But "in practice reliable" is not "guaranteed correct", and you should know which one you are looking at.

What a "gap" does and does not mean

A gap is a CVE published — or added to CISA KEV — inside the window you selected, with no non-deleted rule in any of these repositories referencing it. That is a precise, checkable claim, and it is narrower than it sounds.

It does not mean no detection exists. Your EDR vendor almost certainly ships private coverage that no public repository knows about. It does not mean you are exposed, and it is not a risk score. Treat the gap list as a research shortlist for rule authoring, not as an audit of your security posture — anyone selling you the second interpretation is overselling this data, and I would rather say so myself than have you find out later.

The other honest limitation: a rule that detects a CVE's exploitation technique without ever naming the CVE will not be credited here. Behavioral rules covering a whole technique class are common and genuinely valuable, and this tool systematically undercounts them. That is a real weakness of CVE-keyed coverage analysis, not an implementation bug I plan to fix.

Data sources

The five git-hosted sources (Sigma, Elastic, Splunk ESCU, YARA, Sentinel) are cloned locally and re-synced on a schedule, diffed commit-to-commit so changes are picked up without hammering anyone's API. Snort and Suricata come from Emerging Threats Open instead, which isn't a git repository but a periodically-updated downloadable bundle - those two are re-synced the same way, just diffed by content hash against the previous download rather than by commit. CVE metadata comes from the NVD API; exploitation status comes from CISA's Known Exploited Vulnerabilities catalog; technique names and tactics come from MITRE's ATT&CK STIX data. Everything this site knows is also available as JSON at /docs, free and unauthenticated.

Methodology note: all coverage data on this site is derived from the public contents of the seven sources named above, parsed automatically, with no manual curation. Nothing here is vendor-supplied and nothing is sponsored. Where a rule's CVE reference was inferred from free text rather than read from a structured field, that inference is recorded in the underlying data and available through the API.