From Reachability to Reality: Proving Vulnerable Code was Executed & Exploited in Production

The Problem: Alerts Without Proof

Traditional scanners and static reachability raise volume. We spend time going back and forth with Engineering on issues that never execute. Confirmation that a vulnerable function ran in our environment would eliminate the need for those conversations altogether. This allows us to focus on issues that are real in our application

The Solution: Runtime Function-Level Evidence in Kodem

• Supported Languages: Java, Scala, Kotlin, JavaScript, TypeScript, Go, Ruby, Python.
• Evidence location: Triage Issues > Runtime Evidence. Export JSON for developer handoff.
• Developer Context: Stack traces, image and environment context.
• Result: Correlated static findings with runtime evidence, reducing false positives and prioritizing issues that are both reachable and observed in execution.

How it Works

Kodem uses verified eBPF sensor programs that run directly within the kernel to provide a lightweight layer of visibility into system calls, process execution and file activity. The low-overhead visibility layer serves as a triggering mechanism for our memory analysis engine, which correlates kernel-level signals with memory fingerprints to confirm which code paths and third-party modules were actually loaded and executed.

Kodem Runtime Intelligence^TM tracks software modules as they load at runtime and builds a runtime bill of materials. It observes framework load functions and records which modules become active, then links observations to vulnerable functions tied to known CVEs.

The combination of lightweight eBPF visibility and comprehensive memory analysis provides detailed evidence: 

• Which vulnerable functions were observed in runtime.
• Which classes and packages executed.
• Which files are running.
• Which processes executed.
• Versus those that remained dormant.

This helps teams prioritize CVEs where vulnerable code paths have been loaded into memory and executed versus those that were not loaded during runtime.

What Memory Analysis Adds

Memory analysis transforms eBPF observations into effective prioritization. Rather than investigating every CVE, teams focus exclusively on vulnerabilities with evidence of runtime execution in their specific environment

Benefits: Proof Over Prediction - Reachability vs. Execution

Static call graphs often over-approximate possible call paths; they are designed for coverage, not certainty. Runtime evidence confirms execution in your environment, so teams prioritize the issues that truly run.

• Static reachability estimates whether code could call a vulnerable function. 
• Kodem confirms that a vulnerable function did run in your environment with function-level evidence.

The Result: Instead of 'CVE-2023-26136 might affect your system,' you get definitive function and file-level proof like this example from a JavaScript application:

{
        "environment": "staging",
        "namespace": "staging-ecommerce",
        "application": "shopping-cart",
        "image": "registry.company.com/apps/shopping-cart:v2.1.4",
        "package": "tough-cookie",
        "versions": [
            "2.4.3",
            "2.5.0"
        ],
        "language": "javascript",
        "issueInRuntime": true,
        "lastObserved": "2025-01-15T14:22:33Z",
        "firstObserved": "2024-12-08T09:15:42Z",
        "functionsInRuntime": [
            "/app/node_modules/tough-cookie/lib/cookie.js: CookieJar",
            "/app/node_modules/tough-cookie/lib/cookie.js: syncWrap",
            "/app/node_modules/tough-cookie/lib/store.js: Store",
            "/app/node_modules/tough-cookie/lib/memstore.js: MemoryCookieStore"
        ],
        "vulnerableFunctionsInRuntime": {
            "lib/memstore.js: MemoryCookieStore": [
                "CVE-2023-26136"
            ]
        },
        "vulnerableFunctionsNotInRuntime": {
            "lib/memstore.js: removeAllCookies": [
                "CVE-2023-26136"
            ],
            "lib/memstore.js: putCookie": [
                "CVE-2023-26136"
            ]
        },
        "runningFiles": [
            "/app/node_modules/tough-cookie/lib/pathMatch.js",
            "/app/node_modules/tough-cookie/lib/permuteDomain.js",
            "/app/node_modules/tough-cookie/lib/store.js",
            "/app/node_modules/tough-cookie/lib/version.js",
            "/app/node_modules/tough-cookie/lib/memstore.js"
        ],
        "runningVulnerableFiles": {
            "lib/memstore.js": [
                "CVE-2023-26136"
            ]
        }

Outcomes in Practice

“Most security tools are gym memberships. Kodem is the personal trainer actually helping us get fit.” — Nir Rothenberg, CISO, Rapyd.

At Rapyd, AppSec teams shifted from chasing volume to driving impact by focusing on issues with runtime function-level evidence of execution, not static predictions:

• 40% reduction in AppSec triage time by focusing only on executed vulnerabilities.
• 90% of scanner-detected CVEs proven non-exploitable in their environment.
• Faster developer adoption through evidence-backed prioritization that eliminates false positives.

AppSc-to-Dev Workflow: From Evidence to Fix

1. Share evidence where work happens: From Triage Issues → Runtime Evidence, AppSec teams export the JSON and create developer tickets with executed function details, stack traces, image context and environment specifics alongside the fix path.
2. Integrate into existing workflows: Kodem’s Jira integration brings runtime intelligence directly into development workflows, so engineers receive tickets with full execution context and can move from triage to resolution faster.
3. Make evidence-based policies enforceable: AppSec teams can implement policies that block deployments when executed vulnerable functions are detected in production namespaces; keeping security gates focused on real risk while allowing safe changes to flow.

Result: AppSec teams spend time on real threats, developers get actionable tickets with evidence. This evidence-driven approach transforms the traditional AppSec-Dev dynamic from "remediate everything we found" to "remediate what's actually running and exploitable in your environment."