DetectionForge
Give it raw threat intelligence; it returns validated Sigma, SPL, and KQL detection rules - grounded in MITRE ATT&CK and self-corrected until they actually parse. A working Splunk detection engineer reviewed it.
The problem it solves
Writing detection rules by hand is slow, and the same logic has to be re-expressed for every SIEM - Sigma for portability, SPL for Splunk, KQL for Sentinel. DetectionForge takes unstructured cyber threat intelligence and produces vendor-agnostic rules across all three, cutting the manual rule-authoring effort that eats a detection engineer's day.
How it works
A Gemini-powered pipeline drafts the rules, but the interesting part is what keeps them honest. A MITRE ATT&CK-based retrieval layer grounds each rule in the right technique rather than letting the model free-associate, and a self-correcting pySigma validation loop parses every generated rule, detects malformed output, and feeds the errors back in to fix it automatically - so what comes out is syntactically valid, not just plausible-looking.
Measured, not assumed
The whole pipeline is scored against a custom evaluation harness, reaching a ~0.750 aggregate score - a real number to iterate against rather than a vibe. The point was to treat rule generation as something you can measure and improve, the same way you'd tune any detection.
Reviewed by a real detection engineer
To check it against reality rather than my own assumptions, I put it up for community review on r/blueteamsec and incorporated detailed feedback from a practising Splunk detection engineer, then submitted the project to Kaggle's 5-Day AI Agents hackathon. Outside review from someone who writes detections for a living is the closest thing to a production sanity check I could get as a student.
| Format | Target | Grounding |
|---|---|---|
| Sigma | Vendor-agnostic | MITRE ATT&CK retrieval |
| SPL | Splunk | MITRE ATT&CK retrieval |
| KQL | Microsoft Sentinel | MITRE ATT&CK retrieval |