falcosecurity/rules

Falco watches the kernel. It consumes syscall events from the host in real time — plus container and Kubernetes audit events — and evaluates every rule against each one as it arrives. There is no store to query and no lookback: a rule sees an event once, at the moment it happens.

That makes this a runtime-security ruleset rather than a log-detection one. The questions it answers are "what did this process just do" rather than "what happened last Tuesday".

Rules are YAML. Each has a condition expression over syscall fields (proc.name, fd.name, evt.type), a desc, an output template, and a priority.

The critical structural fact is that a rule's condition is mostly not in the rule. Falco has two reuse primitives:

• macro — a named, reusable condition fragment.
• list — a named set of values.

This ruleset defines 93 rules against 351 macros and 163 lists. A condition like

(open_read or open_file_failed)
and (etc_dir or user_ssh_directory or fd.name contains "id_rsa")
and directory_traversal
and not proc.pname in (shell_binaries)

contains exactly one literal test. Everything else — open_read, etc_dir, directory_traversal, shell_binaries — is defined elsewhere in the file. Reading the condition alone will mislead you about what the rule matches.

Content ships in three maturity tiers, and the file a rule lives in is the signal: falco_rules.yaml is stable, falco-incubating_rules.yaml and falco-sandbox_rules.yaml are not.

Any event satisfying the condition, immediately. priority — CRITICAL, ERROR, WARNING, NOTICE, INFO — is the severity field, and we bucket it into the site's five levels.

Because there is no aggregation or windowing, a noisy rule is noisy per event. Falco's tuning model is to append exception clauses to the condition, which is why so many rules end in a chain of and not ... tests.

The rule's condition is shown as the query and its output template as notes. Macro references are not inlined — they are extracted as relations, so the dependencies panel on a rule's page lists the macros it needs. That panel is where a Falco rule's real logic lives.

ATT&CK comes from the rule's tags, which is why coverage here is thinner than the rule count suggests: a rule without ATT&CK tags carries no mapping.

• A rule that looks narrow may be broad, and vice versa, depending on macros defined a hundred lines away. Check the dependencies panel before judging scope.
• Incubating and sandbox rules are indexed alongside stable ones and are not marked differently in the shared schema. The source_path on a rule's page is the only tier signal — check which file it came from.