Application visibility becomes the fourth SOC pillar in 2025

At a glance

What this is: This is Oligo Security’s argument that SOC visibility now needs a fourth pillar, application visibility, because logs, endpoints, and networks do not fully expose application runtime behaviour.

Why it matters: For IAM and security teams, the shift matters because attacks increasingly exploit application-layer execution paths, which changes how visibility, detection, and response should be designed across cloud and software estates.

Context

The SOC Visibility Triad was built around logs, endpoint telemetry, and network data, but modern application behaviour increasingly happens where those signals have limited context. Application runtime is now part of the security perimeter, especially in cloud-native and distributed environments where execution paths are harder to infer from outer layers alone.

Oligo Security frames application visibility as the missing layer because attackers can operate inside applications without generating enough obvious infrastructure-level evidence. That makes runtime visibility, not just alert correlation, central to SOC decision-making for teams responsible for application security, cloud detection, and response.

The article’s premise is that the older model is still necessary but no longer sufficient. That is a typical problem for modern SOCs, not an edge case.

Key questions

Q: How should SOC teams handle application-layer blind spots in modern environments?

A: SOC teams should treat application-layer blind spots as a visibility gap, not a tuning problem. If logs, endpoints, and networks cannot show what the application executed, the SOC needs direct runtime telemetry from inside the application to support detection, prioritisation, and response decisions.

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. Logs are often late and context-poor, endpoint tools stop at the host, and network tools struggle with encryption and distributed execution. Application-layer attacks can succeed entirely inside runtime behaviour, so the SOC needs direct application telemetry to see the decisive evidence.

Q: What are the signs that application visibility is too weak for SOC use?

A: Common signs include repeated alerts with poor application context, vulnerability findings that do not map to real runtime exposure, and incident investigations that stop at the infrastructure layer. If teams cannot identify loaded components or executed functions, application visibility is probably insufficient.

Q: Should organisations replace WAF and RASP with application visibility?

A: No. WAF and RASP still have value, but they solve partial problems and do not by themselves expose full application runtime behaviour. Application visibility should complement those controls by giving SOC teams the missing evidence needed to understand what happened inside the software.

Technical breakdown

Why log, endpoint, and network telemetry miss application runtime behaviour

Logs show activity after the fact, endpoints show host and process state, and network tools see traffic patterns rather than what the software is doing internally. In modern environments, those layers often miss the specific function calls, code paths, and dependency interactions that define application runtime behaviour. Encryption, distributed services, and SaaS workflows further reduce what infrastructure telemetry can prove. The result is a visibility gap at the exact layer where many attacks now execute, persist, or blend into normal application activity.

Practical implication: SOCs need telemetry from inside the application, not only from surrounding infrastructure.

How application visibility changes detection and response

Application visibility adds direct runtime telemetry from the software itself, which lets SOC teams see which components are loaded, which functions execute, and whether malicious calls are occurring in real time. That matters because many application-layer attacks are too fast or too context-specific for delayed correlation to catch reliably. The difference is not just more alerts, but more precise evidence about what actually ran. That supports faster triage, better prioritisation, and more defensible blocking decisions when the application is the attack surface.

Practical implication: detection logic should key off runtime execution evidence, not only off post-event logs.

Why legacy WAF and RASP controls are not enough

WAFs were designed to filter requests at the edge, so they usually see surface-level inputs rather than application intent or internal execution outcomes. RASP moved closer to the application but often introduced performance and operational friction that limited adoption or coverage. Neither model fully solves the visibility problem when attackers exploit open source components, third-party libraries, or in-process behaviour that only runtime telemetry can expose. The practical takeaway is that perimeter-style controls and in-app monitoring solve different problems, and neither should be assumed to complete the picture alone.

Practical implication: teams should treat WAF and RASP as partial controls and validate what they still cannot observe.

Threat narrative

Attacker objective: The attacker wants to operate inside the application layer long enough to avoid detection while exploiting vulnerable runtime behaviour or trusted components.

1. Entry begins at the application layer, where attackers target runtime behaviour that is not fully exposed by logs, endpoints, or network telemetry.
2. Escalation occurs when malicious function calls or vulnerable components are exercised inside the application, creating activity that legacy controls may not surface quickly enough.
3. Impact follows when the attack remains inside the software layer long enough to evade detection, delay response, or spread into adjacent cloud environments.

NHI Mgmt Group analysis

Application visibility is now a SOC governance issue, not a niche observability add-on. The old triad assumed that logs, endpoints, and networks would expose enough of the attack surface to support detection and response. That assumption breaks once meaningful attacker activity occurs inside application runtime, where infrastructure telemetry loses context. The implication is that SOC operating models must treat application-layer evidence as a first-class source of security truth.

Runtime telemetry creates the missing evidence layer for modern attack paths. SOC teams cannot prioritise what they cannot see, and application execution paths are increasingly where attackers hide exploitable behaviour. Visibility into loaded libraries, executed functions, and in-process calls changes both the speed and quality of response. Practitioners should treat runtime evidence as the control plane for application-layer detection.

Legacy controls still matter, but they do not complete the coverage model. WAF and RASP were designed to narrow the gap, yet each carries structural limits that prevent them from replacing direct application visibility. That means the right question is not whether the triad failed, but what new layer must sit alongside it. For practitioners, the governance lesson is that partial visibility is not sufficient when attack paths are software-native.

Supply chain clarity becomes part of SOC visibility when applications are the target. Application telemetry can reveal which open source and third-party components are actually loaded and executed, which is materially different from simply knowing what the bill of materials lists. That distinction matters because vulnerability exposure is runtime-specific, not theoretical. Teams should align SOC and application security around executable reality, not inventory alone.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).

What this signals

Application visibility is a control-plane issue for SOCs. Once attackers can stay inside software execution paths, the old assumption that perimeter and endpoint telemetry are enough no longer holds. Teams need runtime evidence that explains what the application actually did, not just what surrounded it.

Only 5.7% of organisations have full visibility into their service accounts. That figure matters here because visibility gaps are rarely isolated to one layer; when teams cannot fully see machine identity estates, they usually cannot fully see application behaviour either.

Application runtime telemetry changes prioritisation. It lets defenders distinguish theoretical exposure from code that is actually loaded and exercised, which is a more defensible basis for response than broad alert volume alone.

For practitioners

• Map application-layer blind spots Identify where current SOC telemetry stops at infrastructure boundaries and cannot see runtime function calls, dependency execution, or in-process malicious behaviour.
• Instrument runtime evidence sources Prioritise telemetry that captures actual application execution paths so detections can key off what software did, not just what traffic or logs suggest.
• Reassess WAF and RASP coverage Document which application-layer behaviours those controls still miss, especially in encrypted, distributed, or cloud-native environments.
• Tie vulnerability triage to execution reality Focus remediation on libraries and components that are demonstrably loaded and reachable at runtime, not only those listed in inventory or static analysis.
• Correlate SOC and application security workflows Use the same runtime signals for detection, prioritisation, and response so application security findings can drive operational SOC action.

Key takeaways

• The article argues that the SOC Visibility Triad no longer captures enough of the application layer to support modern detection and response.
• Application runtime behaviour is the missing evidence source because attacks can unfold inside software without leaving clear infrastructure-level signals.
• SOC teams should evaluate application visibility as a complementary pillar alongside logs, endpoints, and networks, not as a replacement for them.

Key terms

• Access Visibility: Access visibility is the ability to see, in one place, which identities can reach which data, applications, and services. For IAM and data security teams, it is the difference between reviewing isolated permissions and understanding real blast radius across environments.
• Runtime telemetry: Observation of what a system actually does while it is executing. In agentic CI/CD, this means seeing which commands, files, tools, and credentials an agent touched so security teams can detect misuse that static workflow review will miss.
• Cloud Application Detection And Response: Cloud Application Detection and Response is the practice of identifying suspicious behaviour inside live cloud applications and workloads, then containing that behaviour before it spreads. It focuses on runtime signals such as unusual access, API misuse, and escalation paths that scan-time posture tools cannot see.
• Application attack matrix: A structured map of attacker tactics, techniques, and procedures against application environments. It helps teams see how abuse moves through APIs, business logic, dependencies, and runtime behaviour, rather than stopping at host or network concerns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.