TL;DR: SANS found that only 18% of detection teams say they are staying ahead of the threat landscape, while 56% say they are barely keeping pace and 24% are falling behind, according to Axoflow's analysis of the 2026 State of Detection Engineering survey. The underlying issue is not just rule-writing speed, but brittle data collection, schema drift, and weak validation that leave cloud-native environments undercovered.
At a glance
What this is: This is an analysis of why detection engineering is struggling to keep pace in cloud-native environments, with cloud-native logs, schema drift and validation gaps emerging as the main failure points.
Why it matters: It matters because IAM, NHI and broader security teams depend on reliable telemetry to validate access, privilege and workload behaviour, and weak data plumbing makes those controls look healthier than they are.
By the numbers:
- Only 18% of detection teams say they are staying ahead of the threat landscape, according to Axoflow's analysis of SANS research.
- 56% report barely keeping pace, according to Axoflow's analysis of SANS research.
- 24% say they are falling behind, according to Axoflow's analysis of SANS research.
- 43% of respondents name cloud-native environments as their single biggest detection blind spot, according to Axoflow's analysis of SANS research.
Context
Detection coverage depends on the quality and stability of the data pipeline as much as on the rules that consume it. When logs come from containers, ephemeral workloads and API-driven infrastructure, the telemetry layer can shift faster than the detection content built on top of it.
That creates a governance problem for security programmes that assume collection, normalisation and validation are stable back-end concerns. In cloud-native estates, the identity and workload context that security teams need to trust often sits inside brittle pipelines, so the boundary between observability and detection becomes a control issue, not just an engineering one.
Key questions
Q: Where does detection engineering fail most often in cloud-native environments?
A: It usually fails at the telemetry layer, not at rule authoring. Containers, ephemeral workloads and API-driven infrastructure reshape faster than parsers, field mappings and validation processes can keep up, so rules point at data that has drifted or disappeared. The practical answer is to govern collection, normalisation and schema stability as part of detection assurance.
Q: Why does automating detection rules not fix cloud-native blind spots?
A: Because the bottleneck is often the data path underneath the rules. If collection is brittle, schemas drift and validation is weak, automation only produces faster rules on top of unstable inputs. That improves throughput, but it does not restore coverage. Teams need to automate the first mile of telemetry handling, not just the rule-writing layer.
Q: How do security teams know detection-as-code is actually working?
A: Look for fewer untracked production edits, faster safe deployment of rule changes, and test results that show known threats trigger as expected before rollout. Audit prep should also become easier because every rule change has a reviewer, a reason, and a history. If those signals are missing, the process is still partly manual.
Q: What should organisations do when cloud-native logs are inconsistent or incomplete?
A: They should treat the logging pipeline as a control surface and fix collection, normalisation and schema-drift handling before expanding rule volume. Inconsistent logs are often a design issue in ephemeral infrastructure, not a tuning issue in the SIEM. The right response is to stabilise the telemetry path so detection content can be trusted.
Technical breakdown
Why cloud-native telemetry breaks detection assumptions
Cloud-native systems generate logs from short-lived containers, elastic services and API-driven infrastructure that change shape continuously. Traditional detection pipelines assume relatively stable hosts, fields and collection paths, so the moment the environment self-reconfigures, field names drift, sources disappear and parsers lose fidelity. The result is not just missed alerts. It is a control plane that no longer maps cleanly to the assets and identities it is supposed to observe. In practice, collection must be designed around ephemeral infrastructure rather than retrofitted after the environment scales.
Practical implication: Design collection and normalisation for ephemeral workloads first, or detection coverage will always lag the environment it is meant to watch.
What schema drift does to detection content
Schema drift is the silent failure mode in modern detection engineering. A Sigma rule, correlation query or alert logic may be syntactically valid while pointing at a field that no longer exists, has changed type or now arrives under a different name. That means the content appears deployed but no longer tests the behaviour it was written for. This is a data governance issue as much as a SOC issue, because the control is only as reliable as the schema stability beneath it. Without drift handling, teams automate broken assumptions instead of detections.
Practical implication: Treat schema stability as part of detection assurance, not an implementation detail left to downstream tuning.
Why detection-as-code fails without validation
Detection-as-code borrows software engineering discipline, but teams often stop at version control and peer review. Without automated validation, rules can ship with broken field mappings, untested logic or assumptions that only fail in production. The deeper issue is that detection content and the data it depends on are frequently managed by different teams, so the test surface is split across engineering boundaries. In a cloud-native environment, that separation makes the deployment pipeline the wrong place to discover whether the rule still works. Validation has to happen before ingestion or the failure arrives too late.
Practical implication: Run automated tests against live or representative telemetry before content reaches the SIEM, so broken detections are caught upstream.
NHI Mgmt Group analysis
Cloud-native detection blind spots are a telemetry governance problem, not a rule-writing problem. The article's central point is that automation aimed only at detection content leaves the underlying data instability untouched. When collection breaks first, faster rule production simply scales the same blind spots. Practitioners should treat telemetry reliability as part of security governance, not a post-processing concern.
Schema drift is the named failure mode this survey exposes. Detection logic can look complete while silently losing coverage because source fields, formats and collection paths keep changing. That means the organisation may believe it has controls in place when those controls are no longer anchored to the actual data. The practical conclusion is that schema governance belongs inside the detection lifecycle.
Cloud-native estates force security teams to align observability with control assurance. The more ephemeral the infrastructure, the more detection quality depends on collection architecture, normalisation and validation happening before content reaches the SIEM. That is especially relevant where machine identities, service accounts and workloads change rapidly, because identity evidence is only useful if the telemetry layer preserves it. Security teams should measure assurance at the pipeline boundary, not just at the alert boundary.
Detection-as-code only matures when it inherits software testing discipline. Version control and peer review are necessary but insufficient if no automated validation checks the rule against live behaviour. The survey results show a field that has adopted the easy parts of engineering and left the assurance part incomplete. Practitioners should expect the next maturity leap to come from upstream validation, not from more manual tuning.
First-mile detection engineering: The article sharpens a useful concept for the market: the quality of the first mile, where data is collected, classified and stabilised, matters more than the last mile where rules are written. That is where cloud-native environments either preserve trust in telemetry or quietly erode it. Teams that cannot govern the first mile will keep shipping detections into uncertainty.
What this signals
Cloud-native detection maturity will increasingly depend on whether organisations can govern telemetry as rigorously as access. The teams that win here will be the ones that stop treating log collection as plumbing and start treating it as a control boundary.
First-mile detection engineering: the real maturity gap sits where data is collected, classified and stabilised before detection content ever runs. That boundary is where cloud-native environments either preserve trustworthy evidence or turn every alert into a schema-dependent guess.
For practitioners
- Instrument the first mile of detection Map where logs are collected, classified and normalised before they enter the SIEM, and document every handoff that can break under ephemeral workloads.
- Add automated validation before deployment Require tests that run detection logic against representative or live telemetry so broken field mappings and dormant rules fail in the pipeline, not in production.
- Assign ownership for schema stability Define who owns field mapping, parsing and drift handling across security and data teams, then make schema changes visible to detection engineers before they ship.
- Prioritise cloud-native blind spots first Use coverage reviews to focus on containers, ephemeral workloads and API-driven infrastructure before expanding rule volume elsewhere, because those are the areas the survey shows are most undercovered.
Key takeaways
- Cloud-native environments expose a structural weakness in detection programmes because the data layer changes faster than many teams can validate.
- The article points to collection brittleness, schema drift and weak testing as the practical reasons cloud-native blind spots persist.
- Security teams should move assurance upstream, with telemetry governance and automated validation treated as part of detection control design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007;TA0010 — Discovery; Exfiltration | Detection blind spots weaken visibility into adversary discovery and data removal paths. |
| Recommendation — Map telemetry gaps to ATT&CK techniques and prioritise the blind spots that remove visibility into key adversary stages. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | The article is about whether monitoring remains effective as cloud-native environments reshape logs. |
| PR.DS-01 — Data-at-rest is protected | Schema and log integrity govern whether security data remains reliable enough for detection use. | |
| Recommendation — Review monitoring coverage against DE.CM-01 and close the collection gaps that cloud-native change introduces. Protect detection data pipelines so normalisation, retention and schema stability preserve trustworthy telemetry. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article focuses on how log collection, normalisation and validation fail in modern environments. |
| Recommendation — Harden audit log management by validating log sources, schemas and coverage before relying on them for detections. | ||
| CSA Cloud Controls Matrix | SEF — Security Event Management | Cloud-native detection depends on event collection, correlation and monitoring within the cloud control plane. |
| Recommendation — Use SEF controls to govern cloud event collection, correlation and detection validation across dynamic workloads. | ||
Key terms
- Schema Drift: Schema drift is the mismatch between the attributes an IdP sends and the fields an application can store or interpret. It often appears as missing custom fields, inconsistent group data, or varying attribute names, and it undermines the reliability of lifecycle automation even when the core protocol works.
- First-Mile Detection Engineering: First-mile detection engineering is the work of collecting, classifying and normalising telemetry before it reaches detection logic. It shifts attention from writing alerts to making sure the data path is stable, trustworthy and ready for validation in cloud-native environments.
- Detection as code: A method of managing detection logic like software, using version control, testing, and deployment pipelines. It improves change control and rollback discipline, which is especially useful when AI helps generate or tune rules that will be deployed into production.
- Cloud Native Security Telemetry: Cloud native security telemetry is the security data produced by cloud-hosted systems, services, and workloads. It includes logs, metrics, traces, events, and identity signals from containers, APIs, orchestration layers, and managed services, giving defenders evidence to detect misuse, investigate incidents, and verify control effectiveness across dynamic environments.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs a clearer model for governing identities, secrets and access across modern environments.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org