Skip to content
Calcrivo

Sigma Rule Coverage Calculator

Track a Sigma rule set from applicable to converted to deployed, and find where field mapping loses your detections.

Inputs

rules
rules
rules
rules
rules
%

Unmapped fields are the usual reason a converted rule never fires.

Effective Sigma Coverage

41.6%

Repository Applicable to You

40.0%

Applicable Rules That Convert

75.0%

Converted Rules Deployed

71.1%

Deployed Rules Validated

59.4%

Rules Lost Between Applicable and Deployed

560rules

Weakest Link in the Pipeline

Validation is the weakest link — deployed rules have never been proven to fire

Step by step

  1. Values used

    Sigma rules in the source repository = 3,000 rules; Rules applicable to your platforms and log sources = 1,200 rules; Rules that convert cleanly to your backend = 900 rules; Rules deployed and enabled = 640 rules; Deployed rules validated by emulation = 380 rules; Taxonomy fields mapped to your schema = 78 %

  2. Sigma Rule Coverage

    Effective coverage = deployed rules ÷ applicable rules × field-mapping completeness.

  3. Pipeline loss

    Rules lost = applicable − deployed, split across conversion failures and deployment backlog.

  4. Effective Sigma Coverage

    = 41.6

  5. Repository Applicable to You

    = 40.0

  6. Applicable Rules That Convert

    = 75.0

  7. Converted Rules Deployed

    = 71.1

  8. Deployed Rules Validated

    = 59.4

  9. Rules Lost Between Applicable and Deployed

    = 560 rules

How it works

The multiplication by field-mapping completeness is the important part: a rule that converts and deploys but references an unmapped field is syntactically valid and functionally dead. That failure mode is silent, which is why deployed rule counts overstate coverage so consistently. Sigma makes detection portable in principle, but the value only lands if rules survive conversion, mapping and deployment — and the losses at each stage are where a 3,000-rule repository becomes 640 working detections.

Formulas

Sigma Rule Coverage

Effective coverage = deployed rules ÷ applicable rules × field-mapping completeness.

applicable
Rules matching platforms and log sources you actually have
deployed
Rules converted, loaded and enabled
field mapping
Share of Sigma taxonomy fields mapped to your schema

Pipeline loss

Rules lost = applicable − deployed, split across conversion failures and deployment backlog.

conversion failures
Rules the backend cannot express
deployment backlog
Converted rules never enabled

Frequently Asked Questions

How is Sigma Rule Coverage calculated?

Effective coverage = deployed rules ÷ applicable rules × field-mapping completeness. The multiplication by field-mapping completeness is the important part: a rule that converts and deploys but references an unmapped field is syntactically valid and functionally dead. That failure mode is silent, which is why deployed rule counts overstate coverage so consistently.

Why does Sigma Rule Coverage matter?

Sigma makes detection portable in principle, but the value only lands if rules survive conversion, mapping and deployment — and the losses at each stage are where a 3,000-rule repository becomes 640 working detections.

What values do I need to enter?

This calculator takes 6 inputs: Sigma rules in the source repository, Rules applicable to your platforms and log sources, Rules that convert cleanly to your backend, Rules deployed and enabled, Deployed rules validated by emulation, Taxonomy fields mapped to your schema. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why do so few repository rules apply to me?

Because the repository covers every platform, product and cloud provider. Filtering to your actual log sources typically leaves a third or less, and that is the correct denominator — coverage against the whole repository is a meaningless number.

What breaks during conversion?

Backend gaps around aggregation and correlation, unsupported field modifiers, regular-expression dialect differences, and case-sensitivity assumptions. Convert in CI and fail the build on conversion errors, so the gap is visible rather than discovered months later.

You might also need