How can security teams tell whether their applications are exposed?

How to verify an application is actually exposed

The first pass is to separate theoretical dependency presence from real execution exposure. A vulnerable package in the tree matters most when the application imports the affected React server-component path and exercises server-side rendering, server functions, or unstable RSC APIs. If the code only ships static client-side output, the blast radius is usually much smaller than the dependency list alone suggests.

That means teams should inspect the package graph, then trace whether the vulnerable component is reachable in the deployed build. A codebase can include the affected library indirectly without being exploitable if the relevant API surface is never invoked. The practical question is not “is the package installed?” but “can this deployment hit the vulnerable server-side path under normal operation?”

When the question is about reachability, the strongest evidence comes from build artefacts, framework configuration, and runtime behaviour. Look for route segments, component boundaries, server actions, and any feature flags or environment-specific code paths that turn a dormant dependency into an active exposure.

What makes exposure real instead of hypothetical

Exposure becomes meaningful when three conditions line up: the affected dependency is present, the vulnerable functionality is reachable, and the application uses the relevant server-side feature at runtime. This is why a dependency audit alone is incomplete. Two applications can share the same package version, yet only one is exposed because only one invokes the vulnerable code path.

For React server-component issues, the key distinction is between code that is bundled but inert and code that is executed during rendering or server invocation. Server functions and unstable RSC APIs are particularly important because they can move the vulnerable path from “present in source” to “reachable in production.”

Security teams should also remember that exposure can be partial. An application may be vulnerable in one route, tenant, or deployment tier but not another. That is common in monorepos, multi-tenant platforms, and hybrid builds where only some surfaces exercise the server-side feature.

How to confirm exposure with confidence

Use a reachability-based review: map the affected dependency to the exact imported module, identify the code path that triggers it, and verify whether that path is used in production traffic. The most useful checks are often source tracing, build inspection, and targeted runtime testing rather than broad package inventory alone.

Teams should also compare what is deployed with what is in the repository. A vulnerable package may appear in lockfiles, but the shipped bundle may exclude the affected code because of tree-shaking, feature gating, or dead code elimination. The inverse is also true: a seemingly minor helper can become exposed when a framework upgrade or refactor starts invoking server-side logic by default.

For broader incident context and attacker tradecraft around exposed secrets, tokens, and service accounts, see The State of NHI & AI Agent Breach Report 2026, which helps frame why confirming real reachability matters before treating every vulnerable dependency as equal.

Practitioner Guidance

What to prioritise: Start with the routes and components that actually execute server-side code, then work outward to secondary dependencies. That usually finds the highest-risk exposure fastest.

What to verify: Confirm that the vulnerable path is reachable in the deployed build, not just present in source control. If the code path requires server functions or unstable RSC APIs, test those execution points directly.

Common mistake: Treating dependency presence as exposure. In this class of issue, the tree tells you where to look, but execution reachability tells you whether the application is truly exposed.

Practitioner takeaway: Exposure is a runtime question, not a package-list question, so teams should validate actual server-side invocation before they decide how broadly to triage or patch.

Related resources from NHI Mgmt Group

• How can security teams tell whether an AI serving service is actually exposed?
• How can security teams tell whether AD is too exposed?
• How can security teams tell whether Linux hosts are actually exposed to this class of bug?
• How can security teams tell whether a host is exposed to this kind of helper abuse?