The suricata-check project

suricata-check is a command line utility to provide feedback on Suricata rules. The tool can detect various issues including those covering syntax validity, interpretability, rule specificity, rule coverage, and efficiency.

Looking for new contributions and feedback

Since suricata-check is still in beta, we are actively looking for feedback on the existing functionality, and the way this functionality is exposed to users through the CLI/API. If you have suggestions that would improve your user experience, please do not hesitate to open an issue! For general discussion around the tool or writing Suricata rules, you are also welcome to open a new discussion

Please check out our contributing guidelines if you would like to help with more than just feedback/ideas. Interested contributors are also invited to join the project as a co-maintainer to further shape the project's direction.

Features

• Static analysis without Suricata installation for any operating system
• Simple CLI with options to work with any ruleset
• Documented, Typed, and Tested API
• CI/CD integration with GitHub and GitLab
• Visual Studio Code Extension
• Easily extendable with custom checkers

Installation from PyPI

To install suricata-check from PyPI, simply run the following command:

pip install suricata-check[performance]

Installation should work out-of-the-box on any Operating System (OS) and is tested for each release using CI/CD on Windows, Linux (Ubuntu), and MacOS.

Usage

After installing suricata-check, you can immediately start to lint Suricata rules from the command line:

suricata-check

This command will look for a file ending with .rules in the currrent working directory, and write output to the current working directory.

More details regarding the command line interface can be viewed using the --help option and are also shown below:

Usage: suricata-check [OPTIONS]

  The `suricata-check` command processes all rules inside a rules file and
  outputs a list of detected issues.

  Check the CLI usage documentation for a full overview of how to use the CLI:
  https://suricata-check.teuwen.net/cli_usage.html

Options:
  -h, --help              Show this message and exit.
  --ini TEXT              Path to suricata-check.ini file to read
                          configuration from.
  -r, --rules TEXT        Path to Suricata rules to provide check on.
                          [default: .]
  -s, --single-rule TEXT  A single Suricata rule to be checked
  -o, --out TEXT          Path to suricata-check output folder.  [default: .]
  --log-level TEXT        Verbosity level for logging. Can be one of ('DEBUG',
                          'INFO', 'WARNING', 'ERROR')  [default: INFO]
  --gitlab                Flag to create CodeClimate output report for GitLab
                          CI/CD.
  --github                Flag to write workflow commands to stdout for GitHub
                          CI/CD.
  --evaluate-disabled     Flag to evaluate disabled rules.
  --issue-severity TEXT   Verbosity level for detected issues. Can be one of
                          ('DEBUG', 'INFO', 'WARNING', 'ERROR')  [default:
                          INFO]
  -a, --include-all       Flag to indicate all checker codes should be
                          enabled.
  -i, --include TEXT      List of all checker codes to enable. Regexes can be
                          provided.
  -e, --exclude TEXT      List of all checker codes to disable. Regexes can be
                          provided.

Usage of suricata-check as a module is currently not documented in detail, but the type hints and docstrings in the code should provide a decent start.

Output

The output of suricata-check is collected in a folder and spread across several files. Additionally, the most important output is visible in the terminal.

suricata-check.log contains log messages describing the executing flow of suricata-check and can be useful during development, as well as to detect potential issues with parsing rules or rule files.

suricata-check-fast.log contains a condensed overview of all issues found by suricata-check in individual rules and is useful during rule engineering as feedback points to further improve rules under development.

suricata-check-stats.log contains a very condensed overview of all issues found by suricata-check across all rules and is useful when reviewing the quality of an entire ruleset.

suricata-check.jsonl is a jsonlines log file containing all the issues presented in suricata-check-fast.log together with parsed versions of all rules and is useful for programatically further processing output of suricata-check. An example use-case could be to selectively disable rules affected by certain issues to prevent low-quality rules inducing additional workload in Security Operations Centers.

Issue codes

suricata-check employs various checkers, each emitting one or more issue codes. The issue codes are grouped into several ranges, depending on the category of the checker. Each issue group is explained in detail below. For details regarding specific issues, we recommend you check the message of the issue as well as the test example rules under tests/checkers.

Overview

Mandatory issues

Rules starting with prefix M indicate issues pertaining to the validity of Suricata rules. Rules with M-type issues will most probably not be used by Suricata due to invalid syntax or missing fields.

Not all invalid rules wlll be reported through M-type issues as some rules can simply not be parsed to the point where these issues are detected. Instead, you can detect these rules through the ERROR messages in suricata-check.log.

Suricata Style Guide issues

Rules starting with prefix S indicate issues pertaining to the adherence to the Suricata Style Guide. Rules with S-type issues are likely to hint on interpretability or efficiency issues.

Principle issues

An additional checker is available to check for design issues, which can be installed by running the following command:

pip install suricata-check-design-principles

Rules starting with prefix P indicate issues relating to rule design principles posed in the Ruling the Unruly paper. Rules with P-type issues can relate to a specificity and coverage.

Community issues

Rules starting with prefix C indicate issues posed by the community and are an extension on top of the other issue groups. Rules with C-type issues can relate to a wide variety of issues. You can propose your own community type issues that should be checked for in the issues section.

Contributing

We are actively looking for new contributors to join our project!

If you would like to contribute, please check out CONTRIBUTING.md some helpful suggestions and instructions.

License

This project is licensed under the European Union Public Licence (EUPL).

Note that extensions may be licensed under another license as detailed in CONTRIBUTING.md. For example, the suricata-check-extension-example project is licensed under the Apache 2.0 license.

Citations

If you use the source code, the tool, or otherwise draw from this work, please cite the following paper:

Koen T. W. Teuwen, Tom Mulders, Emmanuele Zambon, and Luca Allodi. 2025. Ruling the Unruly: Designing Effective, Low-Noise Network Intrusion Detection Rules for Security Operations Centers. In ACM Asia Conference on Computer and Communications Security (ASIA CCS ’25), August 25–29, 2025, Hanoi, Vietnam. ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/3708821.3710823

A publicly accessible preprint is available.