Use case · Vulnerability Prioritization for Server Applications
Prioritize vulnerabilities with runtime evidence
Your vulnerability backlog needs priorities. Raven shows which libraries are loaded, which execute and whether a vulnerable function ran inside your server applications. Give your team runtime evidence to decide what to investigate and fix first.
SERVER APPLICATION · billing-api
OBSERVATION WINDOW · 30 DAYS
XML-CORE 3.2
parse()
validate()
resolveEntity() ← CVE-mapped
serialize()
AUTH-LIB
1.9
HTTP-CORE
5.1
PRESENT ON DISK
✓
component exists
LOADED IN MEMORY
✓
process loaded it
LIBRARY EXECUTED
✓
code in the library ran
VULNERABLE FUNCTION EXECUTED
the function mapped to the CVE ran
→ investigate first
LAYERS OF EVIDENCE · ILLUSTRATIVE RUNTIME EVIDENCE
/ 02 — SCENARIOS
Know which vulnerable code actually runs.
SCENARIO A
Same severity. Different runtime evidence.
Two findings carry a critical severity score. One library has no observed execution; the other's vulnerable function has run. Use that difference to guide investigation, alongside exposure and business impact.
SCENARIO B
The library runs. Does the vulnerable function?
A dependency may perform a routine task without invoking the function associated with a CVE. Look at function-level evidence before treating every finding in that library as the same priority.
/ 03 — MECHANISM
Turn runtime observations into a clearer remediation queue.
REMEDIATION QUEUE — RUNTIME CONTEXT
FINDING A
·
xml-core 3.2
·
critical
INVESTIGATE FIRST
vulnerable function executed · billing-api · window 30d
FINDING B
·
auth-lib 1.9
·
critical
REVIEW WITH EXPOSURE CONTEXT
no observed execution in window · consider exploit conditions and impact
handoff:
workload · library · function evidence
✓
ILLUSTRATIVE RUNTIME EVIDENCE
1
Locate the component
See where a vulnerable library version is present and which application loads it.
2
Check what executed
Distinguish library loading from execution, then inspect whether the function associated with the vulnerability was observed running.
3
Act on the evidence
Combine runtime activity with severity, exploit conditions and service importance. Give engineering a finding tied to the affected workload and code.
/ 04 — EVIDENCE
See the reason behind the priority.
Open a finding and follow the evidence: affected library, server workload and observed function activity. Give engineering a concrete explanation of why this issue needs attention, with the observation window visible.
3
2
1
1
The affected code
Library, version and vulnerability identifier for this finding.
2
What actually executed
The mapped vulnerable function and its recorded execution status.
3
Where and when
The affected workload and covered observation period.
Give engineering a clearer place to start.
Focus vulnerability investigations with evidence from running applications.
Take a finding to engineering with workload and library context.
Revisit priorities as application behavior and deployments change.
/ 06 — FAQ
Questions before you reprioritize
What does "not observed" mean?
The function was not seen executing during the covered observation window. Rare or newly triggered paths may still execute, so consider exposure, exploit conditions and business impact when setting priority.
Does function execution confirm an exploit?
Execution confirms code use. Exploitability also depends on the vulnerability's conditions and application context. Use validation where needed; an execution observation by itself is not an exploit test.
What if patching takes time?
For covered exploit behavior, Raven prevention can provide protection while remediation proceeds. Validate the relevant policy and workload; keep protection status separate from execution evidence.
Give every priority a reason.
See the vulnerable code your server applications use, and bring that evidence into the next remediation decision.