Generally speaking, vulnerability management solutions still treat every flagged dependency as equally urgent. A CVE gets logged, a severity score gets assigned, and that’s often where the analysis stops. But a vulnerable package existing somewhere in an application’s codebase isn’t the same as that package’s vulnerable code actually being loaded into memory and reachable by an attacker.

In cybersecurity, the words “vulnerable” and “exploitable” mean different things. When they’re conflated, it leads to widespread alert fatigue as security teams are barraged by a high volume of vulnerabilities, even though many of them are found in inaccessible code. To avoid wasting time and effort, organizations need to focus on runtime risk prioritization. 

This is where Wiz’s Sensor Workload Scanner comes in. Rather than treating every flagged dependency the same way, it compares vulnerabilities against the code actually running in memory, revealing to security teams which findings are worth fixing first because they’re genuinely exposed to be exploited, and which ones are safe to leave alone for now. That prioritization job is separate from watching for an attack already underway, which other parts of the Wiz Sensor handle, but it’s the piece that most vulnerability management programs are still missing. 

Mapping What Risk Actually Means in a Modern Supply Chain

Nowadays, given how dynamic infrastructure can be, it’s best to avoid maintaining a static list of everything that exists in an organization’s software supply chain and instead build an active inventory. The idea here is to provide dual-layer visibility into not only what exists, but critically, whether or not those assets are active and executing in their runtime environment. 

There are several categories of supply chain assets that must be monitored: 

• Open-source and transitive dependencies: Vulnerable packages often sit inside a container image’s filesystem, but does the app ever call that function or module while it’s actually running?
• CI/CD pipelines and build servers: Scanners might reveal an exposed or overpermissioned build server or pipeline stage, but can that exposure actually be reached during an active deployment window, rather than just in theory? 
• Container registries and base images: These often contain libraries with known vulnerabilities, but do those libraries actually get loaded into memory when the app runs, or do they just sit dormant?
• Cloud services and third-party integrations: Some may have excessive permissions in theory, but does the integration actually exercise that access?
• Developer workstations and secrets: Exposed secrets and leaked credentials can cause damage either way, but runtime context still matters. Is the related account or service currently active with those excessive privileges, or has it already been rotated? 

Recent advances in scanning functionalities mean security teams are now capable of easily refreshing catalogs of the assets that exist in their supply chains, but the second layer, validating runtime execution, is a work in progress. 

Why Static Scanning Alone Produces Noise, Not Signal

Snyk’s open-source reachability analysis tool marked a real step forward from traditional manifest-matching, giving security teams a way to trace static call graphs and identify a viable path for attackers to reach vulnerabilities within a software dependency. Static reachability answers an important question. It just isn’t the whole question. 

Static analysis, however, works by examining source code without actually running it, so it can only tell us if a path could exist in theory. What it doesn’t do is reveal if that execution path currently exists within a workload that’s running in production, with real traffic hitting it. It’s a key distinction, because many vulnerable functions may be reachable in a code repository, without ever being executed in a runtime environment. 

In addition, some functions may be executable under conditions that static call graphs are unable to see, such as in environment-specific code branches, feature flags or dependencies that only run in rare infrastructure configurations. 

Static analysis alone tends to generate a high volume of false alerts. Instead of using a static scan to generate a one-time snapshot, Datavant utilized Wiz’s runtime validation tools to identify incomplete remediations and configuration drift, according to a recent case study. In doing so, it was able to reduce its number of flagged vulnerabilities by 51%, while also preventing any new critical and high-severity issues. 

Three key insights are invisible to static reachability analysis: 

• Does a statically reachable function actually execute against real production inputs? 
• Is the package loaded in-memory when the workload being assessed is running?
• Did a remediation that appeared to close the vulnerability actually hold once the environment configuration changed? 

How Wiz Validates Risk at the Point Where It Actually Matters

Wiz’s Sensor Workload Scanner uses a lightweight daemon to inspect workloads as they run within the runtime environment. By looking at how the application executes, it creates a dynamic Software Bill of Materials or SBOM based on which dependencies and functions are actually being executed right now within the runtime memory. 

It deprioritizes any vulnerabilities found in installed system files that aren’t loaded into running processes or exposed in any other way. 

The tool is compatible with diverse infrastructure environments. In the case of Linux, Kubernetes, virtual machines and serverless containers, it relies on extended Berkeley Packet Filters or eBPF, while on Windows it uses a customized and dedicated memory-safe kernel-mode driver. 

The Wiz Sensor Workload Scanner generates the following outputs:

• Runtime-validated SBOMs, namely a dynamic inventory of the active libraries, dependencies, binaries and modules running in a workload’s memory. 
• Automated deprioritization, where non-executable and dormant vulnerabilities are filtered out from the alert list to reduce fatigue. 
• Execution-based prioritization, with findings based on reachable exposure pathways, live memory state and active exploitability.

Where Other Runtime-Aware Tools Fit Into This Picture

Wiz isn’t the only vendor tackling this problem from the runtime side. Contrast Security approaches that same gap from a different angle. Through Contrast SCA, it combines static call graph analysis with actual runtime execution data, using language-specific agents that instrument the application and observe which classes and methods are actually invoked while it’s running. That runtime observation is what separates a confirmed, active finding from a theoretical path traced through source code alone.

The approach is conceptually similar to what Wiz’s Sensor Workload Scanner does at the infrastructure level, using an execution-level signal to sort functionally active vulnerabilities from ones that only exist on paper. The difference is where that signal comes from. Contrast instruments the application itself and requires an agent deployed within each monitored service, while the Wiz Sensor observes the workload from the operating system level, without requiring any changes to the application’s own code.

AccuKnox offers yet another approach to runtime risk validation. Like Wiz, it’s an eBPF-based platform, though its focus is enforcing runtime policy and containment at the kernel level rather than correlating risk across a graph. Its architectural approach is reliant on established zero-trust policies and is geared towards a “policy-enforcement-first model,” as opposed to Wiz’s “graph-correlation-first” model that’s all about contextualized risk. 

Building a Supply Chain Program That Prioritizes What’s Actually Exploitable

Rather than creating a ticket for every vulnerability that turns up, efficient application security programs treat those flagged dependencies as leads and follow up with an investigation that’s focused on the runtime reality. 

AppSec tools that prioritize runtime risk evaluate whether a vulnerability is actively exploitable, based on whether it’s loaded and running in memory, reachable over the network, and exposed within a privileged context, instead of relying only on its severity score or how recently it was disclosed. 

In this way, Wiz’s Sensor Workload Scanner helps security teams eliminate false positives stemming from dormant, inactive code, so they can focus their resources on the vulnerabilities that are actually loaded, running, and reachable.