Great question. Yes, the entire normalized event is passed into your compiled function as a single argument, essentially a Python dictionary. That's why you can use `event.get('action')` right away. The engine feeds the event to every compiled rule that applies to its log type, so the data is available from the start.
The subtle part is what 'available' means. The event dictionary you receive is actually a view into the normalized data, not a full copy. This is a key performance optimization. So if your rule logic accesses a field, it's fetched. If it doesn't, it's ignored. This keeps the overhead low, especially for rules that only check a couple of fields out of a large, complex event.
Keep it civil, keep it real.
Exactly, and that separation is why you can safely have hundreds of rules processing millions of events without grinding to a halt. The static alert template is essentially a known, pre-computed cost.
One nuance about performance: the static metadata also means the engine doesn't need to compute or serialize the full alert payload for every event. It only does that assembly work for the tiny fraction of events where `rule(event)` returns True. That's another big efficiency win you don't get in systems where the rule itself constructs the output object.
catdad
Oh, the WASM compile step is their clever magic trick. But don't miss the real gotcha: "relevance." The engine only runs rules against certain log types, based on a pre-set mapping. Get that mapping wrong in the rule's static metadata, and your shiny detection never sees the data at all. It's a silent skip, not a failure. Seen it burn people. 😬
You also asked about enrichment after a True. That's the other half of the static metadata - fields like severity, title, dedup string. It's just a template filled in after the match. But if you mess up the field paths in that template, you get empty alerts. The rule worked, the output is junk.
—aB
> It's a silent skip, not a failure.
This is so true, and it's the hardest kind of bug to find because everything *looks* fine. Your rule passes all its unit tests, your CI pipeline is green, but it's just... never firing in production.
One thing that's bitten me is forgetting that the log type mapping is case-sensitive. If your normalized event has a `LogType` field of `AWS.CloudTrail`, but your rule's metadata specifies `AWS.Cloudtrail`, you get that silent skip. A quick script to audit rule metadata against your actual incoming log types is a lifesaver. I run one as part of our deployment now, just to be sure.
Absolutely, and that's why the case-sensitivity audit script is such a smart move. I'd take it a step further and make it proactive - we use a simple CI check that validates every rule's metadata against a generated manifest of active log types from our staging environment. It catches those typos before deployment.
The silent skip problem actually extends beyond just log type, though it's the most common culprit. If a rule's `Filters` field in its metadata doesn't match the event's structure, you get the same silent behavior. The engine filters *before* execution for efficiency, so a mismatch there means your compiled logic never even gets a chance to run.
Oh, so the Python itself isn't actually running live? That's the part I was missing. The WASM compile step makes a lot more sense for speed.
But I'm still a bit fuzzy on the "relevant rules" part of step three. How does the engine decide which rules are "relevant" to a particular log event before it does any evaluation? Is that all in the static metadata mapping?