Yes. Detection rules only work when the underlying data is present, timely, and complete. If collectors, schemas, and transport credentials are unstable, more rules simply create more dependence on an unreliable feed. Pipeline observability should come first because it protects the integrity of every downstream use case.
Why pipeline observability belongs before more detection rules
Detection engineering only pays off when the telemetry pipeline is reliable enough to carry the signal. If collectors drop events, schemas drift, or transport credentials fail, the best rule in the world will miss activity or fire on incomplete context. pipeline observability is therefore a control on the control plane: it tells you whether downstream detection can be trusted at all.
That is why the question is not “rules or observability,” but whether the data path can support consistent detection outcomes. Pipeline health covers freshness, completeness, parsing success, routing, and source availability. Without those basics, adding rules mostly increases maintenance load, not detection quality.
A useful way to think about this is as dependency order. Detection rules consume the output of log collection, enrichment, and transport. If the feed is unstable, every rule inherits that instability. The MITRE D3FEND model is helpful here because it frames defensive capability as a chain of countermeasures that must operate on trustworthy inputs.
What breaks when the pipeline is not observable
When telemetry is not instrumented, teams usually discover problems only after an incident, a tuning complaint, or a gap in a case review. That creates blind spots in the exact moments where detection matters most. The issue is often not total failure but partial failure: delayed logs, truncated fields, duplicated events, or sources silently going dark.
Those faults distort both security operations and engineering prioritisation. Analysts may spend time tuning rules against bad data, while the actual issue is upstream. Pipeline observability exposes where the loss is happening, so teams can distinguish source failure from detection weakness and avoid chasing symptoms.
- Missing or delayed events create false negatives even when rules are correct.
- Schema drift breaks field matching and can quietly degrade detections.
- Credential or transport failures can stop ingestion without obvious user impact.
- Partial routing or enrichment failures can make alerts less actionable than expected.
For pipeline failure patterns and real-world credential exposure in build and delivery paths, the CI/CD pipeline exploitation case study and ArtiPACKED 2024 show how weak pipeline controls can turn operational issues into security exposure.
How to decide what to do first
Prioritise observability first when you cannot answer basic questions about the feed: what arrived, what was parsed, what failed, and what is delayed. If those answers are unclear, rule expansion is premature. If the pipeline is stable and measurable, then adding rules has a much better chance of improving detection instead of amplifying noise.
The practical sequence is to establish source coverage, pipeline status, and failure alarms before broadening detection logic. That means the detection program can trust volume trends, ingest timestamps, field integrity, and delivery health. Once those are visible, rule changes can be evaluated against a known-good baseline rather than against guesswork.
When pipeline telemetry is weak, start by improving visibility into the collection layer, message transport, and parsing layer. If you still cannot explain why a log source is silent, do not treat new rules as compensation. For attack-path awareness around exposed tokens and poisoned delivery flows, Shai Hulud npm malware campaign and reviewdog Action compromise 2025 are useful reminders that pipeline weaknesses often have security consequences beyond missed alerts.
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 NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1005 — Data from Local System | Telemetry gaps and missing logs directly affect adversary visibility and detection coverage. |
| Recommendation — Map missing telemetry paths to ATT&CK techniques and hunt for collection gaps. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Pipeline observability is part of continuous monitoring for trusted detection. |
| Recommendation — Instrument telemetry pipelines so monitoring can confirm data is flowing as expected. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Reliable log collection, retention, and monitoring underpin downstream detection rules. |
| Recommendation — Verify log collection and integrity before expanding detection content. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Detection depends on complete and timely events being generated and collected. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Observability enables review of missing, delayed, or malformed telemetry. | |
| Recommendation — Ensure required events are logged before tuning alert logic. Review pipeline failures as part of audit record analysis. | ||
Practitioner Guidance
What to prioritise: Make the pipeline observable before you expand detection coverage. The first win is not a larger rule set, it is evidence that your existing detections are seeing complete, timely, and correctly parsed data.
What to verify: Confirm source uptime, ingest latency, parsing success, schema stability, and credential health for every critical telemetry path. If any of those are opaque, treat the pipeline as an active risk rather than a background dependency.
Common mistake: Teams often add more detections to compensate for missing telemetry, then discover that the new rules only increase false confidence and operational churn. A bigger rulebook cannot repair a broken feed.
Practitioner takeaway: Detection quality is bounded by pipeline quality, so the right order is to make the data path measurable first and the detection layer more expressive second.
Related resources from NHI Mgmt Group
- Should organisations prioritise analyst-like AI before adding more alert rules?
- Should organisations prioritise passkeys before adding more detection tools?
- Should organisations prioritise least privilege before adding more cloud controls?
- When should organisations prioritise credential rotation over more detection rules?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org