Application visibility becomes the fourth SOC pillar in 2025

At a glance

What this is: This is an analysis of why application visibility is being added to the SOC visibility model and how it closes a blind spot in modern detection and response.

Why it matters: It matters because IAM, NHI, and broader security teams increasingly rely on application-layer behavior to understand where identities, workloads, and attacker actions intersect in cloud-native environments.

👉 Read Oligo Security's analysis of the SOC Visibility Quad and application visibility

Context

Application visibility is the ability to see what code and functions are actually executing inside an application, rather than inferring behaviour only from logs, endpoints, or network traces. The article argues that existing SOC telemetry misses the runtime layer where modern attacks increasingly operate, which leaves identity-linked workloads and service interactions harder to govern in practice.

For IAM and NHI programmes, that gap matters because access controls only go so far if teams cannot observe how applications consume credentials, invoke dependencies, or execute suspicious calls. The practical question is no longer whether a SOC has enough signal, but whether it can see the application boundary where secrets, service accounts, and runtime decisions intersect.

Key questions

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. Pair that telemetry with detection logic for suspicious function calls and reachable dependencies. The goal is to close the gap between what the app does and what the SOC can prove.

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: 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. If the business depends on applications that load third-party code, consume secrets, or call internal services dynamically, runtime visibility becomes essential for both detection and response.

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.

Technical breakdown

Why logs, endpoints, and network telemetry stop short

The original SOC Visibility Triad gave teams breadth, but each signal type has structural limits. Logs are retrospective and often lose execution context. Endpoint telemetry sees host activity but not the application logic that triggered it. Network telemetry is increasingly weakened by encryption, SaaS, and distributed workloads. Together, they can show that something happened, but not always why it happened inside the application layer. That is why attackers can remain inside runtime paths without triggering the usual detection stack.

Practical implication: SOC teams should treat application runtime as a distinct telemetry domain, not as an extension of infrastructure logging.

What application telemetry reveals that WAF and RASP miss

Application visibility is not just another filter in front of traffic. It means direct telemetry from inside the application, where teams can see which functions are executed, which libraries are loaded, and which calls are actually reachable. WAFs mostly inspect inbound requests at the surface, while RASP introduced in-process awareness but often created performance and operational friction. The article’s core point is that only runtime application telemetry can show the true exploit surface, especially when dependencies and code paths differ from what policy assumed.

Practical implication: use runtime application telemetry to prioritise controls around the code paths attackers can actually reach.

How application visibility changes supply chain and response decisions

Modern applications depend on open source and third-party components, so the security question is no longer whether a vulnerable library exists somewhere in the bill of materials. The real issue is whether that component is loaded, executed, and reachable in production. Application visibility helps SOC teams separate theoretical exposure from exploitable exposure, which is crucial for response prioritisation. It also supports real-time blocking when malicious function calls are observed, shifting the SOC from post-event correlation toward runtime intervention.

Practical implication: align vulnerability triage, detection engineering, and runtime blocking around executed code paths rather than inventory alone.

NHI Mgmt Group analysis

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.

Runtime function calls are the new evidence stream for application-layer attack detection. Logs and endpoint data can show surrounding activity, but they often miss the malicious function invocation itself. That is why SOC teams need to see executed code paths, not just events derived from them. The implication is that detection engineering has to move closer to the application boundary.

Supply chain visibility only becomes actionable when teams can see what is actually executed. A vulnerable dependency on paper is not the same as an exploitable dependency in production. Application visibility makes that distinction visible and helps reduce noise in vulnerability management. Practitioners should stop treating software inventory as proof of exposure.

Legacy surface controls do not collapse the runtime blind spot. WAFs filter requests, and RASP tried to extend awareness into the process, but neither fully solves the visibility problem described here. The gap is structural: attackers increasingly succeed in the layer those controls only partially see. Security teams should reframe the control objective around runtime observability, not perimeter interception.

Identity and application visibility are converging in the same operational plane. As workloads, service accounts, and application calls become more tightly coupled, security teams need to understand which identities are driving which runtime actions. That is where IAM, NHI, and SOC functions overlap most sharply. Practitioners should align telemetry, entitlement review, and response around the application session itself.

From our research:

• 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.
• Application visibility becomes more urgent when teams can separate theoretical exposure from live execution, so review the NHI Lifecycle Management Guide alongside runtime detection planning.

What this signals

Runtime observability is now part of identity governance. When service accounts, tokens, and workload identities are consumed inside application code, the governance question shifts from who has access to what, toward what the application actually does with that access. Teams that cannot observe runtime behaviour will struggle to prove least privilege in practice.

The operational signal is that detection, vulnerability management, and identity review are converging around the same control point. If your programme still treats application telemetry as a niche AppSec capability, you are likely missing the point where identity use becomes observable and actionable. The NIST Cybersecurity Framework 2.0 is most effective here when teams connect identify, protect, and detect functions to runtime evidence.

For practitioners

• 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.
• Align NHI review with application execution points Check where service accounts, tokens, and workload identities are consumed by application code, then review whether those execution points are observable and governable.

Key takeaways

• The article’s core argument is that the SOC Visibility Triad no longer shows enough of the application layer to explain modern attack behaviour.
• Its practical significance is that runtime evidence, not static inventory alone, determines which dependencies and code paths are actually exploitable.
• Security teams should treat application telemetry as a distinct control plane and align SOC, AppSec, and identity review around runtime behaviour.

Key terms

• Application Visibility: The ability to observe what an application is actually doing at runtime, including executed code paths, function calls, and active dependencies. It goes beyond logs or network traces by exposing the layer where many modern attacks and identity-driven actions occur.
• Runtime Telemetry: Signals collected from an application while it is executing, rather than after the fact. For identity and security teams, runtime telemetry is valuable because it shows how code, secrets, and workload identities behave in production.
• Application-layer Attack: An attack that targets the logic, code paths, or dependencies of an application rather than only the surrounding infrastructure. These attacks often evade traditional perimeter controls because the decisive action happens inside the runtime environment.
• Executed Dependency: A third-party or open-source component that is not just present in a build, but actually loaded and called in production. This distinction matters because only executed dependencies represent live exposure that attackers can often reach.

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

👉 Oligo Security's full article covers the triad-to-quad rationale, app-layer threat mapping, and CADR capabilities

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.