Scirius turns Suricata rule sources into one ruleset you can tune

A ruleset composer, not a Suricata management console

Scirius Community Edition is described as a web interface dedicated to Suricata ruleset management, and the scope is stated precisely: it handles the rules file and the update associated files. The word to notice is ruleset, because Scirius is not a dashboard for a running sensor. It is the place where the content of that ruleset is assembled. The mechanism has three stages. First, a ruleset is composed from different sources, where the feeds can be picked from public sources published by OISF, the Open Information Security Foundation, or can be custom. Second, Scirius takes care of refreshing the sources and composing the ruleset by applying your transformations to it. Third, the application presents statistics on rules activity, which the documentation frames as a way to give information and facilitate the tuning. For a team running Suricata on more than one sensor, that is a meaningful gap being filled, because the rules file, its sources and its tuning notes are otherwise three separate artefacts that drift apart.

Transformations are where the noise gets removed

The transformation model is the part that makes Scirius more than a downloader, and the documentation is specific about it. Transformations like disabling a rule or applying a threshold, to lower the noise only, can be made for each rule or at the category level. That distinction between per-rule and per-category scope is what makes the tool practical at scale. A single bad signature that fires constantly is a per-rule problem, and a whole category of rules that is not relevant to your network is a per-category one, and applying the same transformation to hundreds of rules one at a time is exactly the manual work that stops happening. Thresholding in particular is the transformation detection teams care about, because a rule that is technically correct but noisy in a given environment is better expressed as a threshold than as a disable. The statistics view closes the loop. You can see which rules are producing activity, decide that one of them should be thresholded or disabled, apply the transformation, and then watch the numbers change.

The stack is Django 4 with a webpack and jQuery front end

The repository layout describes a full web application rather than a script. The Python side is a Django project with manage.py, a setup.py that lists the packages scirius, rules, suricata, accounts and viz, and a requirements.txt that pulls in Django at 4.2 or later with an upper bound of 5, djangorestframework, django-celery-results, celery and kombu for asynchronous work, psycopg2-binary, elasticsearch pinned below 7, influxdb, gunicorn, gevent, djangosaml2 and django-auth-ldap for single sign-on, django-csp for content security policy, django-revproxy, idstools and suricata-language-server for the Suricata side, and python-gnupg for signature verification. The front end is a separate build. The package.json describes a webpack 5 pipeline with eslint, babel, sass and postcss, and a dependency list that is recognisably a late 2010s admin interface: bootstrap 4, patternfly, jquery with jquery-ui and jquery-knob, d3 with nvd3 and c3 for charts, and webcola for graph layout, which is what draws the source and ruleset relationship views. The two npm scripts are minimal, with start running a remove-build step and then webpack, and remove-build clearing the built assets under the rules static directory. The result is an application that a security team can deploy but that carries a front-end toolchain of a particular generation.

Running it locally takes one compose command

The development environment is the fastest way to see what the application does, and it is a single command.

docker compose up -d

That spins up a Scirius container based on the local code with hot reload, and it also creates the dependency containers, which the documentation names as fluentd, postgres and elasticsearch. The compose file backs this up with a set of named volumes, and the list tells you what the system is made of: elastic-data for Elasticsearch persistence, suricata-rules for the rules transfer between Scirius and Suricata and for persistence, scirius-data and scirius-static for the application data and the static files served by nginx, suricata-run as the path where the Suricata socket resides, suricata-logs and suricata-logrotate for log handling, arkime-logs and arkime-pcap for packet capture, logstash-sincedb where Logstash keeps its state so it does not re-ingest, db-data, and fluentd-pos. The config blocks point at a Docker subdirectory for OpenSearch configuration, OpenSearch Dashboards configuration and the fluentd configuration and template. Note that the compose file is newer than the README's description, which still refers to elasticsearch.

The development stack is not a production stack

The documentation is direct about this, and the sentence is worth quoting in substance. The compose environment is for development only, and some of the services are going to be open to the local network, or more depending on your setup, without authentication. For production installation the project points at ClearNDR with stamusctl, a separate tool for deploying the Stamus stack. So the honest reading is that Scirius Community Edition is the application layer, and the supported way to run it in anger is inside a larger product that handles authentication, secrets and the Suricata deployment itself. The application does have the pieces for a serious deployment, since the requirements list django-auth-ldap and djangosaml2 for enterprise identity, django-csp for content security policy, and python-gnupg for signature checking. What is missing from the repository is the operational layer: the authentication front door, the TLS termination, the backup schedule. Anyone running this directly should assume they own that work.

The version story is confusing on purpose or by accident

Here is a discrepancy worth flagging before anyone pins a version. The release history shows scirius-3.0.1, titled The Flying Squirrel, from 2018-11-30, preceded by 2.0.1 in April 2018 and 2.0.0 in March 2018. But the setup.py in the repository declares version 3.8.0, and the requirements pin modern libraries, including Django 4.2, cryptography at 43.0.3 or newer, and suricata-language-server at 0.9.4 or newer. The last push to the repository was on 2026-05-22. So the code is being worked on in 2026 with current dependencies, while the published release names stop in 2018 and the repository has no GitHub releases to speak of. The setup.py classifiers also still list Python 2.7, which is plainly out of date next to a Django 4.2 requirement, so the metadata is not a reliable guide. There is a SECURITY.md and a GitLab CI configuration alongside a Travis file, and the documentation lives on readthedocs, so the project is not abandoned, but the version you get from a package index may not be the version in the tree. The licence is GPLv3, which suits a network security appliance that a team also modifies, and the packaging files in the repository make that plain.

Getting help, and what the alternatives look like

Support channels are documented and mostly belong to the Stamus community. There is the Scirius documentation on readthedocs, the IRC channel #SELKS on irc.freenode.net, the SELKS forum on Google Groups, and the GitHub issue page. Contributions go through pull requests on GitHub, and the project says explicitly that there is more than one way to contribute, from improving the documentation to coding new features. That is a good sign for a project whose community is its maintenance strategy. The alternative worth naming is not a competitor but a different operating model. Suricata ships with its own rule update mechanism, and a team that wants a single managed ruleset can simply script the download and merge of feeds, apply a curated disable list with a version-controlled file, and reload Suricata. That approach has no web interface, no per-category transformations and no activity statistics, which is the point of Scirius. What Scirius adds is a place where the transformation rules and the feedback on rule activity live together, and that is worth having once you have more than one sensor and more than a handful of suppressions. For a single sensor with a handful of rules, the script is the better answer, because it has fewer moving parts and nothing to authenticate.

Editorial conclusion

Adopt Scirius if you run Suricata across several sensors and need one place to merge feeds, disable noisy rules and watch which signatures are actually firing, because that is exactly the workflow the application was built for. Skip it if you want a supported product with a release trail, since the newest published release is from 2018 while the code has continued to move, and skip it if your Suricata deployment is a single appliance with a static ruleset. Before you plan a deployment, read the compose file's volume list and the warning in the documentation about unauthenticated services, and decide whether you want the community edition or the ClearNDR path the project points to for production installs.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. StamusNetworks/scirius on GitHub