PaperlayerView exact revision on arXiv

Source-linked AI summary

CAPE - Context-Aware Prioritization Engine for Vulnerability Scoring and Management

Rakesh Podder, Viktoria Koscinski, Indrajit Ray

arXiv:2610.13071v1cs.CRcs.SE

TL;DR

Prioritizing vulnerability fixes is difficult when alert lists are large and dependency updates can lag, while generic scores omit deployment context. CAPE enriches scanner findings with deployment-specific evidence and ranks them using a regime-adaptive score. In its evaluation, CAPE lowered the mean rank of the first confirmed-exploitable CVE by 79.8% against the baselines, though ranking metrics do not measure realized risk reduction.

  • Problem

    How can vulnerability fixes be prioritized amid large alert lists and delayed dependency updates while accounting for deployment context?

    Source: §I · pp. 1–2

  • Method

    CAPE enriches scanner-reported CVEs with deployment-specific evidence and combines it in a regime-adaptive AHP scoring model.

    Source: §I · p. 2

  • Results

    79.8% lower mean rank of the first confirmed-exploitable CVE (3.4 vs. 16.9; median 1 vs. 7), with AUROC 0.908 vs. 0.454 and NDCG@10 0.652 vs. 0.227 for CVSS.

    Source: §I · p. 2

  • Takeaways & Limitations

    The conclusion is that deployment-specific code evidence provides more accurate remediation guidance than context-free severity scoring alone.

    Source: §VIII · p. 11

    MRFTP and NDCG@10 measure ranking position, not realized risk reduction, which also depends on patch availability, developer capacity, and deployment timelines.

    Source: §VII · p. 10

Abstract

from arXiv · show

Vulnerability patching is critical for safeguarding an enterprise's software ecosystem from cyber attacks. However, patching requires adequate preparation for potential system downtime and for unforeseen effects of the patched software on a live system. Thus, effective risk mitigation requires prioritization strategies that explicitly account for the operational context of the affected software. While vulnerability prioritization based on Common Vulnerability Scoring System (CVSS), Exploit Prediction Scoring System (EPSS) and CISA Known Exploited Vulnerabilities (KEV) catalog, can help, their differing goals and methodologies often lead to inconsistent, context-unaware decisions resulting in mis-allocated remediation efforts. In this work, we present the Context-Aware Prioritization Engine (CAPE), a vulnerability analysis framework that enriches each vulnerability scanner report of vulnerabilities (CVEs) with deployment-specific evidence. This evidence is used to perform vulnerability reachability, centrality, and exploitability analysis, producing a ranked priority score for the effective distribution of remediation effort. We evaluate CAPE on 30 open-source agentic applications comprising 6,138 scanner-reported CVEs. Our evaluation shows that a significant majority of CVEs are not reachable and exploitable which results in significant disparities between CAPE and context-free baselines - the CVSS, EPSS, and KEV. It also shows that CAPE consistently surfaces confirmed-exploitable CVEs at higher priority than all baselines, demonstrating that context-aware analysis provides substantially more accurate remediation guidance than context-free severity scoring alone.

I. INTRODUCTION

CAPE adds deployment-specific evidence to vulnerability prioritization, addressing context-blind scanner results and generic severity scores. On 30 projects, it reports stronger ranking of confirmed-exploitable CVEs than the listed baselines.

I. INTRODUCTION

  • Scanner lists can contain hundreds of CVEs, while pinned dependencies and breaking changes can leave known-vulnerable versions in production after patches become available.A cited study of npm packages found a median of more than four months between vulnerability disclosure and a consuming project updating the affected dependency.Source: §I · p. 1
  • Scanner matching by component and version does not reveal whether vulnerable code is deployed or reachable, and CVSS lacks application-specific operational evidence.These limitations make scanner-reported findings with different operational risks appear alike.Source: §I · p. 1
  • Prior context-aware systems use organizational, infrastructure, or service-topology information, while CAPE analyzes deployed artifacts at source-code level.The paper identifies the conjunction of entry-point reachability, artifact-level bug or patch signatures, and graph centrality within one scoring model as absent from prior systems.Source: §I · p. 2
  • CAPE combines reachability, code-level evidence, graph centrality, and a regime-adaptive AHP scoring model to rank scanner-reported CVEs.The model marginalizes structurally absent evidence dimensions while preserving score monotonicity across deployment evidence and VEX verdicts.Source: §I · p. 2
  • 43.3% of 6,138 scanner-reported CVEs across 30 projects are statically unreachable; the share reaches 76.1% in the most extreme case and averages 53.2% for TypeScript/JavaScript projects.The paper describes these findings as context-aware false positives.Source: §I · p. 2
  • 79.8% lower mean rank of the first confirmed-exploitable CVE (3.4 vs. 16.9; median 1 vs. 7), with AUROC 0.908 vs. 0.454 and NDCG@10 0.652 vs. 0.227 for CVSS.Evaluation covered 30 open-source applications.Source: §I · p. 2

II. BACKGROUND & RELATED WORK

Prior vulnerability scoring and context-aware approaches leave deployment-specific source-code evidence outside prioritization. The formal problem is to rank scanner findings by operational exploitability rather than generic severity.

II. BACKGROUND & RELATED WORK

  • Existing scoring uses CVSS, EPSS, or KEV, but these signals do not consistently capture exploitation risk or deployment-specific source-code evidence.EPSS provides 30-day exploitation predictions but clusters near zero for recently published CVEs; KEV covers only about 1.4% of CVEs.Source: §II · p. 2
  • Prior systems add organizational, infrastructure, service-topology, or telemetry context, but none combines entry-point reachability, artifact-level code evidence, and component centrality.The cited Java and Maven reachability studies did not extend reachability to prioritization or patch-state confirmation.Source: §II · pp. 2–3

III. FORMAL PROBLEM STATEMENT

  • Across 30 projects, 43.3% of 6,138 scanner findings are statically unreachable, but raw scanner output does not distinguish them from exploitable findings.The formal problem defines a priority function that ranks scanner findings to approximate which vulnerability should be remediated first.Source: §III · p. 3
  • CVSS-only prioritization can rank an unreachable vulnerability above a reachable, confirmed-bugged one because it ignores deployment-specific evidence.Table I compares approaches using full, partial, and absent coverage indicators for prioritization capabilities.Source: §III · p. 3, Table I · p. 3

IV. THE CAPE ARCHITECTURE

CAPE processes scanner findings through evidence collection and synthesis before scoring them. It builds a deployment-representative SBOM locally, then normalizes and enriches the resulting CVE list.

IV. THE CAPE ARCHITECTURE

  • CAPE's seven stages transform scanner CVEs into a context-aware ranking, with S3–S6 collecting independent evidence in parallel before S7 synthesizes their signals for scoring.The architecture figure states that S7 requires all four stage signals or data, and the scoring model requires S7.Source: §IV · p. 3, Figure 1 · p. 4

A. Local Build and SBOM Generation

  • Local builds produce an SBOM from the installed dependency tree at resolved versions, avoiding version divergence and platform-variant findings observed with other SBOM sources.In OpenClaw, a local build installed one of 23 @esbuild variants, making 22 findings unreachable false positives; lock-file-only installs diverged in 6 of 12 npm projects.Source: A. Local Build and SBOM Generation · pp. 3–4

B. Stages S1–S2: Normalisation and Enrichment

  • S1 collapses advisory aliases while preserving distinct CVEs, and S2 adds OSV metadata, EPSS probability, and KEV membership to each finding.CAPE uses EPSS and KEV as external evaluation baselines and CVSS as an external severity signal in its evidence dimension.Source: B. Stages S1–S2: Normalisation and… · p. 4
  • In an OpenClaw example, the highest-CVSS finding sits at the 66.4th EPSS percentile, while another has an 80.1 percentile and no OSV record.The paper notes that neither signal nor scoring method alone is sufficient for remediation strategies.Source: B. Stages S1–S2: Normalisation and… · p. 4

C. Stage S3: Code Evidence Collection

Stage S3 checks whether fix-commit code signatures occur in the installed artifact, providing evidence about buggy or patched code beyond scanner version matching.

C. Stage S3: Code Evidence Collection

  • S3 searches installed artifacts for pre-fix buggy lines and post-fix patched lines from vulnerability-fix commits, checking whether relevant code is physically present.The process obtains fix-commit URLs from NVD and OSV, prioritizing NVD Patch-tagged URLs.Source: C. Stage S3: Code Evidence Collection · p. 4
  • S3 assigns BG, NB, NF, or NC verdicts, with a single confirmed-buggy file taking precedence; absent code evidence does not discard the CVE from later analysis.When no commit is found, code evidence is structurally absent and its scoring weight is redistributed across remaining dimensions.Source: C. Stage S3: Code Evidence Collection · p. 4
  • In the Handlebars 4.7.8 example, buggy code remains in the installed artifact while the patched guard is absent.The example identifies the surviving code in runtime.js and javascript-compiler.js.Source: C. Stage S3: Code Evidence Collection · pp. 4–5, Figure 2 · p. 4

D. Stage S4: Call Graph Construction

CAPE builds a typed call graph and uses a reachability skeleton with multi-source BFS to assess whether vulnerable components lie on paths from application entry points. In OpenClaw, this analysis found 14 of 161 CVEs statically unreachable, while unreachable findings continue through later analysis because static analysis can miss dynamic dispatch.

D. Stage S4: Call Graph Construction

  • S4 constructs a typed directed call graph from internal source parsing, external package parsing, and import resolution, with unresolved imports handled by a resolution cascade.The described graph uses multiple edge types, including CALLS, IMPORTS, DEPENDS_ON, and CONTAINS.Source: D. Stage S4: Call Graph Construction · p. 5
  • OpenClaw’s graph contained 316,491 nodes and 1,587,771 typed directed edges across nine relation types, with CALLS the largest relation at 934,891 edges.IMPORTS had 328,135 edges and CONTAINS had 280,832.Source: D. Stage S4: Call Graph Construction · p. 5

E. Stage S5: Reachability Analysis

  • S5 removes CONTAINS edges and test-file nodes to form a runtime-traversable reachability skeleton, avoiding false paths through package membership and test harnesses.It matches each finding’s package to call-graph nodes, then uses multi-source BFS from application entry points.Source: E. Stage S5: Reachability Analysis · pp. 5–6
  • For OpenClaw, S5 identified one entry node; among 161 CVEs, 147 (91.3%) were statically reachable from an entry point, while 14 (8.7%) were not.Source: E. Stage S5: Reachability Analysis · p. 6
  • Unreachable CVEs continue to S6 because static analysis can miss dynamic dispatch, and discarding them risks losing genuine vulnerabilities.S5 assigns REACHABLE, NOT_REACHABLE, or NO_CALLGRAPH verdicts.Source: E. Stage S5: Reachability Analysis · p. 6

F. Stage S6: Centrality Analysis

CAPE measures vulnerable components’ structural influence at function and file granularities, then selects the relevant centrality level according to the assigned regime. Its exploitability analysis combines SBOM/code presence with code-evidence verdicts to assign each CVE a regime.

F. Stage S6: Centrality Analysis

  • CAPE computes nine centrality metrics per component and, where available, patch file, but only impact radius, hub score, and eigenvector centrality enter the priority score.Across 30 cases, the remaining six metrics added no ranking signal beyond this triple.Source: F. Stage S6: Centrality Analysis · p. 6
  • For R4 and R5, CAPE selects file-level centrality; otherwise it uses component-level values, with max-min normalization applied at each level.The function graph has 162,448 nodes and 1,587,771 edges for OpenClaw; the file graph has 54,972 nodes.Source: F. Stage S6: Centrality Analysis · p. 6
  • OpenClaw’s handlebars reached hub = 0.687 at affected-file level, while reachable vite and undici retained component-level centrality despite having no code evidence; fast-xml-parser had impact radius 0.0.This allows structural influence to be scored even when S3 finds no affected files.Source: F. Stage S6: Centrality Analysis · p. 6

G. Stage S7: Exploitability Analysis

  • S7 assigns each CVE a regime from SBOM/code presence and S3 code-evidence verdicts; OpenClaw’s R2 regime dominated at 98 of 161 CVEs (60.9%).R2 indicates present components without a retrieved git commit, so CAPE still reports priority evidence while requiring manual investigation.Source: G. Stage S7: Exploitability Analysis · pp. 6–7

V. PRIORITY SCORING MODEL

CAPE combines normalized exploitability, reachability, code-evidence, and centrality dimensions, redistributing weights when a dimension is structurally absent. Its AHP prior sets baseline weights, while regime-aware selection determines which evidence is available for scoring.

A. Evidence Dimensions

  • CAPE’s four normalized evidence dimensions are CVSS-based exploitability, reachability, code evidence, and centrality, with unavailable evidence treated as structurally absent.A missing call graph maps reachability to 0.5 rather than treating it as evidence of unreachability.Source: A. Evidence Dimensions · p. 7
  • Centrality combines impact radius, hub score, and eigenvector centrality with weights 0.5, 0.3, and 0.2, respectively.The metrics are min-max normalized within each case, with affected-file maxima used for R4 and R5.Source: A. Evidence Dimensions · p. 7
  • CAPE’s centrality weights achieved mean NDCG@10 of 0.680 and AUROC of 0.914 across 30 cases.For handlebars 4.7.8, the file-level centrality dimension was φ4=0.820.Source: A. Evidence Dimensions · p. 7

B. AHP Weight Prior and Redistribution

  • The baseline AHP prior is (0.318, 0.261, 0.227, 0.193), and structurally absent dimensions redistribute their weight proportionally across the remaining defined dimensions.R2 loses φ3 and uses weights (0.412, 0.338, NaN, 0.250), whereas R3–R5 retain the full prior.Source: B. AHP Weight Prior and Redistribution · p. 7

C. Priority Score and Gates

CAPE aggregates available evidence dimensions into a base score and applies ordered gates to obtain the final priority score. The evaluation uses 30 software projects and relevance grades derived from regime and reachability rather than analyst labels.

C. Priority Score and Gates

  • CAPE applies gates in the fixed order G1→G2→G3 after aggregating available evidence dimensions into a base score.The gate threshold was selected by grid search to optimize mean NDCG@10 across the 30-case corpus.Source: C. Priority Score and Gates · p. 8

A. Corpus and Experimental Setup

  • The evaluation corpus spans 30 Python, TypeScript, and JavaScript projects with 6,138 scanner-reported CVEs, and compares CAPE with CVSS, EPSS, EPSS-pct, and KEV rankers.Projects were built locally, their SBOMs generated with Syft, and scanned with Grype.Source: A. Corpus and Experimental Setup · p. 8
  • Relevance grades are based on regime and reachability, with grade 3 reserved for buggy code that is reachable and defined as confirmed-exploitable.The grading scheme is independent of φ1 and φ4, preventing self-evaluation against those dimensions.Source: A. Corpus and Experimental Setup · p. 8
  • Evaluation measures include the fraction of statically unreachable CVEs, the rank of the first confirmed-exploitable CVE, NDCG@k, AUROC, and Kendall τb.A lower rank of the first confirmed-exploitable CVE is better; if none exists, the metric uses sentinel n+1.Source: A. Corpus and Experimental Setup · pp. 8–9

B. RQ1: Scanner False-Positive Rate

Across the evaluated projects, many scanner-reported CVEs were statically unreachable, while CAPE ranked confirmed-exploitable CVEs and high-evidence findings ahead of context-free baselines more consistently.

B. RQ1: Scanner False-Positive Rate

  • 43.3% of scanner-reported CVEs were statically unreachable; rates averaged 53.1% in TypeScript/JavaScript and 27.4% in Python, reaching 76.1% in C23.C23 had 530 of 696 CVEs classified as unreachable.Source: B. RQ1: Scanner False-Positive Rate · p. 9

C. RQ2: Rank of First Confirmed-Exploitable CVE

  • Across 19 outright wins, mean MRFTP fell from 23.4 (CVSS) to 3.3 (CAPE), an 86.0% reduction; against CVSS, CAPE won 24, tied 3, and lost 2.In 11 of the 19 outright wins, CAPE's MRFTP was 1.Source: Table VI · p. 9, C. RQ2: Rank of First… · p. 9

D. RQ3: Ranking Quality

E. RQ4: Weight Sensitivity and Centrality Metric Selection

CAPE's selected centrality blend improved ranking metrics over its baseline, while the evaluation has scope and ground-truth limitations. The conclusion reports a lower mean rank for the first confirmed-exploitable CVE than CVSS.

E. RQ4: Weight Sensitivity and Centrality Metric Selection

  • Among 969 valid weight vectors tested on C03, optima concentrated weight on code evidence, with multiple vectors reaching NDCG@10 = 1.000.C03 spans all four active regimes, R2–R5.Source: E. RQ4: Weight Sensitivity and… · p. 10
  • Selection_3a raised NDCG@10 from 0.477 to 0.653 and AUROC from 0.842 to 0.911, beating the baseline in 21/30 and 26/30 cases, respectively.The blend is 0.5 · ir+0.3 · hub+0.2 · ev.Source: E. RQ4: Weight Sensitivity and… · p. 10

VII. THREATS TO VALIDITY

  • The internal evaluation uses reachable, confirmed-buggy CVEs as ground truth despite no analyst-labeled dataset; only Python, TypeScript, and JavaScript are evaluated.Whether acting on CAPE's rankings reduces real-world risk depends on factors outside the study, including patch availability, developer capacity, and deployment timelines.Source: §VII · p. 10

VIII. CONCLUSION

  • CAPE reduced the mean rank of the first confirmed-exploitable CVE by 86.0% compared with CVSS, and the authors identify extending language coverage as future work.The conclusion attributes more accurate remediation guidance to deployment-specific code evidence.Source: §VIII · pp. 10–11

APPENDIX A ONE-AT-A-TIME WEIGHT SENSITIVITY (30 CASES)

Across the appendices, CAPE's ranking is broadly stable to weight perturbations, exploitability and code evidence contribute ranking signal, and the deployed reachability-penalty multiplier lies on a stable quality plateau.

APPENDIX A ONE-AT-A-TIME WEIGHT SENSITIVITY (30 CASES)

  • Median rankings remained stable (τb ≥0.93), but halving φ1 or φ4 pushed more than a third of cases below τb = 0.90, with tails reaching 0.83 and 0.76.The analysis perturbs each prior weight by 0.5 or 1.5, renormalizes the remaining weights, and compares rankings with the unperturbed ranking.Source: Figure 4 · p. 12, Appendix A · pp. 12–13

APPENDIX B DROP-ONE-DIMENSION ABLATION (30 CASES)

  • Dropping exploitability or code evidence degraded both metrics (∆AUROC −0.066 and −0.065, respectively), while reachability was metric-neutral and blast-rating was near-neutral on average.Reachability acts primarily through the G2 gate; blast-rating still contributes to one-at-a-time tail behavior.Source: Figure 5 · p. 13, Appendix B · p. 13

APPENDIX C REACHABILITY-PENALTY (α) SENSITIVITY

  • Corpus-mean ranking quality rose as α demoted unreachable findings, then plateaued through the deployed α = 0.40, indicating a stable shoulder rather than a sharp optimum.For unreachable findings in R3–R5, the G2 gate multiplies the score by α rather than zeroing it.Source: Figure 6 · p. 13, Appendix C · p. 13

APPENDIX D WEIGHT GRID SEARCH

The appendices test CAPE’s ranking across cutoffs and cases, justify its weight and centrality choices, and make its scoring process inspectable on a running example.

APPENDIX D WEIGHT GRID SEARCH

  • The AHP prior lies near the top of the weight-grid distribution, and the degenerate optimum supports retaining it rather than fitting weights to this corpus.Many distinct weight vectors tie for the maximum, so there is no unique data-fitted optimum.Source: Appendix D · p. 13, Figure 7 · p. 14

APPENDIX E RANKING-QUALITY CURVES

  • Across every cutoff k, CAPE dominates CVSS and EPSS, while pooled ROC shows stronger separation of relevant findings (grade ≥2) from irrelevant findings than CVSS.Source: Figure 8 · p. 14, Appendix E · p. 14

APPENDIX F CENTRALITY-VARIANT STUDY

APPENDIX G EVIDENCE DIMENSIONS ON THE RUNNING EXAMPLE

  • In case_003, top-40 φ1–φ4 inputs and top-20 weighted contributions expose how dimensions and gate adjustments, including R5 and G2, shape each final score.The figures provide a per-finding view of the evidence inputs, weighted contributions, and gate-adjusted scores.Source: Appendix G · pp. 14–15, Figure 11 · p. 15, Figure 12 · p. 15
  • In all 30 cases, CAPE AUROC exceeds 0.5 and both CVSS and EPSS, showing the advantage is not confined to corpus averages.Source: Figure 13 · p. 15, Appendix G · p. 15
Loading 2610.13071v1…