Lint Rules

rsigma rule lint runs 85 built-in checks derived from the Sigma v2.1.0 specification, plus 1 reserved enum value (empty_filter_rules) that no production code currently emits. This page is the canonical catalog: every rule’s ID, default severity, what it flags, and whether --fix can auto-correct it.

For the workflow and CLI surface see Linting Rules and the rule lint CLI reference. For the source of truth see crates/rsigma-parser/src/lint.

Severities

Override the threshold with --fail-level warning or --fail-level info. See Linting Rules: severity gate.

Counts at a glance

The hint severity is defined but not used by any of the shipped rules.

The 14 safe-fix rules

Infrastructure rules (4)

Fired by the linter’s loader and runner before per-rule checks even start. Cannot be suppressed with inline comments because the rule never gets parsed.

Shared metadata rules (17)

Apply to detection, correlation, and filter rules alike.

Detection rules (18)

Apply to detection rules (detection: block + condition:).

Correlation rules (17)

Apply to correlation rules (correlation: block).

Filter rules (8 IDs, 7 emitted)

Apply to filter rules (kind: filter with a filter: block). The eighth row (empty_filter_rules) is reserved: the variant exists in the lint-rule enum and is asserted in a regression test, but no production code path emits it today.

Modifier and related: hygiene (7)

These also apply to detection rules but sit apart from the core detection-block checks above: modifier-misuse checks on a single detection item (single_value_all_modifier, all_with_re, incompatible_modifiers) and validation of the related: cross-reference block.

Specification version and rule references (4)

The first two apply to any document type, based on the top-level sigma-version attribute (the Sigma specification major the document targets); see Array Matching: requires sigma-version: 3. The last two resolve cross-document references (a correlation rule and the rules it aggregates, a filter and the rules it targets) by id or name. Reference resolution spans the whole directory when linting a directory; for a single file or string, only references to rules in the same input are resolved, and unknown_rule_reference is suppressed (the target may live in a file outside the linted scope).

ADS detection-strategy metadata (11)

Optional Alerting and Detection Strategy checks. They are opt-in: nothing fires until an ads: block is present in the layered .rsigma-lint.yml. When enabled, they fire only on detection rules whose status is in the configured enforce_status set (default [stable]) and skip any rule carrying rsigma.ads.exempt: true. Four ADS sections reuse standard fields (description, attack.* tags, falsepositives, level); the rest live under a rsigma.ads.* custom-attribute namespace. See Detection Strategy and Custom Attributes.

Configure the bar with an ads: block in .rsigma-lint.yml:

ads:
  enforce_status: [stable]   # statuses that require ADS sections
  required:                  # mandatory sections (defaults to all nine)
    - goal
    - categorization
    - strategy
    - technical_context
    - blind_spots
    - false_positives
    - validation
    - priority
    - response
  severity: warning          # one severity for every ADS finding (optional)

Selected findings, with worked examples

Most lint rules are self-evident from their description. The ones below tend to surprise rule authors when they hit them for the first time. Each section shows the Sigma fragment that triggers the rule and the cleanup the linter (or you with --fix) would apply.

wildcard_only_value

Trigger:

detection:
    selection:
        Image: '*'
    condition: selection

A lone * value matches any value of Image, including null. That’s almost never what the author meant; what they actually wanted is “the field is present” or “match any non-null value”, which Sigma expresses as |exists: true.

Fixed by --fix:

detection:
    selection:
        Image|exists: true
    condition: selection

single_value_all_modifier

Trigger:

detection:
    selection:
        CommandLine|contains|all: 'whoami'
    condition: selection

The |all modifier is meaningful only with multiple values (it ANDs the per-value matches). On a single-value item it is a no-op and confuses readers. The fix removes |all.

detection:
    selection:
        CommandLine|contains: 'whoami'
    condition: selection

all_with_re

Trigger:

detection:
    selection:
        CommandLine|re|all:
            - '^cmd'
            - 'whoami'
    condition: selection

|all says every value in the list must match the field. |re says match a single regex. Combining the two on a single field can’t be both at once: a regex is by definition the only matcher, so |all adds nothing. The fix removes |all and the rule keeps its OR semantics across the patterns; if you actually needed AND, use two separate selections joined with and in condition:.

non_lowercase_key

Trigger:

Title: Suspicious whoami invocation
detection:
    selection:
        CommandLine|contains: whoami
    condition: selection

Sigma’s top-level keys (title:, id:, logsource:, detection:, level: …) are case-sensitive. Title: is not recognized by the parser; the rule silently has no title. The fix lowercases the offending key.

condition_references_unknown

Trigger:

detection:
    selection:
        CommandLine|contains: whoami
    condition: selection_keywords

The condition: expression references selection_keywords, but the only selection defined in the detection: block is selection. The rule will fail to compile; this lint catches it before runtime. No auto-fix because the linter cannot tell which selection name was intended.

deprecated_aggregation_syntax

Trigger:

detection:
    selection:
        EventID: 4625
    condition: selection | count() by User > 5

The pipe-aggregation form in condition: is the pre-v2 way to express a correlation. Sigma v2.1.0 makes correlations first-class via a dedicated correlation: block, which RSigma evaluates and converts more accurately:

title: Failed logon (base)
id: 9d2e7c48-4a3b-4f99-93c9-1c5f7c8b1a2b
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    condition: selection
---
title: Brute force logon
id: aaaa1111-2222-3333-4444-555555555555
correlation:
    type: event_count
    rules: [9d2e7c48-4a3b-4f99-93c9-1c5f7c8b1a2b]
    group-by: [User]
    timespan: 5m
    condition:
        gte: 5

No auto-fix because the migration is structural (split into a base detection plus a correlation document).

duplicate_fields

Trigger:

fields:
    - CommandLine
    - User
    - CommandLine

The top-level fields: list names fields to surface in matches. A duplicate entry is redundant and the fix removes it. This rule does not detect duplicate YAML keys inside a detection selection (YAML keeps only the last key); use a single key with a value list when you need multiple values on one field.

fields:
    - CommandLine
    - User

unknown_tag_namespace

Trigger:

tags:
    - attack.t1059
    - mittre.t1059       # typo: should be attack.t1059

The recognized tag namespaces are attack.*, cve.*, detection.*, tlp.*, stp.*, and informational.*. The fix is to manually replace the unknown namespace with the closest valid one (the linter doesn’t auto-correct; tag namespaces are ambiguous enough that silent rewrites would be unsafe).

To allow organization-specific namespaces, pass --tag-namespace <name> on the CLI (repeatable) or add a tag_namespaces list to .rsigma-lint.yml:

tag_namespaces:
  - myorg
  - internal

null_in_value_list

Trigger:

detection:
    selection:
        ParentImage:
            - C:\Windows\System32\cmd.exe
            - null
    condition: selection

A null literal inside a values list is spec-ambiguous. Does it mean “the field is null” or “an absent value” or “the literal string null”? The lint flags it so the author can be explicit. To express “field is null”, use |exists: false. To match the literal string, quote it ('null').

invalid_status and invalid_level

Trigger:

status: experimnetal      # typo
level: criticla           # typo

The valid status: values are stable, test, experimental, deprecated, unsupported. The valid level: values are informational, low, medium, high, critical. The fix replaces the bad value with the closest valid one (edit-distance ≤ 3).

How to read the source for any rule

Every lint rule’s emission lives under crates/rsigma-parser/src/lint/rules/, with a few loader/CLI exceptions noted below:

Infrastructure findings (yaml_parse_error, not_a_mapping, file_read_error) and cross-document reference checks (sigma_version_mismatch, unknown_rule_reference) are produced by the lint loader/runner in crates/rsigma-parser/src/lint/mod.rs. schema_violation is attached by the CLI when --schema fails. Each emission is a call to error(LintRule::X, ...), warning(LintRule::X, ...), info(LintRule::X, ...), or hint(LintRule::X, ...). The full enum and the programmatic catalog live in that same module and in catalogue.rs.

See also

• Linting Rules for the workflow walkthrough, suppression tiers, auto-fix patterns, and CI integration.
• rule lint CLI reference for every flag.
• Sigma specification (v2.1.0) for the underlying constraints these rules enforce.
• crates/rsigma-parser/src/lint for the implementation.