The Revolution in Cloud Security Prioritization
In the modern cloud landscape, security teams are drowning in a deluge of vulnerabilities. Thousands of Common Vulnerabilities and Exposures (CVEs) lurk within base images, open-source libraries, and operating systems. While today’s security infrastructure is doing better at detection—scanning images, generating Software Bills of Materials (SBOMs), and identifying exposures at scale—the real battle has shifted.
The challenge is no longer finding vulnerabilities. It is prioritizing them effectively.
For years, vulnerability management has evolved from static image scanning to runtime awareness. Severity scores have expanded to include exposure context and real-world exploit intelligence. These advancements have successfully reduced noise and improved signal quality.
Yet, a critical question remains unanswered:
If a vulnerable package is present and loaded at runtime, is the vulnerable code actually being executed?
This distinction defines the difference between theoretical exposure and actual risk. Security teams need a way to prioritize based on what is actually executed, not just what is theoretically present. Vulnerability management is not about cataloging what exists in your environment. It is about understanding what can truly impact it.
Why It Matters?
Most security teams are not suffering from a lack of vulnerability data. They are suffering from too much of it.
When every vulnerability appears urgent, teams are forced to spread attention across thousands of findings, many of which may never pose meaningful risk in production. That leads to alert fatigue, slower remediation cycles, and constant friction between security and engineering teams trying to decide what truly deserves immediate action.
This is why execution-level validation matters so much.
A vulnerable package being present in an image is one thing. A vulnerable package being loaded at runtime is more important. But knowing that the exact vulnerable function is actually being executed in a live workload is a much stronger signal.
That level of proof helps teams focus on what is actively relevant, justify prioritization decisions with confidence, and reduce time spent chasing theoretical risk. In practice, it means faster remediation, better collaboration, and a much clearer path to reducing real exposure.
Runtime Presence Is Signal. Runtime Execution Is Proof.
We have long relied on the concept of runtime presence, which confirms that a package has been loaded into memory by a running process. This is a valuable signal. It indicates runtime relevance and reduces purely theoretical noise.
However, it fails to confirm the critical detail:
Is the specific vulnerable code path associated with a CVE being executed?
A library may be loaded without ever invoking the vulnerable function. A code path may be reachable without ever being exercised. Exploit conditions may exist without ever materializing.
This gap creates dangerous uncertainty. Security teams are left guessing which vulnerabilities represent real, active risk and which are merely theoretical risks sitting idle in their infrastructure.
To move from informed prioritization to definitive prioritization, execution evidence is required. We must move from “it might be there” to “it is being used right now.”
Exploitable Function-in-Use Detection
Upwind’s Exploitable Function-in-Use Detection changes the game. Instead of stopping at package presence or runtime loading, this technology validates whether the exact vulnerable function tied to a CVE is executed within live workloads.
This validation occurs per container, per language, and per environment. It is powered by two coordinated engines that work together:
1. LLM-Powered Vulnerability Analysis
Advanced large language models analyze CVE disclosures to extract the precise vulnerable functions and the specific conditions required for exploitation. This transforms raw vulnerability intelligence into structured runtime validation targets.
2. Runtime Execution Validation
Lightweight runtime sensors observe live workload behavior and verify whether those vulnerable functions are actually executed.
Together, these engines elevate CVE prioritization from contextual estimation to runtime-backed validation.
Why Runtime Is Required for Certainty
Validating whether a vulnerable function is executed cannot be achieved through static analysis alone.
Static scanners:
- Analyze images
- Identify packages
- Infer exposure based on metadata and version matching
Even advanced signals such as exploit intelligence and exposure modeling remain predictive. They are still educated assumptions, not observations of reality.
Execution, however, is observable.
To determine whether a vulnerable function is actually invoked, you must observe real workload behavior at runtime. That requires deep runtime visibility inside containers and processes. Without runtime presence, function-level validation is not technically possible.
This is where architecture matters. Solutions built with runtime as a foundational layer—such as Upwind—operate within live environments, providing continuous visibility into what is actually running, how it behaves, and how components interact.
Because these solutions operate at runtime, they can validate:
- Whether a vulnerable package is loaded
- Whether the specific vulnerable function is executed
- In which container it occurs
- Under which workload conditions it happens
This is not a heuristic. It is observed behavior.
How It Works:
Exploitable Function-in-Use Detection operates as a runtime monitoring subsystem designed to validate function execution without requiring application instrumentation. This is a major advantage for engineering teams, because it means no code changes are required.
At a high level, the process works as follows:
- Vulnerable function signatures are mapped to relevant workloads
- Running processes are identified and matched to their runtime environments
- Language-aware runtime hooks are selectively attached
- When a monitored function executes, the event is validated and enriched with workload context
The system supports interpreted and compiled runtimes, including environments that rely on just-in-time compilation. Hybrid tracing ensures accuracy whether code is interpreted or compiled to native instructions.
The result is precise, workload-level evidence of actual vulnerable function execution.
The Winner Approach
The Upwind way is a big industry shift:
- Legacy vulnerability management asks: What vulnerabilities exist?
- Modern runtime-aware prioritization asks: Which vulnerabilities are relevant?
- Exploitable Function-in-Use Detection asks: Which vulnerabilities are actively executed?
This shift reduces ambiguity. It removes assumptions from the prioritization process. It enables security teams to act based on validated behavior and, where execution is observed, concrete proof of exploitability.
At scale, that difference transforms operations.
See It It In Action
If you’d like to see how this feature fits into your environment – or to explore how Upwind can help you prioritize and remediate risk more effectively – schedule a customized demo with us. We’ll walk through your use cases, integrations, and security goals to show how Upwind delivers actionable cloud security at scale.
