Detection Engineering Grew Up. Most Security Stacks Didn't.
Behavior-based, CI/CD-integrated detection logic is eating vendor-supplied rules. What's actually driving the shift, and what teams still get wrong.

Key points - 80% of organizations are actively investing in detection engineering, with 60% running dedicated teams, per a SANS Institute survey of 264 security professionals. - Out-of-the-box vendor rules generate high false positive rates and lack environmental accuracy, according to the same survey. - Detection engineering applies software development principles: version control, CI/CD pipelines, and adversary emulation to keep rules honest. - Behavior-based detections are the durable answer to fileless malware, living-off-the-land execution, and supply chain compromises. - Detection drift, where rules break silently after infrastructure changes, is the failure mode most teams discover too late.
Signature-based detection had a good run. It's over.
A SANS Institute and Anvilogic survey of 264 security professionals found 80% of organizations are actively investing in detection engineering, and 60% now run dedicated teams. Large enterprises reach 85%. Detection engineering is a job family now, not a niche.
Why vendor rules keep failing you
Out-of-the-box rules don't know your environment. They won't baseline your AWS EC2 fleet, won't account for your GCP Cloud Run jobs making unusual outbound calls by design, and won't stop paging you for behavior your platform team has run for three years. Neither figure surprises anyone who has triaged an alert queue at 2 a.m.
Detection drift compounds the problem. When infrastructure changes, rules break, and they break silently. The postmortem says the detection existed; nobody knew it had stopped firing six months earlier. We covered the downstream consequence of that silence in our 11 June story on missed threats.
What the engineering approach actually requires
The pitch is straightforward: treat detection logic like software. Version it, test it, run it through a CI/CD pipeline so changes are auditable and rollbacks are possible. Map coverage against MITRE ATT&CK so gaps are visible before an adversary finds them. Use adversary emulation tools like Atomic Red Team to confirm rules actually fire.
The gap between that pitch and what ships is wide.
Clean, centralized telemetry is the prerequisite nobody wants to budget for. You need normalized log data from endpoints, cloud control planes, network flows, and your identity provider, all landing in a SIEM or data lake that can query at scale. Azure Sentinel, Chronicle, Splunk, whatever you've committed to. Without it, even well-written logic fires on noise or misses entirely. Garbage in, garbage out.
Should you trust the AI hype here
45% of organizations now use AI in their detection programs, mostly for anomaly detection and rule generation, per the SANS data. Vendors will call this a shift that changes everything. The honest read: ML helps with the tuning backlog 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 signatures that legacy tools were built to catch. Behavior-based detections that model what attackers actually do inside an environment require threat intelligence integration, ongoing threat modeling, and analysts who understand adversary TTPs well enough to write rules that survive an attacker who reads the same public frameworks you do.
Who is actually ahead
Finance and technology companies are leading adoption, facing regulatory pressure alongside sophisticated adversaries. Healthcare is catching up slowly. Any organization running complex hybrid infrastructure, on-premises Active Directory federated into Azure AD with workloads split across cloud providers, has the detection drift problem whether they've named it yet or not.
Start with your actual threat profile, not a generic framework checklist. Instrument cloud control plane logs before anything else.



