Detection as Code
Your detection library in git, not in a UI you can't diff
Every detection rule in ManySignal is a versioned YAML file. Write rules locally, test them against historical data in CI, review them in a pull request, and deploy them through the same pipeline as your application code.
Detection rule — YAML
Human-readable, machine-validated, CI-deployable
Rules are validated against a JSON schema before commit. CI runs the rule against a historical replay dataset and reports false-positive rate, true-positive rate on synthetic attack scenarios, and field mapping errors.
detection:
id: aws-iam-console-login-no-mfa
title: "AWS Console Login Without MFA"
version: "1.0.0"
severity: medium
mode: active # alert-only | active
author: security-team
created: 2026-03-01
mitre:
- technique: T1078
subtechnique: T1078.004
tactic: initial-access
filter:
event.source: aws.cloudtrail
event.action: ConsoleLogin
event.outcome: success
event.mfa_used: false
conditions:
- "entity.is_human == true"
- "entity.environment != 'sandbox'"
dedup:
key: [entity.user_id]
window_seconds: 3600
finding:
title: "Console login without MFA — {{entity.display_name}}"
description: "Human account {{entity.display_name}} authenticated to the AWS console without MFA from {{event.source_ip}}."
severity: "{% if entity.is_privileged %}high{% else %}medium{% endif %}"
tags: [aws, iam, mfa]
tests:
- name: tp_human_no_mfa
event:
source: aws.cloudtrail
action: ConsoleLogin
outcome: success
mfa_used: false
entity.is_human: true
entity.environment: production
expected: finding
- name: fp_sandbox_account
event:
source: aws.cloudtrail
action: ConsoleLogin
outcome: success
mfa_used: false
entity.environment: sandbox
expected: no_findingThe full detection lifecycle in one pipeline
Why detection as code matters
Every change is diffable
A rule change from threshold 5 to threshold 3 appears as a one-line diff. No screenshot of a GUI, no tribal knowledge about what changed last week.
Unit tests in the rule file
Each rule carries its own test cases: events that should produce a finding, events that should not. CI fails if a test case regresses.
Shipped rules are forkable
ManySignal's shipped rule library is expressed in the same YAML format. Fork a shipped rule, adjust it for your environment, and track the delta explicitly.
Rollback is a git revert
A rule that causes a false-positive storm is rolled back by reverting the commit. The previous version is in git history, not in a backup you have to file a ticket to access.
Coverage reporting in CI
CI reports which MITRE ATT&CK techniques your deployed rule set covers, and which are gaps — so coverage is a metric on every PR, not a quarterly spreadsheet exercise.
Multi-tenant rule promotion
For MSSPs, a rule approved in the testing tenant can be promoted to all customer tenants through a single pipeline run, with per-tenant threshold overrides declared in a config file.
Detection as Code — FAQ
Is there a CLI for local development?
Yes. The ManySignal CLI validates rule YAML, runs unit tests against local event fixtures, connects to the sandbox API to run historical replays, and pushes rules to a named environment. It installs via npm, pip, or a static binary.
Can I use my own git hosting?
Yes. The CI action is a standard GitHub Actions workflow. GitLab CI and Bitbucket Pipelines are supported with equivalent configuration files. The API used by CI is the same public API available to all deployments.
What is a historical replay dataset?
A rolling 30-day sample of your normalized events, deduplicated and stored in the CI environment. Rules run against this dataset in a read-only sandbox — no findings are created in production, and no live alerts are affected.
Do shipped detections automatically update?
No. Shipped detections are pinned to the version you import them at. Updates to shipped rules appear as pull requests in your rule repository, which you can review and merge on your own schedule.
What does a detection rule unit test look like?
Unit tests are YAML fixtures that define an input event (or sequence of events) and the expected finding output. The CLI runs them locally in under 100ms each. Tests can assert on finding type, severity, entity resolution, and alert-only vs. active status. A CI gate requires all tests to pass before deployment.
How does the promotion workflow prevent untested rules reaching production?
Rules are deployed in alert-only mode by default. Promotion to active status requires passing CI tests, a precision review (alert volume and false-positive rate from the replay run), and optionally a peer review gate on the pull request. The promotion workflow is configurable per team.
Can we manage context rules and suppression rules in the same repo as detections?
Yes. Business context rules (suppressions, escalations, entity tags) use the same YAML format and the same CLI commands. Detection and context rules coexist in the same repository and deploy together in a single CI pipeline run.
How do we migrate existing custom SIEM rules to the ManySignal detection-as-code format?
Sigma-format rules import with automatic conversion via the CLI's sigma import command. Splunk SPL and KQL rules require manual translation — the ManySignal detection engineering team offers a migration service for enterprise customers with large existing rule libraries.
What is the deployment latency from CI merge to live rule evaluation?
After a successful CI pipeline run, rule deployment propagates to all detection engine nodes within 30 seconds. Alert-only rules begin evaluating immediately; active rules begin generating findings and triage queue entries within the same window.
Detection rules you can diff, test, and roll back
Book a session to walk through the detection-as-code workflow from rule authoring to production deployment.