Detection content
Why Sigma won the detection-sharing decade.
For about ten years people have been trying to share security use cases with each other, in a handful of different forms: the Sysmon config you forked off SwiftOnSecurity, the hunt notebook you ran in Binder, MITRE's analytics in CAR, Red Canary's atomic tests, and Sigma rules. Some of that compounded into living community resources and most of it went stale, and the dividing line was not quality, because the best-annotated Sysmon config in the world froze in 2021 with its author's attention. The line was structural, and it's the same structure I argue for at the data layer: vendor-neutral, community-governed, portable. Sigma is the clearest proof of it, and the pattern is worth naming because it tells you what to bet on for the next format, before you've sunk a year into curating it.
Reading time: about 16 minutes. Evidence tier: B overall. Repository facts (stars, release dates, commit recency) are A/B from the projects' own GitHub metadata and releases, pulled in mid-2026 and subject to drift; the durability argument is B, built on a couple of clean natural experiments rather than a survey; the cross-engine-fidelity caveat is covered in more depth in the portability piece.
The configs everyone forked
The best Sysmon config froze, and it froze for a structural reason.
If you stood up endpoint logging any time in the last decade, you almost certainly started from SwiftOnSecurity's Sysmon configuration: a single, heavily annotated XML file that told you not just what to log but why, with the reasoning in the comments. It earned something like 5,500 stars and became the default starting point for an entire practice. Olaf Hartong's sysmon-modular came later and improved on it, breaking the monolith into composable pieces tagged to ATT&CK techniques so you could assemble the config you needed. Both were genuinely good, both were plain text in git, and both are now frozen: SwiftOnSecurity's has had no commits since 2021, and sysmon-modular stalled in the summer of 2024, with issues still arriving and going unanswered. (Tier B, from the repositories' commit histories.)
It would be easy to read that as decline and move on, but it's actually a clean experiment, because the thing that stopped was not the quality of the work and not the format. The configs were excellent and they were text-in-git, which is supposed to be the thing that makes content durable. What they were was single-maintainer, resting entirely on one person's continued attention, and the moment that attention moved the work ossified in place. The telemetry kept evolving, Sysmon kept shipping new event types, the adversary kept changing, and the config sat where it was. Nobody did anything wrong; the structure just had a single point of failure, and over a long enough horizon single points of failure fail.
Hold that next to what didn't freeze, because the contrast is the argument. The energy that used to go into curating a shared Sysmon config didn't disappear, it moved up a layer, into the detection rules that consume Sysmon telemetry rather than the config that produces it. And the place it moved to was governed differently.
What didn't freeze
Sigma kept moving because no one person and no one vendor carries it.
The SigmaHQ ruleset carries on the order of three thousand rules across something like ten and a half thousand stars, with a fresh release in April 2026 and the cadence to match. (Tier A/B, from the project's releases and repository metadata.) It is maintained by a named core team rather than a single author, Nasreddine Bencherchali, Florian Roth, Christian Burkard, François Hubaut, and Thomas Patzke, with several hundred contributors behind them, and that is the first structural difference from the configs: the project survives any one maintainer's attention wandering, because no one maintainer is the project.
The second difference is the one that actually made it scale, and it's an architecture choice rather than a governance one. Sigma split the rule format from the conversion. The rules live in the main repository as vendor-neutral YAML, and the machinery that turns a rule into Splunk SPL or Elastic EQL or a Sentinel KQL query lives outside it, in pySigma and its backends, which the vendors and the community maintain at the edges. That sounds like a small packaging decision, but it's why Sigma became a standard rather than a popular repo. Because no single converter gates the format, a new backend can appear without anyone at the center approving it, and a vendor can support Sigma without ceding control of anything, so the incentives all point toward more coverage rather than toward a bottleneck. The earlier monolithic-converter design, where one tool had to know every target, is exactly what this replaced, and the replacement is what let the ecosystem grow past what any core team could have hand-maintained.
So the two things the frozen configs lacked, Sigma has by construction: governance that outlives any one person, and a portability layer that no one vendor controls. That durability comes from the structure and not from popularity, and once you see that, you can go looking for the same structure in the other things that did or didn't last.
The pattern, ranked
Five properties predict whether shared security content lasts.
Reading across the survivors and the casualties, the properties that actually predict durability sort into a rough order, strongest first, and the order matters because the top one does most of the work.
- Vendor-neutral, with a portability layer no one controls. This is the strongest single predictor, and Sigma is the proof. Content that converts to any engine, through machinery the vendors don't gate, outlives content welded to one product. Every engine-bound corpus stays alive only as long as its vendor funds it, and dies with the product line.
- Community governance over single-maintainer. The clearest natural experiment in the whole space: Sigma with a five-person core team and hundreds of contributors keeps moving, while SwiftOnSecurity and sysmon-modular, each carried by one person, froze in 2021 and 2024. Multi-maintainer projects survive contributor turnover; one-author projects inherit one author's bandwidth.
- Mapped to a shared coordinate system. Sigma, Atomic Red Team, the vendor corpora, and CAR all map to MITRE ATT&CK, and that mapping is what lets otherwise-incompatible content be found, compared, and reasoned about together. A technique ID is the join key that turns a pile of rules into a navigable library.
- Text in git. Necessary and not sufficient. Every survivor is plain text under version control, but so were the frozen configs, so this one is table stakes rather than an edge. It earns a place on the list only because content that isn't text-in-git, the notebook corpus most of all, had a harder time being reviewed, diffed, and trusted.
- Executable and testable. Content you can run keeps itself honest, because a broken test is visible and a stale one nags. This is why a separate execution corpus grew up next to the rule corpus rather than one format trying to do both.
The thing to notice is that none of these is about the YAML. They're about ownership and governance, the same axes that decide whether a data format or a query engine is something you own or something you rent. Detection content turns out to obey the same economics as the data layer underneath it, which is the reason this essay sits in the same body of work as the storage and engine pieces rather than off in a detection-engineering silo.
The edges of the pattern
The other corpora confirm it, including the ones that died.
Atomic Red Team is the healthiest project in the whole survey, around twelve thousand stars, MIT-licensed, still updated in mid-2026, maintained by Red Canary (now a Zscaler company). It's a library of small, runnable adversary-emulation tests mapped to ATT&CK, and its durability comes partly from being executable: a test that stops working announces itself, which gives contributors a standing reason to keep it current. It pairs with Sigma rather than competing, the rules being the detection side and the atomics the validation side, which is itself evidence that one format trying to be both detection and test tends to lose to two formats that each do one job well. (Tier A, from the repository.)
The vendor corpora are the controlled comparison on the neutrality axis. Splunk's Threat Research Team publishes its ESCU content openly, well over two thousand detections on a monthly cadence, and Elastic's detection-rules repository is similarly active. (Tier A for the artifacts, Tier C-flagged because they're each a vendor's own content channel.) Both are genuinely good and genuinely maintained, and both are engine-bound, which means their health is a function of their vendor's continued investment rather than a community's. They're alive because Splunk and Elastic fund them, and that's exactly the dependency Sigma's design removes. MITRE's CAR is the other instructive case: a knowledge base of analytics with multi-engine pseudocode, conceptually upstream of everything here, that in practice got passed by SigmaHQ and the vendor repos and now reads as a slow-moving reference instead of content you deploy.
And the hunt-notebook corpus is the casualty that's most relevant to where the field is heading. The notebook movement around Jupyter, msticpy, and the Open Threat Research projects was influential and pedagogically rich, and it never became the durable, shareable operational format, in part because notebooks failed the text-in-git test that the configs and Sigma passed. I worked through why notebooks settled into the exploration-and-teaching niche instead of the system-of-record niche in the piece on where detection notebooks should live; the short version is that the format made review and reproduction harder, and content that's hard to review is hard to share with confidence.
The honest limit
A shareable rule is not the same as identical detection.
The place this argument can overreach is in conflating "shareable" with "works the same everywhere," and I want to be careful about it, because the difference is where the real engineering still lives. Sigma having won as the authoring-and-sharing format does not mean a Sigma rule fires identically on Splunk and on Elastic. The conversion is solved; the field mapping underneath it is not, because the same logical field lands in different places, with different normalization, in different backends, and a rule that assumes one schema can silently underperform against another. That is the same context-collapse problem that dogs OCSF normalization, reappearing one layer up at the rule.
So the honest claim is bounded. Open, community-governed, portable content wins the durability and sharing contest over a multi-year horizon, and that is a strong and useful result on its own. It does not win you guaranteed cross-engine detection equivalence, which remains a per-backend correctness problem you have to test rather than assume, and which I take apart in the portability piece. Keeping those two claims separate is what keeps the argument credible; the people who oversell Sigma as turnkey cross-engine detection are handing the skeptics an easy rebuttal.
What to bet on next
Run the same five questions at whatever wants to be the next standard.
The reason to extract the pattern rather than just admire Sigma is that the field keeps producing new candidates for shared content, the detection-as-code platforms, the agentic and MCP-packaged content that's arriving now, whatever comes after, and you have to decide which to invest a curation budget in before the history is written. The five questions are the test. Is the format vendor-neutral, with a portability layer nobody controls, or does it convert to one product. Is it governed by a community or carried by one maintainer or one company. Is it mapped to ATT&CK so it can be found and compared. Is it text under version control so it can be reviewed. Can you run it to keep it honest. Content that answers those the way Sigma does has a structural reason to last; content that doesn't is borrowing against one person's stamina or one vendor's budget, and you should price it accordingly.
That test is the same one a capability matrix applies to tooling, pointed at content instead, and it lands on the same place the rest of this work does: the durable thing is the open, owned, community-governed one, and the proof is not a preference but a decade of repositories you can go read, some still shipping releases this spring and some last touched in 2021.