My Friday SIEM post is here, this time with detection engineer angle.
Detection engineering is quietly going through its own renaissance.
You can feel it even if you don’t name it. More teams are building proper pipelines, treating detections like software, and borrowing lessons from engineering culture.
At the same time, something interesting is happening in the tooling. We’re starting to see a wave of decoupled platforms for managing the entire detection engineering lifecycle. This didn’t come out of nowhere
AI SOC is a big driver here. It lets us process far more alerts without narrowing detections. It also frees up the time we used to spend on triage, which means more teams can finally do real detection engineering instead of just surviving the queue.
That pushes the practice forward and creates demand for better tooling.
What I want as an engineer is simple. A central place to track detections, build and test them, plug into a feedback loop, run unit tests or attack emulation, see who changed what, tie SOPs and automations to each detection, and pull real metrics out of the whole thing. This is where "DSAEM" Loop that I created makes even more sense.
Most SIEMs already let you do detection as code and some do it well.
This isn’t an argument against that.
The question is whether this capability gets baked directly into the SIEM or whether it grows as a decoupled layer sitting beside it. Something like the AI SOC model already hints at that separation.
What do you think, if you have such platform would you prefer to use it as separate offering or you would stick to the SIEM native capabilities?
Btw really good episode I would say related to this on the Detection Engineering Dispatch by Alex Hurtado hosting Dennis Chow
Originally posted on LinkedIn on 5 December 2025.
Read the original post and the comments.