Skip to main content
Squasher checks your connector logs, web server spans, and AI agent spans against detection rules when the data arrives. Each match is a security finding. Detection findings never page. You manage the rules as code. Each project has the built-in pack and up to 20 packs of its own. You can check a rule before you save it, and you can run a rule over past logs to see what it would have found.

​
Rule packs

A change to a custom pack applies within about 60 seconds. A turned-off pack keeps its rules and does not run. All turned-on custom packs of a project together hold at most 20 packs, 200 rule files, and 4 MiB of rule YAML. A create, change, or turn-on that goes past one of these limits fails with 409. Turn off a pack or remove rule files first.

​
Rule formats

A Sigma field name reads the mapped attribute of the log first, then the raw vendor record of the connector log, so a rule written for the vendor’s field names works without changes. Each rule needs an id that is unique in its pack and a title.
okta_admin_token.yml

​
Validate a rule

Validation compiles each file with the same engine that runs at ingest and returns one error per file that does not compile. It stores nothing.
Create and update also validate every file, and refuse the change with the errors when a file does not compile. Add --dry-run to see the validation without a change.

​
Backtest a rule

A backtest runs a pack, or rule files that you have not saved, over the connector logs of a past window. The window is at most 7 days and a backtest reads at most 10,000 log events. A backtest stores nothing and makes no findings.
The job reports its status (queued, running, succeeded, failed, or cancelled) and progress. A finished job lists the events read, the matches of each rule with up to 5 sample timestamps, and truncated when the window held more events than a backtest reads. Stop a job with squasher detections backtest-cancel. A backtest reads logs with the same limits as other security queries: the project’s own logs only, the security attributes only, and the project’s query budget. The budget covers the whole job, not each read. A project runs at most 2 backtests at a time, and one backtest runs for at most 240 seconds. A job that passes the budget or the time limit fails with budget_exceeded or time_limit_exceeded and keeps the partial result.