Runtime Verified Feature – How AccuKnox Eliminates Vulnerability Noise in Containers and VMs

You run a vulnerability scan across your Kubernetes cluster, and 22,000 findings come back. Your team has a finite number of hours and a finite amount of patience. The real question is not how many CVEs exist in your images — it is which ones are actually running in production right now, and which ones are genuinely capable of being exploited by an attacker.

AccuKnox answers that question precisely, and the mechanism behind the answer is called Runtime Verification.

The Vulnerability Backlog Nobody Can Actually Fix

Every container image built for production picks up dozens of packages, and a significant portion of those packages will never be invoked once the container is actually running. A static vulnerability scanner has no way of knowing this distinction — it reads the software bill of materials, matches package versions against CVE databases, and reports everything it finds. The result is a list that is technically accurate but operationally useless, because it treats a library that executes ten thousand times a day the same as a library that has never been loaded once.

Security teams end up spending their most valuable resource — focused human attention — triaging vulnerabilities in packages that pose no real-world risk at all, while the CVEs that genuinely matter are buried somewhere on page forty-seven of the report.

How AccuKnox Knows What Is Actually Running

AccuKnox addresses this problem at the source by deploying KubeArmor, its runtime security engine, directly within your Kubernetes clusters or virtual machines. KubeArmor uses eBPF to observe exactly what is happening inside your workloads in real time — which processes are executing, which files are being accessed, and which network connections are being established.

This telemetry streams continuously to the AccuKnox Control Plane, where it is correlated against CVE data and package metadata. The output is the Runtime Verified flag — a definitive marker that a vulnerable package is not merely present in an image, but is actively executing in your live environment and therefore represents a real, exploitable risk.

The Scalability Problem AccuKnox Solved

Collecting kernel-level telemetry at the scale of a production Kubernetes cluster is not trivial. Every context switch between kernel space and user space consumes CPU cycles, and at high event volumes this overhead becomes severe enough to degrade the very workloads you are trying to protect — which is why many runtime security tools either sample aggressively or simply do not attempt this depth of visibility.AccuKnox holds a patent for optimized in-kernel aggregation of runtime telemetry, filed in 2020 and granted in 2024. The approach uses eBPF to aggregate and batch events inside the kernel before forwarding them to user space, which reduces CPU overhead by more than 95% and cuts telemetry volume by more than 90%. This is what makes deep runtime visibility practical at enterprise scale.

From 22,000 Findings to 1,510 That Actually Matter

The impact of Runtime Verification becomes concrete when you look at what it does to a real dataset.

A production cluster in this example contained 22,267 container image vulnerabilities. After applying the Runtime Verified filter, the number of findings requiring active investigation dropped to 1,510. That is the same cluster, the same packages, and the same CVE database — but now the security team is looking exclusively at vulnerabilities that are provably executing in their environment. The remaining 20,000+ findings are not dismissed; they are deprioritized with full transparency, and the team’s attention is focused where it belongs.

Proof That a Vulnerability Is Live, Not Just Present

Runtime Verification produces detailed, auditable evidence for every finding it flags, which means security teams can see precisely why a vulnerability has been marked as active rather than simply trusting a score or a label.

When a Library Is the Evidence

Consider CVE-2024-41996, a vulnerability in openssl-libs. AccuKnox marks this finding as Runtime Verified because it directly observed the OpenSSL library file at /etc/pki/tls/openssl.cnf being accessed inside the running container — not because the package appears in the image manifest, but because the library was demonstrably loaded and used. This is the difference between a finding that demands immediate remediation and one that can be safely scheduled for the next patch cycle.

When a Process Is the Evidence

For CVE-2022-41723, a high-severity vulnerability in the Golang standard library that allows maliciously crafted HTTP/2 streams to cause excessive CPU consumption and denial of service, AccuKnox confirmed that the process /bin/vault was actively executing inside the HashiCorp Vault container. The vulnerable library was not dormant — it was being invoked by a live process, which elevates this finding to an immediate remediation priority regardless of where it sits in a raw severity ranking.

Up and Running in a Single Helm Command

Enabling Runtime Verification requires enabling two options during cluster onboarding — Runtime Visibility and Protection, which installs the KubeArmor and AccuKnox agents, and Scan Running Images, which restricts scanning to images that are actively deployed in the cluster rather than scanning everything in the registry.

Once these options are selected, the platform generates a complete Helm command automatically. A single install command brings KubeArmor and the AccuKnox agents online, and runtime telemetry collection begins immediately. The same workflow applies to virtual machines running Docker or containerd directly, not only to Kubernetes clusters.

Knowing It Runs Is Half the Story, Knowing It Is Exploited Is the Other Half

Runtime Verification tells you which vulnerabilities are active in your environment. External enrichment tells you which of those active vulnerabilities are being exploited right now, in the real world, by real attackers.

AccuKnox pulls from a comprehensive set of external intelligence sources to augment every finding. The National Vulnerability Database and CWE provide baseline CVE context. EPSS from first.org provides a probability score for exploitation within the next thirty days. The CISA Known Exploited Vulnerabilities catalog confirms that a vulnerability has been actively exploited in the wild. GitHub Proof-of-Concept links surface publicly available exploit code. NVIDIA advisories cover vulnerabilities specific to AI and GPU workloads, and the Microsoft Security Response Center adds Windows and Azure-specific intelligence.

When a GitHub PoC exists for a vulnerability, that finding is typically on its way into the CISA KEV catalog within weeks. A finding that is Runtime Verified, carries a high EPSS score, and has a publicly available PoC is not merely urgent — it is the definition of what security teams should be working on today.

Every Signal, One Control Plane – The Only Number That Matters Is the One You Can Actually Fix

Vulnerability management has always suffered from a signal-to-noise problem, and static scanning alone makes that problem worse with every image you add to your environment. Runtime Verification is the mechanism that transforms an overwhelming list of theoretical exposures into a focused, evidence-backed set of genuine priorities — not because it ignores the rest, but because it knows the difference.

When your cluster has 22,267 vulnerabilities and your team has time to fix 1,510 this sprint, AccuKnox tells you exactly which 1,510 to choose. The full AccuKnox architecture integrates all of these data streams into a single, unified control plane that security teams interact with through dashboards, reports, and the knoxctl command-line interface.

KubeArmor and the image scanner operate on the compute layer — whether that is a Kubernetes cluster or a virtual machine — and send runtime telemetry and scan findings to the AccuKnox Control Plane. Threat intelligence from sources like Open Threat Exchange and IP2Location, combined with API activity data from AWS CloudTrail, Amazon API Gateway, Azure APIM, and Kong, flows into the enrichment and SIEM layers. Everything converges in one place, giving security teams a complete and correlated view of their vulnerability landscape.

Start your security trial at AccuKnox →

FAQs