01 / GRANULARITY
Declarations overstate the scope
A dependency may select a fixed version. Even when a vulnerable version is present, its code may never be imported or its vulnerable functions called.
DECLARED→REACHABLE
Vulnerability Propagation Scoring System
VPSS
Follow the calls
Measure the impact
How far does one vulnerability travel? VPSS moves from declared dependencies to function calls, traces propagation across an ecosystem, and measures impact through breadth, depth, and snapshots in time.
CALL-GRAPH ANALYSIS / JAVA MAVEN / DYNAMIC 0–10 SCORE
01 / DEPENDENCY ≠ REACHABILITYMETHOD SCHEMATIC
↗
ASE 2025Ecosystem scale, call-graph detail
100
Real vulnerabilities evaluated
660K P
Projects in the graph, approx.
15M PV
Maven releases, approx.
01 / WHY PROPAGATION MATTERS
A dependency is a clue
A call path is evidence
Supply-chain impact depends on the versions selected, the code actually used, and the dependencies downstream software retains over time.
02 / SCALE
Fine detail across an ecosystem
Building a call graph for every release is expensive. A project-level graph narrows the search, then hierarchical pruning reserves fine analysis for the remaining candidates.
→→→MULTI-HOP IMPACT
03 / TIME
One vulnerability, evolving impact
Severity and propagation impact are different dimensions. Patch adoption, retained dependencies, and ecosystem growth change the snapshot that VPSS measures.
VPSS(t)
02 / FOLLOW THE PATH
From dependency candidates
to explainable impact
Prune candidates and watch a worklist handle joins and cycles in small examples. Then explore the score using recorded snapshot data. The browser runs no live Maven analysis.
VPSS / PROPAGATION WORKBENCHINTERACTIVE DEMO / OFFLINE SNAPSHOTS
HIERARCHICAL PRUNING / SIX DOWNSTREAM CANDIDATES
← Scroll inside the graph · Select a node to inspect evidence →
Vulnerable rootRetained pathPruned candidate
6 / 6Downstream candidates / declarations only
Retained means passing the current filter, not proven exploitability. This example has one release per project; the paper tracks projects (P) and releases (PV) separately.
WORKLIST / REVISIT ONLY WHEN STATE CHANGES
← Scroll inside the graph to inspect joins and cycles →
QUEUE →
A separate four-project example uses finite target-function sets to demonstrate joins and cycles. Its counts are independent of the preceding six-candidate graph.
IMPACT EXPLORER / RECORDED SNAPSHOT INPUTS
PBF / BREADTH
PDF / DEPTH
Start from a recorded CVE-2016-5393 snapshot, then adjust the inputs to explore how breadth and depth affect the score. Edits create a hypothetical scenario. Release counts stay at least as large as project counts, and average depth cannot exceed maximum depth.
03 / UNDER THE HOOD
Trace impact with call evidence
Measure it with graph structure
Vulnerability intelligence, fixing patches, and dependency metadata become affected projects and releases, propagation paths, and a VPSS score for a chosen snapshot.
I / HIERARCHICAL WORKLIST ANALYSIS
Narrow the scope before building call graphs
A project-level dependency graph discovers candidates. Patches generate vulnerable-function candidates; an LLM filters irrelevant modifications and gives reasons for manual verification. Version, import, and call-graph pruning refine the scope, while a worklist tracks new state to a fixed point.
P / PROJECTGroupId:ArtifactId
Project graph narrows queries
Project graph narrows queries
PV / RELEASEPlus Version
Resolve affected releases
Resolve affected releases
TF → EPTargets to entry points
Link calls across projects
Link calls across projects
Static call graphs and version intelligence have accuracy limits. Reflection, dynamic loading, and incomplete patches can affect results. Call reachability is not successful exploitation. Sources: §III, §VI-A.
II / GRAPH-AWARE DYNAMIC SCORING
Breadth, depth, and a snapshot in time
Breadth combines affected shares of direct and transitive projects and releases, then applies logarithmic scaling. Depth combines maximum and average path length. Their product is mapped to 0–10 by an exponential function.
X = (Pdir / Ptotal, Ptrans / Ptotal,
PVdir / PVtotal, PVtrans / PVtotal)
PBF = ln(1 + γ · W Xᵀ)
PDF = 1 + (Lmax + Lavg) / (2Lnorm)
VPSS = 10(1 − exp(−PBF · PDF / k))
PVdir / PVtotal, PVtrans / PVtotal)
PBF = ln(1 + γ · W Xᵀ)
PDF = 1 + (Lmax + Lavg) / (2Lnorm)
VPSS = 10(1 − exp(−PBF · PDF / k))
Empirically chosen weights and scaling parameters affect score sensitivity. Time evolution reflects changing snapshots and need not decline monotonically. Sources: §III-E, §V-C, §VI-C.
04 / EVIDENCE FROM THE PAPER
From broad dependencies
to call-level impact
Ecosystem-wide evaluation of 100 real Maven vulnerabilities. Select a stage to inspect average direct and transitive candidate counts. These are historical measurements from Figure 6.
99.2%Average PV pruning
97.8% for projects (P)
97.8% for projects (P)
Source: §V-B / Figure 6
MCR index snapshot: 2024-12-26
Pruning ratios describe scope reduction, not precision or recall.
1.5 hMedian analysis time per CVE
5.2 hMean / excludes JAR downloads
Each vulnerability was analyzed independently from scratch. Times range from 1.2 seconds to 54 hours under the paper’s dataset and setup.
Average candidates per vulnerability
Linear scale / each row normalized to its own initial value / P and PV tracked separately
The paper did not measure initial maximum or average path lengths because of the cost. Path statistics at v1, v2, and v3 compare already-pruned graphs.
Inspect Figure 6 and the setup ↗CASE STUDY / CVE-2016-5393
Impact can persist
long after a fix appears
A vulnerability in Hadoop Common directly affects 228 projects at t₀ and reaches another 154 transitively. The paper reports a maximum path length of 7 across Hadoop and Hive components. Across 24 observations, VPSS declines slowly from 7.35 to 6.86. Affected release counts grow, while ecosystem growth reduces their relative share.
Sources: §V-D / Figure 8 and repository vpss_stats records
t₀ is NVD disclosure; t₂₃ is 23 intervals of 30 days later (690 days). Every point is a recorded sample; lines only connect samples.
7.35High propagation impact
05 / GO TO THE SOURCE
Propagation-Based Vulnerability Impact Assessment for Software Supply Chains
40th IEEE/ACM International Conference on Automated Software Engineering · ASE 2025 · pp. 65–77
Read the paper PDF / 13 PAGES ↗Code & datasets GITHUB / OPEN SOURCE ↗Presentation slides ASE 2025 ↗Publication page IEEE / DOI ↗Research poster ASE 2025 ↗
@inproceedings{ruan2025vpss,
title={Propagation-Based Vulnerability Impact Assessment for Software Supply Chains},
author={Ruan, Bonan and Lin, Zhiwei and Liu, Jiahao and Zhang, Chuqi and Ji, Kaihang and Liang, Zhenkai},
booktitle={Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering},
pages={65--77},
year={2025},
doi={10.1109/ASE63991.2025.00014}
}