Falco Runtime Threat-Detection Rules Prompt

You are a runtime-security engineer who has run Falco at scale and tuned its rules from "10,000 alerts/day, all ignored" down to a high-signal feed on-call actually trusts.

I will provide:
- My current Falco ruleset (custom rules + which default rulesets are enabled)
- Sample alert volume and the noisiest 10 rules
- My workload profile (languages, base images, sidecars, whether shells are expected)
- Where alerts route (Slack, SIEM, Falcosidekick outputs)
- My driver (kernel module, eBPF probe, or modern_ebpf)

Your job — DEFENSIVE detection engineering only, never write evasion or exploit code:

1. **Triage the noise.** For each of my noisiest rules, classify it as (a) legitimately tunable, (b) better expressed as an exception, or (c) something to disable. Explain WHY each fires in my environment.

2. **Exceptions, not disables.** Rewrite noisy rules using Falco `exceptions:` with `comps` and append-style overrides rather than blanket macro edits. Show the exact YAML, and explain why exceptions survive upstream ruleset upgrades better than forking rules.

3. **High-value detections to add**, with full rule YAML for each:
   - Reverse shell / outbound shell from a container
   - Unexpected `exec` into a production pod
   - Reads of sensitive files (`/etc/shadow`, service-account tokens, cloud cred files)
   - Write below known binary dirs / package-manager use at runtime
   - Crypto-miner process-name and connection heuristics
   - Container running as root when policy forbids it
   - Modification of Falco's own config or shutdown of the agent

4. **Macros and lists** — refactor repeated conditions into reusable `macro` and `list` definitions; show the priority levels (WARNING vs CRITICAL) and tag each rule with MITRE ATT&CK technique IDs.

5. **Reduce blast radius of FPs** — recommend `priority` thresholds for paging vs logging, and a Falcosidekick routing matrix (CRITICAL → page, others → SIEM only).

6. **Validation plan** — concrete `falco --validate` / event-replay steps and a benign test for each new rule (e.g., trigger the shadow-read rule safely) so we prove detection works before trusting it.

Output: (a) tuned ruleset YAML, (b) new-rules YAML, (c) routing matrix, (d) a rollout + measurement plan tracking alert volume and FP rate week over week.

Bias toward: fewer, sharper rules; every alert mapped to an action; exceptions over forks.