SO-CRATES puts Suricata, YARA, Sigma and email analysis behind one local web UI

A file triage workbench rather than a monitoring platform

SO-CRATES stands for Security Onion Containerized Rapid Analysis of Threats, Evil, and Sus. The name is a clue to the design: it borrows the Security Onion brand and its detection engines, and repackages them as a tool you point at a file.

The documentation describes it as a standalone web application for analyzing pcap files, log files, email messages and binary files. The feature list names Suricata network analysis, YARA binary scanning, Sigma rule detection for logs, email header, link and attachment analysis, and a single-page UI for browsing alerts, metadata, transcripts and hexdumps.

That word standalone carries the design. The usual Security Onion deployment is a sensor stack that collects and correlates continuously. SO-CRATES is the opposite: you give it an artifact, it runs the analysis, you read the result in the browser. It is the tool for the moment after you have pulled a file off a case, not the thing that watches the network.

For an analyst, that distinction is the whole value. The same detection engines that normally live inside a pipeline are reachable through a web interface with no deployment to speak of, which is why the project also ships an interactive demo and a quick demo page.

The compose file binds to localhost on purpose

The quickest way to see the shape of the deployment is the compose file, which is short.

services:
  so-crates:
    image: ghcr.io/dougburks/so-crates:main
    container_name: so-crates
    ports:
      # Localhost-only by default. To allow other machines on your
      # network to connect, change to "8000:8000".
      - "127.0.0.1:8000:8000"
    volumes:
      - type: bind
        source: ./socrates-data
        target: /data
    restart: unless-stopped

Three decisions are visible here. The image is published on GitHub Container Registry with the main tag, so there is no build step to get the first version running. The port mapping is bound to 127.0.0.1, and the comment in the file says why: to let other machines on your network connect you change it to 8000:8000. That is an explicit opt-in rather than a default, which is the right default for something that handles attacker-controlled files.

The data directory is a bind mount from ./socrates-data to /data, so your analysis output lives in a directory you control and can inspect, back up or delete. The service is set to restart unless stopped, which is convenient for a laptop you keep closed between cases.

Separate compose files exist for Podman, and the installation documentation is split into three paths: OhMyDebn, Docker and Podman. So the container runtime is not assumed.

One Python module per analysis concern

The repository root shows how the application is factored, and the file names describe the feature set directly. There is a suricata_analyzer.py alongside suricata_sid_ranges.py, which suggests the Suricata signature identifier ranges are handled separately from the analysis itself. There is a yara_analyzer.py for binary scanning and a sigma_analyzer.py for log rules.

Email handling has its own module, email_analyzer.py, and there are two more for file work: file_analyzer.py and exif_analyzer.py. A cyberchef.py sits alongside socrates.py and socrates.html, and the name Socrates appears again as the data directory in the compose file, so it is the application's own name for its analysis core.

The rest of the root is infrastructure: db.py, models.py, storage.py, analysis_cache.py, config.py and validators.py, plus samples.py for bundled sample data, url_fetch.py, stream_payload.py, and lookup modules for AI summaries and Playbooks. static/ holds the front end, overrides/ holds configuration overrides, hooks/ holds extension points, and docs/ contains the site sources with mkdocs.yml driving it.

It is a flat, readable layout. Each analyzer is its own file, which is what you want if you plan to add a detection source.

The image vendors its tools, and says why

The Dockerfile is where the interesting engineering decision sits, and the comments explain it.

The build runs in stages on a debian:13-slim base, and the first stage exists only to compile Zircolite. The reasoning is written out: evtx and orjson have Rust extensions and lxml has a C extension, so a Rust toolchain, build-essential, dev headers and git are needed to build them, and the goal is that none of that has to exist in the final runtime image. Even pip is uninstalled from the Zircolite virtual environment once the requirements are installed, with the note that nothing imports pip at runtime and that the image never installs packages after build time.

The Zircolite checkout is pinned to a specific tag, v3.7.1, cloned with depth 1, and then aggressively pruned. The rules, gui, pics, tests, docs, templates and tools directories are removed, along with the README, the licence and other project files, so what is left in the image is the code that runs and nothing else.

The practical consequence for an adopter is supply chain visibility. The detections your analysis relies on are pinned in the image at build time, not fetched at runtime, and the release notes and changelog for the pinned tag are what you audit. The tradeoff is that updating a rule set means pulling a new image, not running an update command.

Running the tests is a single unittest discovery

Development guidance lives in AGENTS.md, which the documentation points to for agent focused maintenance instructions including how to update vendored dependencies. That file exists because the project is set up to be worked on with coding assistants, and the same file is where a contributor learns the rules about refreshing the bundled tools.

The test suite is standard library unittest discovery, with no pytest configuration needed for the main run.

# All tests
python3 -m unittest discover -v

There is a tests/ directory at the root and a scripts/ directory alongside it, and requirements-docs.txt and requirements-screenshots.txt for the documentation tooling and the screenshot automation respectively. The separate requirements files for docs and screenshots suggest the screenshot generation is scripted and repeatable rather than manual, which is what you want when a UI like this changes often.

The only npm dependency in the whole project is jsdom, declared in a package.json at the root, and it is there to run JavaScript in a Node context for tests. The application itself is Python, and the front end is served as static files, so there is no JavaScript build pipeline to maintain.

Where the documentation is thin and what you have to decide

The README is mostly a table of contents, and that is a deliberate choice for a project with a full documentation site at so-crates.org. The site has separate pages for installation by runtime, usage, themes, configuration, security, architecture, the API reference, filtering, credits and release notes.

Some things a new operator will look for are not in the repository itself. The README does not state which Suricata, YARA or Sigma rule versions ship in the image, beyond the pinned Zircolite tag visible in the Dockerfile. It does not describe authentication for the web interface, only that there is a security page. It does not say whether the analysis cache, which exists as analysis_cache.py, is shared or per user, or how long it retains data.

Those are all answerable, but the answers live in the site rather than in the tree, and the site is the versioned documentation for the project while the repository is the code. If you are evaluating this for a team, the security page is the one to read first, and the configuration page is the one you will keep open, because the compose file ships one binding and one data directory and everything else is presumably driven from configuration.

The themes page is a smaller surprise: a UI that runs Suricata, YARA and Sigma side by side also lets you restyle the whole thing, which suggests the analysis views are template driven rather than hardcoded pages.

Editorial conclusion

SO-CRATES fits a threat analyst or incident responder who wants to open one pcap, one suspicious email or one binary and get Suricata, YARA and Sigma verdicts in a browser, without standing up the full Security Onion stack. It does not fit a team running continuous network monitoring, since the project describes itself as a standalone application for analysing files rather than a sensor, and it does not fit a deployment that needs the analysis reachable from other machines without changing the compose file yourself. Before adopting it, read the security and configuration pages at so-crates.org, confirm the port binding stays on localhost as the compose file ships it, and check that the vendored rule and tool versions in the image match the detections your workflow depends on.

Frequently asked questions

Official sources

1. dougburks/so-crates on GitHub
2. Issues
3. License: MIT
4. README
5. Releases