Notifications
Clear all
Topic starter
06/07/2026 9:42 am
TL;DR: Log, endpoint, and network telemetry no longer give SOC teams enough visibility into application runtime behavior, so application visibility must become the fourth pillar of the SOC visibility model, according to Oligo Security. The missing layer matters because many modern attacks unfold inside applications, where legacy WAF and RASP controls often fail to provide enough context or response speed.
NHIMG editorial — based on content published by Oligo Security: The SOC Visibility Quad: Why Application Visibility Completes the SOC in 2025
Questions worth separating out
Q: How should security teams implement application visibility in a SOC?
A: Start by identifying the applications where runtime behaviour matters most, then instrument those workloads so the SOC can see executed code paths, not just logs or traffic.
Q: Why do logs, endpoints, and network tools fail to fully detect application-layer attacks?
A: They each cover only part of the attack surface.
Q: When should organisations treat application visibility as more than a nice-to-have control?
A: When attackers can operate inside cloud-native, encrypted, or SaaS-heavy environments where the triad no longer shows the actual execution path.
Practitioner guidance
- Define application runtime as a first-class detection source Map which applications must emit direct runtime telemetry, then decide where logs, endpoint data, and network signals are insufficient on their own.
- Prioritise executed code paths over static inventory Use production telemetry to separate loaded and reachable libraries from components that merely appear in a bill of materials or dependency scan.
- Rework detection engineering around malicious function calls Tune response logic to trigger on suspicious function invocation, abnormal runtime behaviour, and unexpected application paths rather than delayed log correlation.
What's in the full article
Oligo Security's full article covers the operational detail this post intentionally leaves for the source:
- The specific reasoning behind the SOC Visibility Quad model and how it extends the older triad
- A fuller explanation of why WAF and RASP fall short in modern runtime environments
- The Application Attack Matrix context that links app-layer threats to structured threat analysis
- CADR use cases for runtime blocking, supply chain clarity, and vulnerability prioritisation
👉 Read Oligo Security's analysis of the SOC Visibility Quad and application visibility →
Application visibility in SOCs: what does the quad change?
Explore further
06/07/2026 9:58 am
Application visibility is becoming the missing control plane for modern SOC operations. The triad still matters, but it cannot explain what happens inside cloud-native execution paths, encrypted services, or application runtimes. That leaves a governance gap between infrastructure telemetry and the actual layer where attackers now operate. Practitioners should treat runtime application visibility as a separate detection domain, not an optional enhancement.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to Oasis Security & ESG.
A question worth separating out:
Q: What should teams do when a vulnerable library exists but may not be executed in production?
A: They should verify whether the library is actually loaded, called, and reachable in the live application path before escalating it as an active risk. That distinction prevents wasted remediation effort and helps responders focus on exploitable exposure rather than theoretical inventory. Runtime evidence should drive prioritisation.
👉 Read our full editorial: Application visibility becomes the fourth SOC pillar in 2025
