Application security teams are overwhelmed. Not because they don’t know vulnerabilities matter, but because it’s getting harder every year to tell which ones actually do.
In 2024 alone, more than 48,000 new CVEs were disclosed. For AppSec teams, that number isn’t just impressive. It’s exhausting. Every new CVE triggers triage, analysis, and often a conversation with developers, even when the real-world risk is unclear.
Most tools still answer the same basic question: Is this dependency present? But that’s rarely the question developers ask back. They want to know: Is this vulnerable code actually running?
Without a clear answer, trust breaks down. Security escalates based on severity scores. Developers push back because the risk feels theoretical. Meanwhile, truly exploitable issues compete for attention with thousands of findings that will never be triggered in production.
Why Proving Exploitability Is Still So Hard
For years, AppSec has relied on static and build-time techniques to manage risk. SCA, SAST, and reachability analysis all attempt to predict what might be exploitable before an application runs.
The problem is that modern applications don’t behave like static diagrams. What runs in production depends on frameworks, configuration, feature flags, dynamic loading, and real user behavior. Code can exist in a binary and still never execute.
Reachability analysis helps narrow the field, but it still relies on inference. It suggests that a vulnerable function could be called, not that it is being called. That gap between possibility and reality is where AppSec teams lose credibility and time.
Introducing Runtime Call Stacks for CVEs
To close that gap, Oligo now provides runtime call stacks for CVEs as part of Oligo Runtime Vulnerability Management.
When Oligo observes a known vulnerable function actually executing at runtime, it surfaces the full call stack that led to that execution. This information is available directly in the CVE side panel and can also be accessed through the Oligo API.
Instead of debating likelihood, AppSec teams can now point to evidence. The vulnerable code didn’t just exist. It ran.
What a Call Stack Changes in Practice
A runtime call stack answers the questions that usually slow everything down:
- Is the vulnerable function really being invoked?
- What else is invoked?
- Which service or application path is responsible?
For developers, this level of clarity changes the conversation completely. It’s no longer about fixing something just in case. It’s about fixing something you can see running.
That shared understanding removes friction. Remediation happens faster because the evidence is concrete, not theoretical.
Why Oligo Can Surface This Evidence at Scale
Showing call stacks sounds simple. In practice, it requires deep visibility into how applications behave while they run.
Oligo Deep App Inspection observes code execution, OS processes, and AI behavior - all non-intrusively, without needing access to source code. Deep App Inspection is what powers the detection of vulnerable functions that are loaded and executed, not just when a vulnerable package is present.
This runtime depth is why Oligo identifies far more vulnerable functions than traditional tools. Call stacks only appear when there is definitive proof that vulnerable code has executed, not when risk is inferred.
How This Improves Everyday AppSec Work
With runtime call stacks, AppSec teams can focus their time where it matters most:
- Prioritizing vulnerabilities that actually execute in production
- Reducing noise from dormant or unused code paths
- Giving developers clear, actionable context
- Automating workflows through API access
Instead of acting as the messenger for endless alerts, AppSec becomes a trusted source of high-confidence insight.
From Visibility to Proof
Knowing what exists in your environment is useful. Knowing what runs is better. Proving what is exploitable is what finally drives action.
By adding runtime call stacks directly into CVE workflows, Oligo helps AppSec teams move past debate and focus on reducing real risk. In a world of tens of thousands of new vulnerabilities every year, proof is what makes AppSec scalable.
.png)
.png)