Executive Summary

Key Numbers

Source: Sudaroli Dhananjeyan, Kumaran U, The Exclusion Ratchet: False-Positive Suppression Accumulates and Persists in Detection Rule Repositories, arXiv:2608.31062 (August 31, 2026)

Before any statistics, the paper shows the history of a single rule. image_load_dll_vss_ps_susp_load.yml alerts when a process loads the Volume Shadow Copy Service proxy library. Loading it is characteristic of programs that manipulate shadow copies. Backup and servicing software does it all day, and ransomware does it immediately before encryption. Ordinary behavior and hostile behavior emit the same signal.

So exclusions kept accruing on this rule. The reconstructed history holds 27 of them, and 24 are still in force at the snapshot. The three that lapsed were not reconsiderations either. Exclusions written as dismhost.exe and taskhostw.exe in July 2021 disappear in June 2022 and come back the same day under the identical names with a leading separator. The third swapped a contains-match for a startswith-match. The authors record this against themselves before anyone else can: the detector sees three relaxations here, and none of them relaxes anything.

The breadth of what was excluded did not hold still either. For the first fifteen months every exclusion named one specific binary. A single revision on October 31, 2022 brought in three directory trees at once: C:\Windows\, C:\Program Files\ and C:\Program Files (x86)\. The first landed in a block that already required a Windows prefix, so it changed little. The other two were new. An attacker cannot write into Program Files without escalating first, but one who has escalated inherits the whole tree for this detection.

Whoever added it knew that. The rule body carries a comment addressed to the people who deploy it.

The comment has stood unchanged for three and a half years. It says the exclusion is provisional and it says how to tighten it, and nobody has tightened it. Every organization that pulled the rule over those years pulled the exclusion along with it. That is why the paper opens here. The individual decision was sound, it was taken knowingly, it was even annotated with its own remedy, and it is nonetheless permanent.

The corpus is 3,110 files in the main SigmaHQ rule set and 4,204 version histories. The 2,355 histories carrying at least one revision that actually changed detection logic are the study population, and the 8,234 revisions inside them are the unit of analysis. The oldest version dates to December 27, 2016 and the last revision to April 1, 2026, an observation window of 9.3 years.

One problem had to be solved first: how do you tell that a rule got narrower? Earlier work compared rule structure between versions, counting predicates and blocks and reading the shape of the condition line. But there are two ways to add an exclusion. You can write a new exclusion predicate, or you can append one more value to an exclusion list that already exists. The second touches no predicate count, no block count and not one character of the condition.

The paper also counts how badly structural tools handle the first form. Wrapping an exclusion in a negation inverts the polarity of every operation inside it, and appending a value moves no structure at all. Of the 8,234 revisions, 3,231 carry a predicate under negation and 4,174 involve a predicate-value update, with 5,927 (72%) hitting at least one of the two. The structural classifier the authors built first surfaced events on sole-coverage rules that turned out on inspection to be housekeeping: a sweep removing deprecated hash-field syntax, sub-technique retagging, a file rename. The classifier was careful and it was wrong, as they put it.

Of the 1,642 exclusion additions the paper does detect, 1,139 take the first form and 503 the second. That second share is 31%. Structural comparison cannot see those 31% even in principle, so every existing count of rule evolution has been undercounting narrowing by roughly a third. The blind spot is not specific to Sigma. A field whose value is a list counts as one term in an expression no matter how many items sit inside it, and that property is shared by most detection rule formats and configuration languages. The paper names Splunk Security Content, Elastic detection rules, YARA string sets and firewall object groups outright. Measure the set of literals as well as the set of predicates, it argues, or accept a known undercount and say so.

Counted at both levels, exclusions were added 1,642 times and withdrawn 304. That is 5.4 to 1. The authors checked whether a noisy minority of rules inflated it. Conditioning on the 559 histories whose exclusion set was ever modified, 481 of them (86.0%) end the observation period narrower than they began, against 37 that end wider and 41 unchanged. At the level of the rule the ratio is 13 to 1. Rules that narrow tend to narrow repeatedly, while rules that widen do so once, and that asymmetry is what opens the gap.

Where the asymmetry comes from is written into the format itself. When exclusion blocks are named individually the condition line has to name each one, so every further exclusion requires an edit to that line. Mature rules commonly switch to wildcard grouping instead. Once a condition reads not 1 of filter_main_*, adding an exclusion means writing a new block and doing nothing else. The cost of adding falls to very nearly zero. The cost of removing does not fall with it, because removal requires knowing what the exclusion was for, whether the circumstance that prompted it still holds, and whether anything since has come to depend on it. Adding is somebody's task at the moment the noise appears. Removing is nobody's.

2.1How Far Can These Numbers Be Trusted

The twenty busiest days account for 326 suppressions, 20% of the total, but they are spread from 2022 to 2025 and come from 524 distinct histories. Dropping those days entirely leaves the ratio at 4.9 to 1. The placeholder rules the repository keeps as templates were checked separately and contributed two additions and no withdrawals, which changes nothing.

The detector itself was validated by hand. Blinded labeling of 120 items gave a precision of 0.828, and recall estimated by stratification came to 0.911. Applying that precision, the 1,642 detected suppressions imply roughly 1,359 real ones, though the paper notes that classification error hits numerator and denominator alike, which makes the ratio sturdier than either absolute count. The failures are reported too. Twenty-seven items (22.5%) could not be decided from the diff by a human either, which is a statement about the phenomenon: the line between narrowing and rewriting is genuinely hard to draw without knowing the environment the rule runs in. Commit messages, withheld during labeling, were matched afterward. Reason language such as false positive or benign appears in 30.9% of suppression commits against 3.0% of the remaining revisions, a 10.3-fold enrichment. Here again the paper draws its own line: the defensible claim is the 10.3-fold ratio, not the 30.9% itself, because these data cannot say what the other 69% were about.

The study sits on a pipeline released by prior work. An error there would be inherited silently and would never surface in any result, so the authors re-ran the earlier paper's tables first to check that the figures reproduced. Four discrepancies came out of that exercise and were reported to the original authors. One of them will look familiar to anyone who works with data. Different filters had been applied to the version list and the commit list in the lineage metadata, so joining the two by position recovers the correct commit only 19.7% of the time. The rest come back wearing a plausible face. A join that fails silently and returns a sensible-looking result, the paper says, is the kind of error most worth reporting. Every later match to commit metadata was made on commit date or commit hash instead.

The authors call their figures a lower bound rather than an estimate. Generalizations, compound revisions and case-variant cleanups are all forms of narrowing the detector misses, and all three push the ratio down. The removal test compares counts rather than identities, which can only overstate how often exclusions come out, so the 86.7% persistence figure is a lower bound as well.

Duration can be measured for 1,584 exclusions. Of those, 203 were later removed and 1,381 were still in place at the snapshot. Dropping the ones still alive would produce a lifetime shorter than the truth, so the paper treats those 1,381 as right-censored observations and runs survival analysis. The result: 96.6% survive one month, 93.3% six months, 89.9% one year and 86.7% three years.

The first thing anyone looks for in survival analysis is the median lifetime, the point at which half are gone. The paper does not report one, because there isn't one. The curve never falls to 50%. What it reports instead is restricted mean survival time over three years: 978 days out of 1,095. An exclusion spends about 89% of its first three years in force. Nor is this an artifact of a short observation window. Median follow-up, estimated by reverse Kaplan-Meier, is 1,296 days, longer than the horizon at which persistence is reported.

The exclusions that do get removed follow an early-or-never pattern. Of all removals, 52% happen within six months and 76% within a year, after which the removal hazard approaches zero. Someone notices an exclusion soon after it is made and takes it out. Past that window, nobody touches it again.

The authors locate the cause at the point where review begins. Review of a detection rule is prompted by that rule firing. An analyst sees an alert, investigates, decides whether it was worth having, adjusts the rule. But an exclusion stops exactly that alert on the region it covers. The rule keeps firing on everything else and keeps looking healthy, while the covered region produces no evidence at all. Not evidence of absence, but the absence of evidence. An exclusion removes the signal that would have prompted its own reconsideration, and the longer it stands, the less likely anything is to raise it. The authors attach a caveat here: they claim no causation, only an explanation consistent with the shape of the data.

3.1Being the Last Line of Defense Made No Difference

If exclusions were managed with any regard to consequence, the ones sitting on the only rule that watches a given technique should be revisited sooner. The corpus covers 329 ATT&CK techniques, and 84 of them, a quarter, are covered by exactly one rule. Splitting exclusions accordingly gives 71 on sole-coverage rules and 1,268 on rules with redundant coverage. Histories with no tags could not be assigned to either group and were dropped from the comparison rather than given a default, which leaves 1,339.

Of the first group, 63 were still in place at the snapshot; of the second, 1,093. That is 88.7% and 86.2%. A log-rank test taken over the full curves rather than at any single time point gives p = 0.49. The two curves are indistinguishable. Three runs on successively larger samples gave 0.96, 0.31 and 0.49, all pointing the same way. The authors report this as a finding rather than as a failure to find one, because it means that whatever process decides which exclusions come out is currently blind to how much detection stands behind the rule. A queue built in the order alerts happen to fire has no way of knowing which silences matter.

Seventy-one is a small number on its own. But 63 of those 71 are still standing, and there is no fallback detection behind them.

3.2This Is Not New Rules Being Tuned In

One reasonable objection is that the repository grew, so of course exclusions grew with it. The paper normalizes by the number of rules alive on each date. Net exclusions per rule run under a tenth in the early years and reach about 0.57 by 2026. The burden carried by the average rule rose by an order of magnitude.

A second objection is that this is just the early tuning every new rule needs. The median age of a rule at the moment an exclusion is added is 492 days. Twenty-four percent of suppressions land within 90 days of the rule being written and 44% within a year, so there is a real early-tuning spike, but 56% occur after the first year. Set beside the persistence result, that gives the lifecycle in the paper's own sentence: an exclusion arrives around sixteen months into a rule's life and outlives everything that follows.

What maintenance consists of has changed too. Across the 77 months carrying at least 50 revisions, split into halves, suppression rose from 3.3% to 7.9% of all revision activity. There is a plausible mechanical explanation available: value-level suppression needs an existing list to append to, so opportunities grow structurally as rules accumulate filters. That hypothesis predicts the value-level mechanism should carry the rise, and it does not. The value-level share moved from 1.5% to 2.2% and is not statistically significant, while the predicate-level share, which has no such dependency, more than tripled from 1.7% to 5.7%. As the corpus matured, the center of gravity in maintenance shifted from writing detections toward narrowing them. Months are not independent observations, so the paper notes that the significance of this trend is optimistic and that the effect size is what should be read.

That an exclusion persists and that an exclusion is dangerous are different claims. The paper bridges the gap by classifying values one at a time. It takes the 5,336 path literals written into exclusions and sorts them by what an adversary would have to do to occupy them. Bare filenames or suffixes account for 58.2%. Protected system paths, which require privilege escalation first, account for 33.0%. User-writable locations account for 5.9%. Adding the first and third gives 64.1% that an unprivileged process can satisfy simply by choosing what to call a file.

The 1,573 exclusions written on content fields such as command lines and registry data are held out of this path taxonomy entirely, because an adversary writes their own command line and no question of privilege arises. The authors note that folding them in during an earlier pass inflated the freely-enterable share, and they record the correction rather than quietly fixing it.

Laying a second axis over the first produces something actionable: how broadly the exclusion was drawn. A protected path may name a single binary or open an entire directory tree. Crossing access cost with breadth splits the 5,336 literals as follows.

Two things come out of this table, and they cut in opposite directions. The first is that the safe harbor is smaller than it looked. Much of the 33.0% that seemed acceptable because privilege is required turns out to be drawn broadly. Of the 1,759 protected-path exclusions, 708 (40.3%) are directory trees or multi-wildcard patterns rather than named files. That is a blanket amnesty behind a lock, not a precise carve-out. Only 18.4% of the total, rather than the 33.0% that looked safe, is unambiguously costless to the defender.

The second is that this produces an order of work. An instruction to review every exclusion is not actionable. There are thousands, each was added for a reason, and nothing distinguishes them. Ordering by breadth and access cost cuts the first pass in this corpus to 657 literals, with a further 984 that can be left alone. Both properties are computable from the rule text before it is ever deployed.

4.1The Boundary the Paper Draws Around Itself

Here the authors narrow their own claim. What can be identified is exclusions that are broad, that an unprivileged process can occupy, and that have gone unreviewed for a long time. What cannot be identified is whether any of them is wrong. Whether the excluded thing is genuinely benign depends on the environment the rule runs in, and this study observed no environment at all. In an organization where that software really does run everywhere, a broad exclusion may be the right call and a narrow one a mistake. This is a way to decide what to look at first, not a verdict on what you find.

The paper also shows no evidence that any of these windows has been used, since it observes no adversary and no deployment. Feasibility, though, was established elsewhere: Uetz et al. constructed evasions for widely deployed SIEM rules and defeated nearly half of them in a live enterprise network. That work established that the gaps are exploitable. This one counts how such a window, opened for a good reason, stays open.

Three remedies are proposed, and none of them requires new research. First, give an exclusion an expiry or review date, so that standing indefinitely becomes a decision rather than a default. Second, compute at the moment an exclusion is proposed whether the rule it narrows is the only coverage for its technique, and surface that in the pull request. Third, check breadth and access cost when the exclusion is written, so that a broad, freely enterable one has to be argued for before it can be merged. The third is the smallest, and on its own it reaches the 12.3% quadrant. SigmaHQ has already moved a step in this direction: Sigma specification v2.0, released in August 2024, introduced standalone filter rules that hold exclusions as separate objects applied across many detection rules at once. The paper reads that as independent evidence that exclusion management is recognized as a problem in practice. The same fact is also a limitation, since exclusions expressed that way may not appear in the rule histories analyzed here, though the mechanism existed for only the final twenty months of the observation window, which bounds the gap.

The recommendations are split across three audiences, and the middle one is the group nobody has been addressing. At one end are rule maintainers, who make the decisions and leave the record. At the other are researchers and tool builders who measure rule evolution. In between sit the organizations that consume the ruleset. They inherit every exclusion in the repository, rarely read the diff, and are in the best position to act precisely because these were not their decisions. An exclusion inherited today is, in expectation, permanent, so treat merge as the last review it will receive. That is the paper's one line for them.

This has actually happened. In one revision examined during validation, a maintainer replaced five exclusions written on bare filenames with three absolute paths and dropped two entirely. Nobody asked for it; it was done by someone who understood the difference between the two forms. The practice exists. What is missing is anything that asks for it.

Everything so far is a story about a security repository. Read it from the data side, though, and the structure is familiar. When a cleaning rule starts throwing out valid records, it gets an exception clause. When a validation rule keeps failing, one more value goes on the allowlist. Labeling guides accumulate sentences that begin with treat this case as an exception. None of those is a bad decision. Each was right at the time.

Whether the four things the paper measured in a security repository hold in the same shape for data pipelines is something nobody has counted yet. The mapping below is not in the paper. It is this article's reading. The joints line up more closely than they have any right to, though.

The last row is the one you can try this week. Carry the paper's two axes over to data rules and the questions become these. How broadly does this exception clause filter? And how easily is its condition met? What made a filename-based exclusion dangerous on the security side is that satisfying it costs nothing. Data pipelines have exceptions of exactly that kind, in the clauses that let a particular source name or a single field value skip validation.

If you run a pipeline today, three questions are worth asking.

• Is there one place that lists every exception clause in your cleaning rules, validation rules and labeling guides?
• Does each clause record when and why it went in, and when it was last reviewed?
• Can you recount what share of your current data each clause covers?

The third question is what this paper adds. Even with a good list and a good history, if nobody recounts what the clause covers now, the list stays a record of past decisions. As the paper shows, the region a clause covers produces no signal of its own. Without a procedure for recounting, it cannot be told apart from a region where nothing is happening.

The paper's conclusion is short. What is missing is not diligence but signal. Everyone who added an exclusion in that repository made a considered response to a real problem. Nothing told them which of the exclusions they wrote were broad, cheap for an adversary to satisfy, and standing on the only rule that watched a given behavior. Two of those three are computable before deployment.

Primary Source

• 1.Dhananjeyan, S., U, K. (2026). "The Exclusion Ratchet: False-Positive Suppression Accumulates and Persists in Detection Rule Repositories." arXiv:2608.31062. The paper this article is based on.

Academic Papers

• 2.Long, M., Evans, D. (2026). "Evolution of Log-Based Detection Rules in Public Repositories." arXiv:2605.05383. Prior work that measured restoration time for reverted revisions only — the study this paper reproduces and extends.
• 3.Uetz, R., Herzog, M., Hackländer, L., Schwarz, S., Henze, M. (2024). "You Cannot Escape Me: Detecting Evasions of SIEM Rules in Enterprise Networks." Proceedings of the 33rd USENIX Security Symposium, pp. 5179–5196. Demonstrated bypasses for nearly half of widely used SIEM rules in real enterprise networks.

Official Documentation

• 4.SigmaHQ. (2024). "Sigma Specification v2.0." Specification that split exclusions into standalone filter objects outside the rule.