Cutting SCA Noise: Using Runtime Call Tracing to Triage Vulnerabilities

Modern applications rely on deep dependency trees. Consequently, Software Composition Analysis (SCA) scanners constantly trigger security alerts for newly discovered CVEs in third-party libraries.

However, traditional SCA tools suffer from a fundamental limitation: presence-based alerting. They flag vulnerabilities simply because a package version appears in a lockfile or container manifest, completely unaware of whether the vulnerable function or method is actually executed by your application.

Attempting to triage every transitive alert—either manually or by feeding full codebases into LLMs for deep taint analysis—is expensive, slow, and rapidly exhausts engineering time and AI token budgets.

A far more scalable approach is Runtime Reachability Verification.

The Core Concept

Before spending time or AI tokens auditing application logic, verify a foundational invariant:

The Reachability Invariant: A vulnerability in a dependency cannot be exploited at runtime if the vulnerable method is never invoked during application execution.

By capturing real runtime dependency calls during automated tests or staging workloads, you produce an inventory of executed third-party calls (executed_dependency_calls.json). This artifact provides an immediate filter to determine if a reported vulnerability is genuinely exposed.

(For instructions on installing, building, and running the runtime call tracer, see the dep-method-tracer README.)

Step 1: Extract the Vulnerable Method from the CVE Description

Almost all Common Vulnerabilities and Exposures (CVE) descriptions, GitHub Security Advisories (GHSA), and National Vulnerability Database (NVD) entries explicitly name the affected function, class, or method.

Real-World Example: CVE-2024-37891 (urllib3)

Consider the advisory for CVE-2024-37891 (CVSS 7.1):

“When using urllib3, the Proxy-Authorization header is not stripped during cross-origin redirects. The issue resides in urllib3.util.request.make_headers and redirect handling within urllib3.connectionpool.HTTPConnectionPool.urlopen…”

From the CVE description, we immediately extract the exact vulnerable method signatures:

• urllib3.util.request.make_headers
• urllib3.connectionpool.HTTPConnectionPool.urlopen

Step 2: Cross-Reference Against the Captured Call Inventory

During runtime execution, the tracer records all executed third-party function and class method calls into an executed_dependency_calls.json file.

Triaging the CVE requires a simple lookup against that inventory:

grep -E "make_headers|urlopen" executed_dependency_calls.json

Step 3: The Two-Tier Decision Matrix

       [ SCA CVE Alert Detected ]
                   │
                   ▼
  Extract Vulnerable Method from CVE
                   │
                   ▼
  Is Method in executed_dependency_calls.json?
         │                          │
        NO                         YES
         │                          │
         ▼                          ▼
   [ UNREACHABLE ]             [ REACHABLE ]
  • Safe from runtime exploit  • Method is actively executed
  • De-prioritize alert        • Escalate to deep inspection:
  • ZERO AI tokens spent         - Trace input flow
                                 - Check taint conditions
                                 - Prompt AI with targeted context

Case A: The Method is NOT Called (Unreachable)

If the method does not appear in executed_dependency_calls.json:

// executed_dependency_calls.json
[
  "flask.app.Flask.__call__",
  "werkzeug.routing.Map.bind_to_environ"
]

• Security Verdict: The vulnerable method was never invoked. The vulnerability cannot be reached in this runtime workflow.
• Action: Mark the alert as Unreachable / Not Exploitable.
• Resource Savings: 0 developer hours and 0 AI tokens spent. You avoid reading hundreds of lines of code or sending massive repository contexts to an LLM for an alert that is dormant in your environment.

Case B: The Method IS Called (Reachable)

If the method is present in executed_dependency_calls.json:

// executed_dependency_calls.json
[
  "requests.sessions.Session.request",
  "urllib3.connectionpool.HTTPConnectionPool.urlopen",
  "urllib3.util.request.make_headers"
]

• Security Verdict: The method is actively executed in your application’s runtime call path.
• Action: Escalate to Deep Exploitability Analysis.

Now—and only now—is it worthwhile to invest engineering hours or LLM tokens. Because runtime execution is confirmed, you can pass targeted code context to an AI model or security reviewer to evaluate exploit preconditions:

Targeted AI Audit Prompt:
"We confirmed that `urllib3.util.request.make_headers` is actively executed at runtime via `app/services/http_client.py:42`.
Analyze the attached function to determine if user-controlled input can direct requests to cross-origin hosts while retaining sensitive headers:
[ATTACH TARGET SERVICE FUNCTION CODE]"

Why This Approach Saves Time and Tokens

1. Dramatic Token Reduction:
   In typical microservice architectures, 80% to 90% of flagged transitive dependencies are never invoked by application workflows. Filtering them out via runtime call matching eliminates the need to run costly LLM code audits on dead paths, reducing token consumption by up to 90%.

2. Eliminates Alert Fatigue:
   Development teams only receive triage requests for dependencies that actively execute, keeping developer trust and velocity high.

3. High-Precision AI Context:
   When an alert is confirmed reachable, you don’t need to dump entire code repositories into an LLM prompt. You can supply only the precise functions and callers connecting to the vulnerable method.

Checklist for Reviewers & Automated Pipelines

• Has the specific vulnerable method name or symbol been extracted from the CVE/GHSA advisory description?
• Has the test suite or staging environment generated an executed_dependency_calls.json call inventory?
• Is the vulnerable method present in the captured call inventory?
• If absent: Has the alert been classified as “Unreachable” without spending manual review or AI tokens?
• If present: Has the relevant entry point and call chain been extracted for targeted human or AI taint analysis?