Detection Engineering Grew Up. Most Security Stacks Didn't.
Behavior-based, CI/CD-integrated detection logic is eating vendor-supplied rules. Here's what's actually driving the shift — and what teams still get wrong.
Signature-based detection had a good run. It's over.
A SANS Institute survey of 264 security professionals found that 80% of organizations are actively investing in detection engineering, with 60% now running dedicated teams. Large enterprises hit 85%. That's not a niche practice anymore. That's a job family.
The failure mode here is obvious if you've ever triaged an alert queue at 2 a.m.: out-of-the-box vendor rules don't know your environment. They don't baseline your AWS EC2 fleet, they don't know that your GCP Cloud Run jobs make weird outbound calls by design, and they absolutely will not stop paging you for the same benign behavior your platform team has been running for three years. Sixty-four percent of survey respondents reported high false positive rates. Sixty-one percent said their detections lacked environmental accuracy. Neither number is surprising.
Detection engineering's pitch is straightforward. Treat detection logic like software. Version it. Test it. Run it through a CI/CD pipeline — GitHub Actions, whatever — so changes are auditable and rollbacks are possible. Integrate MITRE ATT&CK coverage maps so you know where your gaps are before an adversary finds them. Use adversary emulation tools like Atomic Red Team to validate that your rules actually fire on the techniques you claim to cover.
In practice, the gap between that pitch and what most teams ship is wide.
The inputs matter as much as the logic. You need normalized log data from endpoints, cloud control planes, network flows, and your identity provider — all of it landing in a SIEM or lake that can actually query at scale. Azure Sentinel, Chronicle, Splunk, whatever you've committed to. Without clean, centralized telemetry, even well-written detection logic fires on noise or misses entirely. Garbage in, garbage out — the postmortem will say the rule was there but the log source wasn't onboarded.
The SANS data also shows 45% of organizations now use AI in their detection programs, mostly for anomaly detection and rule generation. Vendor PR will tell you this is transformative. The more honest framing: ML helps with the tuning backlog that every understaffed team is drowning in. It does not replace the threat researcher who understands why a technique works.
Fileless malware, living-off-the-land execution, supply chain compromises — these don't leave the signatures legacy tools were built to catch. Behavior-based detections that model what attackers actually do inside an environment are the only durable answer. That requires threat intelligence integration, ongoing threat modeling, and humans who understand adversary TTPs well enough to write rules that survive an attacker who reads the same public frameworks you do.
Finance and tech companies are leading adoption, largely because they face both regulatory pressure and sophisticated, persistent adversaries. Healthcare is catching up, slowly. Any organization running a complex hybrid environment — on-prem Active Directory federated into Azure AD, workloads split across multiple cloud providers — has the detection drift problem whether they've named it yet or not. Rules break when infrastructure changes. They break silently.
One thing the post-mortem will say: the detection existed; nobody knew it had stopped firing six months ago.
If you're building this capability from scratch, start with your actual threat profile, not a generic framework checklist, and instrument your cloud control plane logs before anything else.
