HARP: Hierarchical Adaptive Ranking with Preference-Adaptive Fusion for Query-Based CVE Prioritization

HARP: Hierarchical Adaptive Ranking with Preference-Adaptive Fusion for Query-Based CVE Prioritization Haochen Liu* 1 , Zhengzhang Chen†2 , Haoyu Wang2 , Yanchi Liu2 , Jundong Li1 , Haifeng Chen2 1 University of Virginia 2 NEC Laboratories America sat2pv@virginia.edu, zchen@nec-labs.com, haoyu@nec-labs.com, yanchi@nec-labs.com, jundong@virginia.edu, Haifeng@nec-labs.com

arXiv:2608.19430v1 [cs.IR] 19 Aug 2026

Abstract Vulnerability prioritization is inherently preference dependent, since the same CVE can receive different remediation priority under different operational preference scenarios. Existing scoring systems and ranking methods typically assume a fixed criterion. In practice, organizations already operate under a preference scenario, but this preference is often implicit and difficult to express as a written prompt instruction, while triage queries usually do not encode it. Past validated triage cases under the current scenario are more readily available. We study query-based CVE prioritization in this setting and propose HARP, a graph-grounded multiview framework that ranks candidates from a natural-language query together with a support bank of historical labeled examples from the current preference scenario, without requiring an explicit textual summary of that scenario. HARP retrieves evidence from a vulnerability knowledge graph, scores candidates with policy-conditioned global, enterprise, and user views, and fits view-fusion weights from sampled supports. Experiments across three preference scenarios and multiple backbone LLMs show that HARP outperforms multiple baselines, expressing our method’s effectiveness.

1

Introduction

Modern software systems continuously accumulate vulnerabilities across large software ecosystems. With limited remediation resources, organizations must decide which CVEs (Common Vulnerabilities and Exposures) to remediate first. This prioritization process depends on multiple factors, including exploitability, affected products, deployment environment, patch availability, and user-facing exposure (Li and Paxson, 2017; de Smale et al., 2023). Existing vulnerability information such as CVSS, EPSS, CISA KEV, and SSVC (FIRST.Org, * Work done during an internship at NEC Labs America. †

Corresponding author.

Inc., 2019; Spring et al., 2021; Jacobs et al., 2023) provide useful signals about severity, exploitation likelihood, and remediation urgency, but they do not define a single universal prioritization strategy. In practice, ranking depends on the organization’s current preference scenario. The same CVEs may therefore require different rankings under different scenarios, even when the triage query looks similar. Existing vulnerability prioritization methods typically rely on fixed industrial signals (Allodi and Massacci, 2014; Sabottke et al., 2015; Bozorgi et al., 2010; Suciu et al., 2022; Wu et al., 2022), lexical matching or embedding-based retrieval ranking (Burges et al., 2005; Burges, 2010; Karpukhin et al., 2020; Khattab and Zaharia, 2020), or LLM prompting with optional retrieved evidence (Lewis et al., 2020). However, these approaches generally assume a fixed or explicitly specified ranking criterion, making them poorly suited when remediation priority depends on the real preference scenario. Recent parameter-efficient adaptation methods show that different model behaviors can be represented through lightweight specialized modules without full retraining (Houlsby et al., 2019; Hu et al., 2022). Related work on knowledge editing likewise studies localized parameter updates for modular behavior control (Meng et al., 2022, 2023; Wang et al., 2024b; Wu et al., 2024; Liu et al., 2025; Zhang et al., 2025, 2026). Although our focus is preference adaptation rather than factual knowledge editing, these lines of work motivate using policy-specific lightweight modules to capture different prioritization preferences while keeping a shared backbone frozen. The central challenge is that preference scenarios are often implicit and complex. Although an organization already operates under a remediation objective, that objective is difficult to express as a written preference description for prompting or as a clean supervision label for training. Queries likewise usually omit such a description. As a result,

Ranking: Traditional

Which CVEs should be remediated first? CVE-A: high severity, no exploit, no patch, … CVE-B: medium severity, exploited, no patch, … CVE-C: low severity, no exploit, patch available , …

Ranking via a fixed view

Scenario 1: Focus more Scenario 2: Focus more on general importance on exploit

Scenario 3: Focus more on patch

Desired Ranking:

Desired Ranking:

Desired Ranking:

CVE-A

CVE-B

CVE-C

CVE-B

CVE-A

CVE-A

CVE-C

CVE-C

CVE-B

CVE-A Produce one ranking for CVE-B all contexts CVE-C Preference mismatch for most scenarios!

The same query and CVEs may require different rankings under different implicit preference scenarios.

Figure 1: Motivating example of preference-dependent CVE prioritization. The same query and candidate CVEs can require different rankings under different preference scenarios. Fixed scoring or single-prompt ranking produces CVE-C CVE-A CVE-B one ordering and may fail to match the current scenario’s remediation preference. CVE-B

CVE-A

CVE-A

methods that require an explicit textual preference CVE-C CVE-C scenario are often impractical. In contrast, past validated triage cases under the current scenario are typically available and can serve as concrete evidence of the desired ranking tendency. Moreover, a single fixed scoring view is usually insufficient: remediation decisions jointly depend on complementary evidence such as global severity and exploitability, enterprise exposure and patch feasibility, and different preference scenarios require different balances among these factors. This motivates a multi-view formulation rather than ranking under one fixed criterion. Figure 1 illustrates this contrast between ranking with a fixed view and ranking under different preference scenarios. In this paper, we propose HARP, a Hierarchical Adaptive Ranking with Preference-Adaptive Fusion framework for query-based CVE Prioritization. HARP retrieves candidate CVEs and evidence from a vulnerability knowledge graph, applies policy-conditioned multi-view scoring, and combines view scores through adaptive fusion with Top-K consensus routing. HARP adapts to the current preference scenario through historical support examples, without requiring an explicit textual summary of that scenario. We construct a querybased CVE ranking benchmark with ground-truth rankings annotated by cybersecurity practitioners under three preference scenarios. These evaluation labels are independent of the policy-specific supervision used for adapter training, and each scenario is associated with its own bank of historical labeled examples, as detailed in Section 4. Although the policy templates and evaluation scenarios are motivated by common real-world remediation objectives, they were designed independently and serve different purposes: the former provide supervision for adapter training, whereas the latter define qualitative human evaluation criteria. Our contributions are summarized as follows: • We study query-based CVE prioritization un-

Ranking: der implicit preference scenarios and propose Ranking: 1. CVE-B 1. CVE-C HARP, which adapts ranking with policy2. CVE-A 2. CVE-A CVE-C 3. CVE-B conditioned multi-view scoring 3.and historical support-guided fusion without requiring a written preference description. • We construct a query-based CVE ranking benchmark with ground-truth rankings annotated by cybersecurity practitioners under three preference scenarios, together with separately designed policy-specific supervision for adapter training. • We conduct experiments showing that HARP consistently improves ranking quality over baselines across multiple backbone LLMs. CVE-B

2

Problem Formulation

We study query-based vulnerability prioritization in a graph-grounded setting. Let G = (V, E) denote a vulnerability knowledge graph, where nodes represent CVEs and related entities such as products, vendors, and weaknesses. Given a natural-language query q, the system constructs a query-specific candidate set C(q) = {c1 , c2 , . . . , cn } ⊆ V,

(1)

where each ci is a retrieved candidate CVE. The goal is to assign each candidate a score that reflects its remediation priority. Ranking depends on an existing preference scenario γ, corresponding to the organization’s current remediation objective. The same query and candidates may require different rankings under different γ. Because γ is typically implicit and is not provided as a written preference description in the query, we represent the current scenario by a support bank Bγ of previously labeled triage examples collected under that scenario and disjoint from the test instances. The ranking function is F (q, ci ; Bγ ),

(2)

where q is used for retrieval, policy selection, and view scoring, and Bγ provides historical preference supervision for view fusion. The system receives neither a textual preference description nor a scenario identity token, and it does not predict γ as an intermediate variable.

3

Method

To estimate the preference-dependent scoring function above, we propose HARP, a graph-grounded and preference-adaptive prioritization framework. As illustrated in Figure 2, HARP consists of four main stages: graph-grounded candidate construction, policy-conditioned multi-view scoring, support-bank-based Preference-adaptive fusion, and Top-K consensus routing. Given a query q and a support bank Bγ of past labeled examples from the current preference scenario, the system retrieves candidates from the knowledge graph, scores them under query-selected policies in each view, and fuses the normalized view scores using sampled supports from Bγ . This design adapts to the current scenario without requiring an explicit textual preference description. Policy-conditioned scoring adapts the scoring behavior within each view, while support-bank fusion adapts the view mixture using historical ranking supervision from Bγ . Details of graph construction are in Appendix A, and the support-bank protocol is in Appendix B. 3.1

Vulnerability Knowledge Graph Construction

We use an enriched vulnerability knowledge graph as the structured evidence source for retrieval and ranking. The base graph is built from CVE records with nodes for CVEs, products, vendors, weaknesses, and references (Høst et al., 2023), and is further enriched with exploit- and patch-related external signals. Details of graph construction and enrichment are provided in Appendix A. 3.2

Candidate Retrieval and Evidence Construction

Given the enriched graph G and a query q, we construct a query-specific candidate set and a shared candidate summary for downstream scoring. The candidate set is retrieved as C(q) = R(q, G),

(3)

where R denotes the graph-based retrieval operator. The query is first aligned with graph entities im-

plied by its content, such as products, vendors, or risk-related terms. Starting from these entities, the system traverses graph relations to collect relevant CVE nodes and forms the candidate set. We then construct a shared candidate summary for the retrieved candidates. For each candidate in C(q), we collect fields such as description, severity score, exploit signals, affected products, weakness category, vendor information, and references. These fields are organized into a structured input and summarized by an LLM: x(q) = LLMsum (C(q)).

(4)

The resulting representation x(q) summarizes the evidence of the candidate set. It is provided to the downstream scoring modules so that each CVE can be evaluated relative to the full candidate set rather than in isolation. 3.3

Policy-Conditioned Multi-View Scoring

Given the candidate feature summary x(q), HARP scores each candidate under multiple prioritization views. Because a single scoring rule is rarely sufficient across remediation objectives, we use policyspecific modules to control the scoring behavior within each view. We consider L prioritization views. In this work, the views correspond to global, enterprise, and userfacing views (L = 3). The global view captures general vulnerability risk, such as overall severity and exploitability; the enterprise view focuses on organizational relevance, such as affected products, exposure, and remediation feasibility; and the user-facing view captures end-user impact. This decomposition preserves complementary evidence rather than forcing all prioritization factors into a single scoring criterion. Within each view l, we define a policy set Πl = {πl,1 , πl,2 , . . . , πl,Kl },

(5)

where each policy πl,k represents a specific evaluation preference under that view. Each policy is implemented as a lightweight adapter module on a shared frozen backbone, rather than as a factual knowledge edit. The number of policies need not be equal across views: different views admit different meaningful prioritization trends. In our benchmark we use five global, four enterprise, and three user policies (Table 5); the overall framework remains modular and does not require these counts.

Enterprise

Candidate Construction Which CVEs should be Query remediated 𝒒 first?

CVE

vendor

Scorer

𝜋1,1 𝜋1,2 𝜋1,3 𝜋1,4 𝜋1,5 Global

Enterprise

User

Scores for all policies and for 𝜸

Pick support 𝜋1,3 𝜋2,2 𝜋3,1 The scores from samples selected policies Policy-conditioned view weighting

Norm 𝒛𝟑 (𝒒, 𝒄𝒊 )

+

Selected Policy

Support bank

𝒛𝟐 (𝒒, 𝒄𝒊 )

+ Scorer

𝜋3,1 𝜋3,2 𝜋3,3

weakness reference Exploit source

𝒛𝟏 (𝒒, 𝒄𝒊 ) Norm

Scorer

Selected Policy

Support samples in 𝜸

Norm

+

Selected Policy 𝜋2,1 𝜋2,2 𝜋2,3 𝜋2,4

+ product

Preference-Adaptive Score Fusion

Policy-Conditioned Multi-View Scoring

Preference scenario 𝜸

𝑤1

𝑤2

𝑤3

Weights

𝒛𝟏 (𝒒, 𝒄𝒊 ) × 𝒛𝟐 (𝒒, 𝒄𝒊 ) 𝒛𝟑 (𝒒, 𝒄𝒊 )

𝑭𝒂𝒅𝒂𝒑𝒕 𝒒, 𝒄𝒊 Adaptive Score

KG Retrieval Candidate Set 𝑪(𝒒) 𝑐1

CVE A

𝑐2

Conflict Solver

Top-K Routing

𝑐3 …

CVE B CVE C

If all views agree on the Top-K, preserve the shared order.

Knowledge Summarization

𝑭𝒂𝒅𝒂𝒑𝒕 𝒒, 𝒄𝒊

else

Feature Summary x(𝒒)

𝒛𝟏 (𝒒, 𝒄𝒊 ) 𝑭𝒖𝒏𝒊 𝒒, 𝒄𝒊 𝑭 𝒒, 𝒄𝒊 𝜶 𝒛𝟐 (𝒒, 𝒄𝒊 ) uniform 𝒛𝟑 (𝒒, 𝒄𝒊 ) average Uniform Score balance Final Score

Ranking

1. CVE C Top-K CVEs are used as the 2. CVE A priority 3. CVE B remediation set. …

𝑐3 𝑐1 𝑐2

𝑳

𝟏 Figure 2: Overview of the HARP framework𝑭𝒖𝒏𝒊 for𝒒, 𝒄query-based Given a natural-language query 𝒊 = ෍ 𝒛𝒍 (𝒒, 𝒄𝒊 ) CVE 𝑭 𝒒, 𝒄prioritization. 𝒊 = 𝜶𝑭𝒂𝒅𝒂𝒑𝒕 𝒒, 𝒄𝒊 + (𝟏 − 𝜶)𝑭𝒖𝒏𝒊 𝒒, 𝒄𝒊 𝑳 𝒍=𝟏 and a support bank of past labeled examples from the current preference scenario, HARP retrieves candidate CVEs and evidence from a vulnerability knowledge graph, scores candidates through policy-conditioned global, enterprise, 𝜋 and user views, adaptively fuses the view-specific scores with support-bank guidance, and produces the final ranked CVE list with multi-view regularization and Top-K consensus routing. Preference 3,1

context

For a query q, the model selects one policy for each view. Let h(q) denote the query embedding, and let κl,k be a key vector derived from the textual name of policy πl,k . The selected policy for view l: πl∗ = arg max sim(h(q), κl,k ), πl,k ∈Πl

(6)

where sim(·, ·) denotes similarity. This selects the policy whose key is most aligned with the query. Using the selected policy and the shared candidate feature summary, the view-specific scorer assigns a raw score to each candidate: al (q, ci ) = fl (q, ci | πl∗ , x(q)).

(7)

Here, al (q, ci ) is the raw score of candidate ci under view l. The output of this stage is a set of raw score vectors {al (q)}L l=1 ,

al (q) = [al (q, c1 ), . . . , al (q, cn )]. (8) These raw scores represent the ranking evidence produced by each view. In the next stage, they are normalized and adaptively combined to produce the final priority score. 3.4

Preference-Adaptive Score Fusion

The view-specific scores produced in the previous stage may have different scales. Directly combining raw scores can make the final ranking dominated by views with larger numerical ranges rather than stronger ranking evidence. We therefore apply per-view z-score normalization within each query’s candidate set: zl (q, ci ) =

al (q, ci ) − µl (q) q , σl2 (q) + ϵ

(9)

where µl (q) and σl2 (q) are the mean and variance of {al (q, ci )}ni=1 , and ϵ is a small constant for numerical stability. This makes fusion depend on relative ranking evidence rather than raw score magnitudes. After normalization, we adaptively combine the view-specific scores. A single global fusion rule would assume that all queries require the same balance among views. In our setting, however, view contributions should follow the current preference scenario, which we represent by a support bank of historical labeled examples. Under the main protocol, each preference scenario γ has its own bank Bγ (three scenarios, three banks). The bank is built from the support data only, where evaluation queries never enter; in deployment it can be refreshed with newly validated triage cases under the same scenario. For each support query, we have run all policies in all views and store their normalized score vectors together with the ranking supervision: Bγ = {(q (k) , C (k) , z (k) , y (k) )}M k=1 ,

(10)

where q (k) is a support query, C (k) is its candidate set, y (k) denotes the ranking supervision associated with that bank, and z (k) stores the normalized score vectors produced by all view-policy scorers. At inference time, the system attaches Bγ for the current scenario and uses it only as labeled historical examples: the scoring prompt contains no scenario information, and HARP does not predict one. Let π ∗ (q) = (π1,r1∗ , π2,r2∗ , . . . , πL,rL∗ )

(11)

denote the policy tuple selected in the previous

𝑳

𝑭𝒂𝒅𝒂𝒑𝒕 𝒒, 𝒄𝒊 = ෍ 𝒘𝒍 𝒛 𝒍=𝟏

stage. We then uniformly sample |S(q)| = 3 sup- fixed, and each policy is trained through its own ports from Bγ and, using the stored scores under lightweight adapter. Thus, policies share the same ∗ π (q), fit backbone model while learning different scoring ! behaviors through separate trainable parameters. L X X For each view l and policy πl,r ∈ Πl , we use wγ (q) = arg min L y (k) , wl zl,rl∗ (q (k) ) , (k) w policy-specific ranking supervision yl,r over the l=1 k∈S(q) (12) candidate evidence u(k) . Different policies emphawhere L denotes a ranking loss. Because these size different remediation criteria over the same score vectors are precomputed, sampling three sup- candidates and therefore induce different training ports and fitting a three-dimensional weight vector targets. Details of the policy definitions used to is cheap relative to the LLM scoring calls. Policy guide this construction are provided in Appendix G. selection depends on the query, while the prefer- Importantly, these policy targets are used only ence signal for weighting comes from the historical to train the adapters. Test rankings are instead labels in Bγ . The adaptive fused score is obtained from independent annotations provided by cybersecurity practitioners following scenarioL X specific prioritization guidelines. The evaluation Fadapt (q, ci ) = wlγ (q)zl,rl∗ (q, ci ). (13) scenarios and their annotation guidelines were del=1 veloped independently of the policy templates used Although adaptive fusion adjusts view importance, to generate adapter supervision. The policy temfitted weights may become very small or nega- plates are never used to construct evaluation labels and are never provided during inference. tive. To preserve complementary evidence from Adapters therefore learn reusable scoring beall views, we introduce a uniform multi-view reguhaviors rather than a preference-scenario classifier. larization term: Preference adaptation for a target scenario is inL 1X Funi (q, ci ) = zl,rl∗ (q, ci ), (14) troduced at inference time through that scenario’s L historical support bank Bγ , while the query is used l=1 for retrieval, policy selection, and view scoring. F (q, ci ) = αFadapt (q, ci ) + (1 − α)Funi (q, ci ), Let θl,r denote the trainable parameters for pol(15) icy πl,r in view l. For each policy, we convert the where α ∈ [0, 1] is selected on the development policy-specific candidate scores into a textual target split (α=0.3 in the main experiments). output that lists candidates with their scores. We After computing the final fused score, HARP use sequence-generation supervision to align the ranks candidates by sorting F (q, ci ) in descend- training objective with the score-generation format ing order. We additionally apply a Top-K consen- used during inference. The policy-specific scorer is sus routing rule, with K = ⌈0.3 · |C(q)|⌉. If the trained to align its generated output with this target: selected view-specific rankings produce the same   X top-K ordering, HARP preserves this shared ordermin Lgen Tl,r (q), T̂l,r (q) , (17) θl,r ing at the top of the final ranking and orders the (q,C(q),u)∈D remaining candidates by the fused score. Otherwise, HARP ranks all candidates directly by the where Tl,r (q) is the target scoring text for policy fused score. This is a lightweight consensus check πl,r , T̂l,r (q) is the generated scoring text, and Lgen on top of weighted fusion, rather than a general is the sequence-generation loss. conflict-resolution procedure. Finally, we construct the support bank used by the fusion module. For each support instance of 3.5 Training a preference scenario γ, we have the outputs of We train the policy-conditioned scorers using a all trained policy-specific scorers and parse their ranking dataset outputs into score vectors. These vectors are nor(k) (k) (k) N D = {(q , C(q ), u )}k=1 , (16) malized within the candidate set and stored together with the support ranking supervision: where u(k) denotes the feature information of candidates in C(q (k) ). The backbone LLM is kept Bγ = {(q (k) , C (k) , z (k) , y (k) )}M (18) k=1 .

Here, z (k) contains the normalized score vectors produced by all view-policy scorers, and y (k) is used only for weight fitting on support instances.

4

Evaluation

We evaluate HARP across preference scenarios and backbone LLMs, then analyze the contribution of its components. We first describe the datasets and protocol, then baselines and results. Appendix B details the support-bank protocol and mixed-support control; Appendix I and Appendix J report parameter and case studies. 4.1

Datasets and Evaluation Setting

We construct a query-based CVE prioritization benchmark from existing CVE records and exploitrelated sources. Based on these sources, we build a vulnerability knowledge graph and generate querycandidate ranking instances for evaluation. Each instance contains a natural-language query, a candidate CVE set retrieved from the graph, and candidate-level vulnerability evidence. To study preference-dependent ranking, cybersecurity practitioners from our organization’s IT/security team annotated ground-truth rankings under three evaluation scenarios: importance, exploit_first, and patch_order (Appendix G). These scenarios define evaluation objectives and are distinct from the policy templates used for adapter training. Their guidelines were developed independently and did not ask annotators to reproduce any policy weighting scheme. For each query– candidate set, annotators ranked candidates using the scenario-specific guidelines and available vulnerability evidence, resolving disagreements through discussion to obtain a consensus ranking. Thus, the evaluation labels are independent of the policy-specific adapter supervision. Although some scenarios and policies share high-level objectives, rankings were based on the complete evidence and qualitative guidelines rather than predefined formulas or policy-specific rules. Each preference scenario has a separate support/train/dev/test split and a support bank Bγ built only from its support split. At test time, HARP receives the query, graph-grounded candidate evidence, and historical supports from Bγ . The scoring prompt includes no scenario name, annotation guideline, or feature-weight vector, and the model does not predict the scenario identity. Fusion samples three supports to fit the view weights. A Mixed Support Bank control pools supports across scenarios (Appendix B). Splits are instance-based.

We evaluate GPT-OSS-20B, Llama3-8B, and Qwen2.5-7B-Instruct under each preference scenario using Precision@K, MAP@K, and MRR@K, where K = ⌈0.3 · |C(q)|⌉. Results are averaged over five independent runs, with HARP standard deviations reported in Appendix E. 4.2 Baselines We compare HARP with LLM-based and nonLLM baselines under their intended inputs. LLM directly prompts the backbone to rank candidates; LLM-SC aggregates multiple sampled rankings; LLM-KG-RAG adds graph-retrieved evidence to the ranking prompt; and Embedding Ranking uses query–candidate embedding similarity. We also include three single-view variants (Global, Enterprise, and User) without multi-view fusion. As non-LLM comparisons, BM25 ranks candidates by lexical matching over textual query–candidate evidence, and Industrial Signals builds a supervised ranker on structured vulnerability features that include CVSS severity, EPSS-style exploit likelihood, CISA KEV-style known-exploitation indicators, patch availability, attack vector, and related exposure cues. Thus, Industrial Signals uses the main industrial prioritization signals and learns how to combine them, which will serve as a traditional way for CVE ranking. 4.3

Main Results

Table 1 reports five-run averages across non-LLM baselines, three backbone LLMs, and three preference scenarios. HARP uses multi-view scoring and Preference-adaption that makes our method provide better performance, while other method like prompting, BM25, and embedding baselines do not. HARP consistently outperforms LLM prompting, LLM-SC, LLM-KG-RAG, embedding ranking, single-view variants, and the non-LLM baselines. Direct LLM ranking is weak and self-consistency helps only partially. LLM-KGRAG benefits from graph evidence but still lags behind HARP. Embedding Ranking is competitive on some Precision@K scores but weaker on MAP@K and MRR@K. BM25 remains below HARP, showing that lexical matching alone is insufficient. Industrial Signals is stronger than several prompting baselines but still underperforms HARP, even though it directly consumes industrial prioritization signals as explicit feature vectors. The single-view variants also underperform the full model. While a few MAP@K margins over the strongest single view are smaller than the

Table 1: Main ranking performance across non-LLM baselines, backbone LLMs, and preference scenarios. We report Precision@k, MAP@k, and MRR@k averaged over five runs. The best result for each metric within each backbone setting is highlighted in bold. HARP standard deviations are in Appendix E. Setting

Importance

Method P@k

Exploit_First

Patch_Order

MAP@k MRR@k

P@k

MAP@k MRR@k

P@k

MAP@k MRR@k

Non-LLM

Industrial Signals 0.4945 BM25 0.4882

0.3594 0.3783

0.3304 0.3319

0.5057 0.4566

0.3672 0.3487

0.3385 0.3066

0.4966 0.4755

0.3621 0.3703

0.3327 0.3277

GPT-OSS-20B

HARP Global Enterprise User LLM LLM-SC LLM-KG-RAG Embedding

0.5685 0.4700 0.4852 0.4659 0.1943 0.4768 0.3032 0.4789

0.4598 0.4208 0.4357 0.4127 0.1732 0.3693 0.2749 0.3618

0.4194 0.3541 0.3709 0.3490 0.1371 0.3374 0.2246 0.3243

0.5758 0.4422 0.4730 0.4607 0.2281 0.4829 0.3347 0.4883

0.4534 0.3946 0.4167 0.4125 0.2036 0.3701 0.3050 0.3666

0.4123 0.3228 0.3505 0.3471 0.1497 0.3389 0.2494 0.3284

0.5921 0.4634 0.5117 0.4749 0.2261 0.4906 0.3014 0.4866

0.4833 0.4168 0.4522 0.4212 0.2059 0.3839 0.2781 0.3704

0.4414 0.3495 0.3876 0.3607 0.1651 0.3512 0.2250 0.3313

Llama3-8B

HARP Global Enterprise User LLM LLM-SC LLM-KG-RAG Embedding

0.7466 0.6576 0.6772 0.6960 0.4531 0.5331 0.6557 0.4793

0.6686 0.6302 0.6409 0.6634 0.3800 0.4292 0.6198 0.3596

0.5871 0.5406 0.5487 0.5633 0.3429 0.3920 0.5294 0.3198

0.7366 0.6720 0.6768 0.6739 0.4283 0.5115 0.5888 0.4763

0.6597 0.6432 0.6438 0.6450 0.3502 0.4002 0.5519 0.3553

0.5782 0.5443 0.5471 0.5434 0.3162 0.3616 0.4732 0.3146

0.7449 0.6687 0.6764 0.6777 0.4350 0.5160 0.6615 0.4785

0.6666 0.6380 0.6471 0.6432 0.3602 0.4110 0.6275 0.3610

0.5859 0.5441 0.5497 0.5506 0.3284 0.3734 0.5394 0.3197

HARP Global Enterprise User Qwen2.5-7B-Instruct LLM LLM-SC LLM-KG-RAG Embedding

0.8337 0.7282 0.7447 0.7565 0.3587 0.5178 0.7192 0.4553

0.7376 0.6970 0.7146 0.7233 0.2992 0.4073 0.6346 0.3404

0.6520 0.5866 0.5981 0.6106 0.2551 0.3758 0.5709 0.3098

0.8336 0.7365 0.7442 0.7407 0.3433 0.4944 0.6711 0.4438

0.7342 0.7052 0.7137 0.7067 0.2828 0.3772 0.5784 0.3257

0.6488 0.5917 0.5975 0.5974 0.2474 0.3491 0.5205 0.2953

0.8404 0.7246 0.7508 0.7686 0.3425 0.5260 0.7252 0.4459

0.7417 0.6936 0.7259 0.7371 0.2868 0.4155 0.6393 0.3306

0.6530 0.5842 0.6109 0.6229 0.2486 0.3868 0.5723 0.2996

gaps to prompting baselines, HARP remains best across P@K/MAP@K/MRR@K jointly, and Appendix E shows that these improvements are stable relative to run-to-run variation. Within-system evidence that scenario-matched supports matter is reported in Section 4.4. We provide further analysis in the appendix. Appendix E reports run-to-run standard deviations for HARP, Appendix I reports a sensitivity study on the interpolation coefficient α, Appendix B details the support-bank protocol and mixed-support control, and Appendix J presents cases analyzing how HARP combines view-specific rankings. 4.4 Ablation Study Table 2 reports the ablation results. We compare HARP with Mixed Support Bank, No Regularization, Equal Weight, Random Weight, No Top-K Consensus, and Random Policy. Mixed Support Bank keeps the same adapters and fusion procedure but pools supports across preference scenarios and samples without using the evaluated scenario identity; scores drop relative to HARP to a level close to Equal Weight and generally below

No Regularization, showing that scenario-matched support supervision is an important adaptation signal. No Regularization generally performs worse than HARP, especially in the exploit-first and patchorder preference scenarios, indicating that the uniform branch helps preserve complementary evidence across views. Equal Weight consistently underperforms HARP, while Random Weight causes a much larger drop, confirming that view contributions should be estimated rather than fixed or random. No Top-K Consensus also underperforms the full model, suggesting that preserving cross-view agreement among top candidates improves ranking stability. Random Policy is generally weaker than HARP, demonstrating the importance of queryconditioned policy selection.

5

Related Work

5.1

Vulnerability Prioritization and Ranking

Vulnerability prioritization is closely related to exploit prediction and remediation planning. Prior work shows that exploit-based signals, social evidence, patch availability, and operational con-

Table 2: Ablation study across backbone LLMs and preference scenarios. Mixed Support Bank pools supports from all preference scenarios without using the evaluated scenario identity. We report Precision@k, MAP@k, and MRR@k. The best result for each metric within each setting is highlighted in bold. Backbone LLM

Importance

Method

Exploit_First

Patch_Order

P@k

MAP@k MRR@k

P@k

MAP@k MRR@k

P@k

MAP@k MRR@k

GPT-OSS-20B

HARP Mixed Support Bank No Regularization Equal Weight Random Weight No Top-K Consensus Random Policy

0.5685 0.5340 0.5601 0.5317 0.4056 0.5344 0.4920

0.4598 0.4395 0.4526 0.4380 0.3109 0.4407 0.3985

0.4194 0.3985 0.4128 0.3974 0.2926 0.3996 0.3652

0.5758 0.5175 0.5204 0.5192 0.4115 0.4787 0.4728

0.4534 0.4180 0.4051 0.4197 0.3204 0.3812 0.3761

0.4123 0.3765 0.3706 0.3776 0.2963 0.3458 0.3410

0.5921 0.5585 0.5605 0.5608 0.4106 0.5281 0.5015

0.4833 0.4580 0.4431 0.4604 0.3071 0.4223 0.4082

0.4414 0.4175 0.4076 0.4190 0.2881 0.3864 0.3755

Llama3-8B

HARP Mixed Support Bank No Regularization Equal Weight Random Weight No Top-K Consensus Random Policy

0.7466 0.7112 0.7186 0.7095 0.1858 0.6795 0.7052

0.6686 0.6465 0.6404 0.6489 0.1367 0.6206 0.6285

0.5871 0.5640 0.5675 0.5657 0.1126 0.5490 0.5510

0.7366 0.7088 0.7160 0.7104 0.1899 0.6846 0.6684

0.6597 0.6495 0.6380 0.6528 0.1378 0.6267 0.5912

0.5782 0.5632 0.5681 0.5649 0.1122 0.5530 0.5208

0.7449 0.7060 0.7093 0.7045 0.1718 0.6668 0.6987

0.6666 0.6505 0.6295 0.6528 0.1287 0.6115 0.6320

0.5859 0.5710 0.5557 0.5736 0.1061 0.5362 0.5524

HARP Mixed Support Bank No Regularization Qwen2.5-7B-Instruct Equal Weight Random Weight No Top-K Consensus Random Policy

0.8337 0.7725 0.8028 0.7697 0.1584 0.7383 0.7864

0.7376 0.7148 0.7018 0.7163 0.1160 0.6813 0.6885

0.6520 0.6195 0.6255 0.6179 0.0850 0.5918 0.6120

0.8336 0.7680 0.8165 0.7651 0.1568 0.7461 0.7620

0.7342 0.7125 0.7139 0.7147 0.1186 0.6919 0.6588

0.6488 0.6160 0.6347 0.6143 0.0876 0.5985 0.5885

0.8404 0.7835 0.8290 0.7809 0.1500 0.7565 0.7912

0.7417 0.7265 0.7299 0.7282 0.1115 0.7023 0.6985

0.6530 0.6275 0.6442 0.6261 0.0838 0.6051 0.6108

straints are important for improving remediation decisions and risk assessment (Jacobs et al., 2020; Chen et al., 2019; Olswang et al., 2022; Lacombe and Bardin, 2025). These studies motivate evidence-aware vulnerability ranking, but they mainly focus on exploit prediction, patch ordering, or fixed risk criteria. General ranking and neural embedding retrieval models further provide generic ranking tools (Cao et al., 2007; Burges et al., 2006; Nogueira et al., 2020). However, they typically assume that the target ranking criterion is fixed or explicitly supervised. In contrast, HARP studies CVE prioritization under an existing preference scenario, where preference is carried by a scenariospecific bank of past labeled supports rather than by the query or a fixed scoring rule. 5.2

Modular Adaptation

Retrieval-augmented and evidence-grounded language models improve generation by incorporating external information (Karpukhin et al., 2020; Khattab and Zaharia, 2020; Lewis et al., 2020; Guu et al., 2020). However, grounding alone does not specify which preference scenario should guide ranking. Parameter-efficient adaptation methods such as adapters and LoRA provide lightweight modules for specializing model behavior without full retraining (Houlsby et al., 2019; Hu et al., 2022). Knowledge editing and related modular-

update methods further study localized parameter changes for factual or behavioral control (Mitchell et al., 2022a,b; Dai et al., 2022; Zhong et al., 2023; Hartvigsen et al., 2023; Yu et al., 2024; Wang et al., 2024a; Li et al., 2025; Zhang et al., 2025; Liu et al., 2025; Zhang et al., 2026; Zou et al., 2023; Deng et al., 2025; Jung et al., 2025), but they mainly target factual updating or task adaptation. HARP instead uses policy-specific lightweight adapters for multi-view CVE scoring and combines them through adaptive score fusion; we treat knowledge editing only as related motivation for modular control, not as the technical basis of our method.

6

Conclusion

In this paper, we studied query-based CVE prioritization under preference scenarios that are often implicit and difficult to specify in prompts. We proposed HARP, a graph-grounded multi-view framework that retrieves vulnerability evidence, performs policy-conditioned scoring, and adapts view fusion using scenario-matched historical supports without requiring an explicit textual preference description. We also constructed a benchmark with policy-specific training supervision and practitioner-annotated rankings under three preference scenarios. Experiments show that HARP outperforms multiple standard ranking baselines as a full system.

7

Limitations

This work has several limitations. Our benchmark focuses on three preference scenarios and English triage queries built from public CVE evidence; extending to additional languages, proprietary asset inventories, or organization-specific remediation workflows is left for future work. The current implementation freezes the backbone LLM and trains only lightweight policy adapters, so the effect of jointly updating more backbone parameters is not explored. Inference uses multiple view-wise scoring calls, and wall-clock cost may vary with candidate-set size and hardware.

8

Ethical Considerations

This work is intended to support defensive vulnerability management by helping analysts prioritize CVEs for remediation. The framework does not generate exploits or provide instructions for exploiting vulnerabilities; instead, it uses vulnerability evidence to improve ranking decisions. However, any system that prioritizes high-risk or actively exploitable vulnerabilities could potentially be misused if deployed without appropriate access restrictions. Therefore, practical use should be limited to authorized security workflows and should follow responsible disclosure and organizational security policies. The model may also inherit bias or incompleteness from public vulnerability records, exploit databases, or patch information, which could lead to incorrect prioritization. Human oversight remains necessary, especially for high-impact remediation decisions, and the system should be used as a decision-support tool rather than an autonomous replacement for security analysts.

References Luca Allodi and Fabio Massacci. 2014. Comparing vulnerability severity and exploits using case-control studies. ACM TISSEC. Mehran Bozorgi, Lawrence K. Saul, Stefan Savage, and Geoffrey M. Voelker. 2010. Beyond heuristics: Learning to classify vulnerabilities and predict exploits. In ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD). Christopher J. C. Burges. 2010. From ranknet to lambdarank to lambdamart: An overview. Technical report, Microsoft Research. Christopher J. C. Burges, Robert Ragno, and Quoc V. Le. 2006. Learning to rank with nonsmooth cost func-

tions. In Advances in Neural Information Processing Systems (NeurIPS). Christopher J. C. Burges, Tal Shaked, Erin Renshaw, Ari Lazier, Matt Deeds, Nicole Hamilton, and Gregory N. Hullender. 2005. Learning to rank using gradient descent. In International Conference on Machine Learning (ICML). Zhe Cao, Tao Qin, Tie-Yan Liu, Ming-Feng Tsai, and Hang Li. 2007. Learning to rank: From pairwise approach to listwise approach. In International Conference on Machine Learning (ICML). Haipeng Chen, Rui Liu, Noseong Park, and V. S. Subrahmanian. 2019. Using twitter to predict when vulnerabilities will be exploited. In ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD). Damai Dai, Li Dong, Yaru Hao, Zhifang Sui, Baobao Chang, and Furu Wei. 2022. Knowledge neurons in pretrained transformers. In Annual Meeting of the Association for Computational Linguistics (ACL). Stephanie de Smale, Rik van Dijk, Xander B. Bouwman, Jeroen van der Ham, and Michel van Eeten. 2023. No one drinks from the firehose: How organizations filter and prioritize vulnerability information. In IEEE Symposium on Security and Privacy (IEEE S&P). Jingcheng Deng, Zihao Wei, Liang Pang, Hanxing Ding, Huawei Shen, and Xueqi Cheng. 2025. Everything is editable: Extend knowledge editing to unstructured data in large language models. In International Conference on Learning Representations (ICLR). FIRST.Org, Inc. 2019. Common vulnerability scoring system version 3.1: Specification document. Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad AlDahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Alex Vaughan, Amy Yang, Angela Fan, Anirudh Goyal, Anthony Hartshorn, Aobo Yang, Archi Mitra, Archie Sravankumar, Artem Korenev, Arthur Hinsvark, and 212 others. 2024. The llama 3 herd of models. arXiv:2407.21783. Kelvin Guu, Kenton Lee, Zora Tung, Panupong Pasupat, and Ming-Wei Chang. 2020. REALM: Retrievalaugmented language model pre-training. In International Conference on Machine Learning (ICML). Thomas Hartvigsen, Swami Sankaranarayanan, Hamid Palangi, Yoon Kim, and Marzyeh Ghassemi. 2023. Aging with GRACE: Lifelong model editing with discrete key-value adaptors. In Advances in Neural Information Processing Systems (NeurIPS). Anders Høst, Pierre Lison, and Leon Moonen. 2023. Constructing a knowledge graph from textual descriptions of software vulnerabilities in the national vulnerability database. In Nordic Conference on Computational Linguistics (NoDaLiDa).

Neil Houlsby, Andrei Giurgiu, Stanislaw Jastrzebski, Bruna Morrone, Quentin De Laroussilhe, Andrea Gesmundo, Mona Attariyan, and Sylvain Gelly. 2019. Parameter-efficient transfer learning for NLP. In International Conference on Machine Learning (ICML). Edward J. Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2022. LoRA: Low-rank adaptation of large language models. In International Conference on Learning Representations (ICLR). Jay Jacobs, Sasha Romanosky, Idris Adjerid, and Wade Baker. 2020. Improving vulnerability remediation through better exploit prediction. Journal of Cybersecurity. Jay Jacobs, Sasha Romanosky, Octavian Suciu, Benjamin Edwards, and Armin Sarabi. 2023. Enhancing vulnerability prioritization: Data-driven exploit predictions with community-driven insights. In IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). Dahyun Jung, Jaehyung Seo, Jaewook Lee, Chanjun Park, and Heuiseok Lim. 2025. CoME: An unlearning-based approach to conflict-free model editing. In Annual Conference of the North American Chapter of the Association for Computational Linguistics (NAACL). Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. 2020. Dense passage retrieval for opendomain question answering. In Conference on Empirical Methods in Natural Language Processing (EMNLP).

Xuyuan Liu, Shengyu Chen, Xinshuai Dong, Yanchi Liu, Xujiang Zhao, Haoyu Wang, Yujun Yan, Haifeng Chen, and Zhengzhang Chen. 2025. Representation interventions enable lifelong unstructured knowledge control. arXiv:2511.20892. Ilya Loshchilov and Frank Hutter. 2019. Decoupled weight decay regularization. In International Conference on Learning Representations (ICLR). Kevin Meng, David Bau, Alex Andonian, and Yonatan Belinkov. 2022. Locating and editing factual associations in GPT. In Advances in Neural Information Processing Systems (NeurIPS). Kevin Meng, Arnab Sen Sharma, Alex Andonian, Yonatan Belinkov, and David Bau. 2023. Massediting memory in a transformer. In International Conference on Learning Representations (ICLR). Eric Mitchell, Charles Lin, Antoine Bosselut, Chelsea Finn, and Christopher D. Manning. 2022a. Fast model editing at scale. In International Conference on Learning Representations (ICLR). Eric Mitchell, Charles Lin, Antoine Bosselut, Christopher D. Manning, and Chelsea Finn. 2022b. Memorybased model editing at scale. In International Conference on Machine Learning (ICML). Rodrigo Nogueira, Zhiying Jiang, and Jimmy Lin. 2020. Document ranking with a pretrained sequence-tosequence model. In Conference on Empirical Methods in Natural Language Processing (EMNLP). Amir Olswang, Tom Gonda, Rami Puzis, Guy Shani, Bracha Shapira, and Noam Tractinsky. 2022. Prioritizing vulnerability patches in large networks. Expert Systems with Applications.

Omar Khattab and Matei Zaharia. 2020. ColBERT: Efficient and effective passage search via contextualized late interaction over BERT. In International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR).

Carl Sabottke, Octavian Suciu, and Tudor Dumitraş. 2015. Vulnerability disclosure in the age of social media: Exploiting twitter for predicting real-world exploits. In USENIX Security Symposium (USENIX Security).

Guillaume Lacombe and Sébastien Bardin. 2025. Attacker control and bug prioritization. In USENIX Security Symposium (USENIX Security).

Jonathan M. Spring, Allen D. Householder, Eric Hatleback, Art Manion, Madison Oliver, Vijay S. Sarvepalli, Laurie Tyzenhaus, and Charles G. Yarbrough. 2021. Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (version 2.0). Technical report, Carnegie Mellon University Software Engineering Institute.

Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-augmented generation for knowledgeintensive NLP tasks. In Advances in Neural Information Processing Systems (NeurIPS). Frank Li and Vern Paxson. 2017. A large-scale empirical study of security patches. In ACM Conference on Computer and Communications Security (CCS). Jiaang Li, Quan Wang, Zhongnan Wang, Yongdong Zhang, and Zhendong Mao. 2025. ELDER: Enhancing lifelong model editing with mixture-of-LoRA. In AAAI Conference on Artificial Intelligence (AAAI).

Octavian Suciu, Connor Nelson, Zhuoer Lyu, Tiffany Bao, and Tudor Dumitraş. 2022. Expected exploitability: Predicting the development of functional vulnerability exploits. In USENIX Security Symposium (USENIX Security). Peng Wang, Zexi Li, Ningyu Zhang, Ziwen Xu, Yunzhi Yao, Yong Jiang, Pengjun Xie, Fei Huang, and Huajun Chen. 2024a. WISE: Rethinking the knowledge memory for lifelong model editing of large language models. In Advances in Neural Information Processing Systems (NeurIPS).

Song Wang, Yaochen Zhu, Haochen Liu, Zaiyi Zheng, Chen Chen, and Jundong Li. 2024b. Knowledge editing for large language models: A survey. ACM Computing Surveys. Qiushi Wu, Yue Xiao, Xiaojing Liao, and Kangjie Lu. 2022. OS-aware vulnerability prioritization via differential severity analysis. In USENIX Security Symposium (USENIX Security). Zhengxuan Wu, Aryaman Arora, Zheng Wang, Atticus Geiger, Dan Jurafsky, Christopher D. Manning, and Christopher Potts. 2024. ReFT: Representation finetuning for language models. In Advances in Neural Information Processing Systems (NeurIPS). An Yang, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jingren Zhou, Junyang Lin, Kai Dang, and 23 others. 2024. Qwen2.5 technical report. arXiv:2412.15115. Lang Yu, Qin Chen, Jie Zhou, and Liang He. 2024. MELO: Enhancing model editing with neuronindexed dynamic LoRA. In AAAI Conference on Artificial Intelligence (AAAI). Binchi Zhang, Zhengzhang Chen, Zaiyi Zheng, Jundong Li, and Haifeng Chen. 2025. Resolving editing-unlearning conflicts: A knowledge codebook framework for large language model updating. arXiv:2502.00158. Binchi Zhang, Xujiang Zhao, Jundong Li, Haifeng Chen, and Zhengzhang Chen. 2026. Mind the gap in cultural alignment: Task-aware culture management for large language models. arXiv:2602.22475. Zexuan Zhong, Zhengxuan Wu, Christopher D. Manning, Christopher Potts, and Danqi Chen. 2023. MQuAKE: Assessing knowledge editing in language models via multi-hop questions. In Conference on Empirical Methods in Natural Language Processing (EMNLP). Andy Zou, Long Phan, Sarah Chen, James Campbell, Phillip Guo, Richard Ren, Alexander Pan, Xuwang Yin, Mantas Mazeika, Ann-Kathrin Dombrowski, Shashwat Goel, Nathaniel Li, Michael J. Byun, Zifan Wang, Alex Mallen, Steven Basart, Sanmi Koyejo, Dawn Song, Matt Fredrikson, and 2 others. 2023. Representation engineering: A top-down approach to AI transparency. arXiv:2310.01405.

A

Details of Vulnerability Knowledge Graph Construction

We construct an enriched vulnerability knowledge graph as the structured evidence source for retrieval and prioritization. The base graph G0 = (V0 , E0 ) is built from raw CVE records and contains multiple types of nodes, including CVE, product, vendor, weakness, and reference nodes (Høst et al., 2023). Each CVE node stores its textual description, severity information such as CVSS scores, affected configurations, weakness categories, and external references. Product and vendor nodes are extracted from affected configurations, weakness nodes represent CWE categories, and reference nodes correspond to advisories, patches, exploit reports, or other supporting evidence. Edges encode relations among these entities, such as which products or vendors a CVE affects, which weakness category it belongs to, and which references support it. To incorporate prioritization signals beyond raw CVE records, we enrich the base graph with external sources such as known exploited vulnerability lists and public exploit repositories. These sources provide evidence about exploit availability, observed exploitation, patch-related references, and other remediation-relevant signals. The enrichment process updates node attributes and adds edges when new relations are identified: G = Φ(G0 , S),

(19)

where S denotes the external sources and Φ is the enrichment procedure. The resulting graph contains both structured vulnerability relations and prioritization-oriented evidence, and is used by the retrieval operator in the main text to form queryspecific candidate sets.

B

Support-Bank Protocol

Each preference scenario γ ∈ {importance, exploit_first, patch_order} has its own support/train/dev/test split over the shared query–candidate instance IDs and its own bank Bγ . The bank stores, for every support instance of scenario γ, (i) precomputed normalized score vectors from all view–policy scorers and (ii) the ranking supervision y (k) for that scenario. Test instance IDs of γ never enter Bγ . Main results use the matched bank Bγ rather than a pooled bank. At inference time, attaching Bγ provides historical labeled examples for fusion: the scoring

prompt has no scenario name, and the model does not predict one. After query-conditioned policy selection, fusion uniformly samples three supports from Bγ under the selected policy tuple and fits view weights on those supports’ labels. To measure the value of scenario-matched supports, we additionally evaluate a Mixed Support Bank control. We build a pooled bank Bmix = S B γ γ and, at test time for every scenario, sample |S(q)| = 3 supports from Bmix without using the evaluated scenario identity. Adapters, policy selection, α, and decoding settings are unchanged. Results are reported in Table 2. Splits are by query–candidate instance ID within each scenario, with support and test IDs disjoint. Policy feature-weight templates are used only to construct adapter training targets. Although both the templates and the evaluation scenarios are motivated by common cybersecurity remediation objectives, the evaluation scenarios define independent human annotation guidelines and are not derived from the policy templates.

bedding with a key derived from each policy’s textual name. The fusion weight vector therefore has dimension 3. For each support instance, we precompute and store the normalized score vectors produced by all policy-specific scorers under all three views. At inference time, after the query selects one policy for each view, fusion samples |S(q)| = 3 support instances that contain the selected policy configuration and fits the view weights as described in the main text. This fitting step is cheap relative to the per-view LLM scoring calls. The support bank is fixed during evaluation only to keep a clean protocol; it can be refreshed in deployment. Together with uniform multi-view regularization (α=0.3 in the main experiments) and Top-K consensus routing, this design avoids relying on a single static fusion rule. For each query instance, candidate-level scores are normalized within the candidate set before fusion. The evaluation cutoff is defined as

C

where C(q) is the candidate set for query q. We evaluate ranked lists using Precision@K, MAP@K, and MRR@K. Let GK (q) denote the set of ground-truth Top-K candidates for query q, and let π̂q denote the predicted ranking. Precision@K measures the fraction of the predicted Top-K candidates that appear in GK (q):

Implementation Details

We implement HARP with transformer-based causal language models as the backbone. The backbone parameters are frozen, and each policy is implemented as a lightweight adapter on a target MLP projection layer. For example, for Qwen2.5-7BInstruct, we use model.layers.14.mlp.up_proj as the target layer. This design allows different policies to learn different scoring preferences while sharing the same frozen backbone LLM. During training, we optimize only the policyspecific adapters. Each view-policy pair is trained with its own ranking supervision. The adapters are trained for 3 epochs with learning rate 3 × 10−4 using AdamW (Loshchilov and Hutter, 2019). The model output is constrained by the ranked_zscore format described in Appendix F. The maximum number of new tokens for score generation is set to 200, the decoding temperature is set to 0.75, and invalid score outputs are retried up to 5 times. The framework uses three prioritization views: global, enterprise, and user, with five, four, and three policies respectively in our benchmark (Table 5). These uneven counts reflect the different prioritization trends available under each view rather than an architectural constraint; policies can be added or removed without changing the overall pipeline. Policy selection compares the query em-

K = ⌈0.3 · |C(q)|⌉,

Precision@K(q) =

(20)

|π̂q [1 : K] ∩ GK (q)| . (21) K

MAP@K measures ranking quality within the top-K results by averaging precision at the ranks where a ground-truth Top-K candidate appears: K

1 X AP@K(q) = Precision@j(q) K j=1

(22)

· I{π̂q [j] ∈ GK (q)}. MAP@K is the mean of AP@K(q) over all test queries. For MRR@K, we treat each candidate in the ground-truth Top-K set as an individual target. For a query q, let rq (c) denote the rank position of candidate c in the predicted ranking π̂q . The reciprocal rank of candidate c is RR(q, c) =

1 . rq (c)

(23)

We then average the reciprocal ranks over all candidates in the ground-truth Top-K set: MRR@K(q) =

1 K

X c∈GK (q)

1 . rq (c)

(24)

The final MRR@K is the mean of MRR@K(q) over all test queries. If a ground-truth Top-K candidate does not appear in the predicted ranking, its reciprocal rank is set to zero. We conduct experiments on a Linux cluster using a conda environment. Each experiment is run on NVIDIA A100 GPUs with 80GB memory. Main ranking results for HARP and all baselines are reported as averages over five independent runs. Appendix E reports the corresponding standard deviations for HARP across these runs. For LLM-based baselines, self-consistency uses multiple sampled rankings and aggregates them into the final result. For embedding-based ranking, we use sentencetransformer embeddings by default and rank candidates according to their similarity to the query representation. Regarding inference cost, evaluating one test query with HARP takes approximately 50–70 seconds on an A100 GPU, depending on the backbone model and candidate-set size. The dominant cost is the LLM scoring calls: HARP invokes the policy-conditioned scorer once per view, so the latency is comparable to multi-call baselines such as LLM-SC and higher than single-call LLM prompting. Other stages are comparatively lightweight or can be amortized: KG retrieval uses indexed graph evidence, support-bank score vectors are precomputed offline, and adaptive fusion only fits a small three-dimensional view-weight vector over sampled support instances. We evaluate HARP with three backbone LLMs to test whether the proposed framework is robust across different model families and capacities. GPT-OSS-20B is an open-weight model from OpenAI with 21B total parameters and 3.6B active parameters. We include it as a stronger medium-scale backbone model. Llama3-8B is an instructiontuned model from the Llama 3 family (Grattafiori et al., 2024). We use it as a representative generalpurpose open LLM at the 8B scale. Qwen2.5-7BInstruct is an instruction-tuned model from the Qwen2.5 series (Yang et al., 2024). We include it as a strong 7B-scale backbone with strong instructionfollowing capabilities. Across all three models, the backbone parameters are kept frozen, and HARP

only trains policy-specific adapters. This setting allows us to compare how the same graph-grounded and preference-adaptive ranking framework behaves under different backbone models.

D

Dataset Statistics

We evaluate on three ranking datasets corresponding to the importance, exploit-first, and patchorder preference scenarios. Each contains 12,000 query–candidate samples with per-CVE groundtruth scores and is split into support (1,200; 10%), train (4,800; 40%), dev (1,200; 10%), and test (4,800; 40%). Support instances are used to build the scenario-specific bank Bγ and to fit fusion weights; train is used for adapter training; and test is used for the reported ranking metrics. All three scenarios share the same query–candidate skeletons and instance-ID split sizes; only the ranking objective used for annotation differs. Candidate-set sizes vary across queries under the natural retrieval distribution, and CVE-level feature summaries are stored separately and indexed by CVE ID.

E

Run-to-Run Variance of HARP

Table 3 reports the standard deviation of HARP over five independent runs for each backbone and preference scenario. The corresponding mean scores appear in Table 1.

F

Prompt Design and Output Protocol

The current prompt style is ranked_zscore. This format is used to make the LLM output directly usable as a candidate-level ranking signal. The prompt consists of a system instruction that specifies the output contract and a user instruction that provides the query, optional candidate-set synopsis, and candidate CVE list. The system prompt follows the structure below: You are a CVE prioritization expert. Output ONLY a [Scores] section. Use one line per candidate in the format CVE-ID: -0.00. Scores are normalized within this candidate set and may be signed values. Sort all lines from highest score to lowest score. Include all candidates exactly once. The user prompt contains the following fields: Question: <query> Candidate-set

synopsis:

Table 3: Standard deviation of HARP over five independent runs.

Backbone

Importance

Exploit_First

Patch_Order

P@k MAP@k MRR@k P@k MAP@k MRR@k P@k MAP@k MRR@k GPT-OSS-20B 0.0082 0.0068 Llama3-8B 0.0054 0.0058 Qwen2.5-7B-Instruct 0.0038 0.0042

<sample_summary> CVE candidates: [1] CVE-... [2] CVE-... ... Output [Scores] now highest to lowest):

0.0061 0.0084 0.0069 0.0056 0.0055 0.0060 0.0040 0.0034 0.0039

(sorted

During data generation for policy training, the same prompt format is paired with a target answer in the [Scores] block. The target scores come from the constructed policy-specific ranking supervision, standardized within the candidate set, and sorted from highest to lowest. During inference, the model is required to generate the same [Scores] format. The generated output is parsed by extracting explicit CVE-score pairs. If the output does not contain sufficient valid candidate scores, the system retries generation up to five times. Samples that still fail the output contract are marked invalid.

G

Preference Scenarios and Policy Definitions

This appendix clarifies the difference between policies used for adapter training and preference scenarios used for testing. A policy defines a viewspecific scoring preference; the corresponding ranking targets are used only as supervision for adapter training. A preference scenario defines a prioritization objective under which ground-truth rankings are annotated by cybersecurity practitioners. The preference scenarios and their annotation guidelines were developed independently of the policy templates used for adapter training and do not instruct annotators to reproduce any policy weighting scheme. Instead, they define qualitative prioritization objectives based on the available vulnerability evidence rather than predefined feature weights, scoring formulas, or policy-specific ranking rules. At test time, the scoring prompt does not include a preference-scenario ID; fusion instead uses the support bank Bγ attached to the evaluation run (Appendix B).

0.0062 0.0079 0.0068 0.0057 0.0053 0.0059 0.0039 0.0030 0.0028

0.0062 0.0056 0.0036

We train the scoring modules with policyspecific supervision rather than directly using support-bank labels because the policies capture relatively stable and reusable prioritization behaviors, whereas preference scenarios may vary across organizations and over time. This separation makes HARP a general framework: trained policy adapters can be reused across scenarios, while adaptation to a new or changing scenario requires only updating the support bank and refitting the fusion weights, rather than retraining the scoring modules. Although the policy set can also be extended when needed, it is expected to change less frequently than deployment-specific preference scenarios, making the overall adaptation process more efficient.

G.1

Candidate Evidence

For candidate scoring, the LLM scorer observes the natural-language query, the candidate set, the candidate-set synopsis, and candidate-level vulnerability evidence (CVE records, CVSS metadata, exploit signals, references, and product information). Separately, the fusion module observes a small sample of labeled supports from Bγ . The preference scenario is therefore not hidden from the full system: it enters through the support bank used for weight fitting, while remaining absent from the scorer prompt as an explicit tag. The candidate-level evidence includes textual description, CVSS severity label, CVSS base score, attack vector, exploit status, exploit flag, CWE identifiers, affected product keys, platform information, patch signals from references, reference count, version-related signals, and publication recency. These fields are summarized into the candidate feature summary provided to the LLM. For policy-adapter training, they are also converted into numerical feature contributions that guide the construction of policy-specific ranking supervision.

G.2

Feature Contribution Functions

We first define a common set of feature contribution functions {ϕf (c)} for each candidate CVE c. These functions map raw vulnerability evidence to normalized numerical values and are used only to guide the construction of policy-specific training targets. Table 4 lists the feature contribution rules used in our implementation. For textual severity labels, we use the following mapping: CRITICAL = 1.0,

HIGH = 0.7,

MEDIUM = 0.3,

LOW = 0.1.

(25)

All other severity labels are mapped to 0.0. Given any feature-weight vector λ, we first clip negative feature weights and normalize the remaining positive weights: λ̃f = max(λf , 0),

λ̄f = P

λ̃f

f ′ λ̃f ′

.

(26)

We then compute a generic weighted feature score:   X sλ (c) = max 0, λ̄f ϕf (c) . (27) f

This equation is a generic scoring template used only when constructing policy-specific training targets. G.3

Policy Training Targets

A policy is a discrete scoring preference template used to train a policy-specific adapter. Policies are organized under the three prioritization views: global, enterprise, and user. Each policy πl,r in view l is associated with a feature-weight template λl,r that guides the construction of its ranking supervision. The policy-specific training score for candidate c is defined as pol yl,r (c) = sλl,r (c).

(28)

pol The ranking induced by yl,r (c) is used only to train the adapter corresponding to policy πl,r . These scores are not the evaluation labels used in the final benchmark, and the policy templates are never applied to construct test rankings. Different policies emphasize different remediation criteria over the same candidate evidence. For example, an exploit-focused policy assigns larger

weights to exploit-related features, while a patchfocused policy assigns larger weights to patchrelated features. The feature-weight templates used to guide construction of all policy adapters are listed in Table 5. G.4

Scenario-Based Test Annotation

Preference scenarios define the evaluation objectives: importance, exploit_first, and patch_order. For each scenario, ground-truth rankings were annotated by cybersecurity practitioners from our organization’s IT/security team using the query, candidate evidence, and a scenario-specific prioritization guideline. The same query–candidate instances can therefore receive different rankings under different scenarios. Annotators independently assessed the candidate CVEs according to their professional judgment, and remaining disagreements were resolved through discussion to obtain a consensus ranking. The policy feature-weight templates used for adapter training were not available to the annotators and were never used to generate evaluation labels. Instead, these templates served solely to construct policy-specific supervision for training the adapters. These test rankings are independent of the policy-training templates. The templates provide supervision only for adapter training, whereas the evaluation scenarios define qualitative human annotation guidelines. Although both are motivated by common cybersecurity remediation objectives, the evaluation scenarios were designed independently and are not derived from the policy templates.

H

Overall Algorithm

Algorithm 1 summarizes the HARP inference procedure.

I

Sensitivity Analysis on α

We further study the effect of the interpolation coefficient α in the final score F (q, ci ) = αFadapt (q, ci ) + (1 − α)Funi (q, ci ). Figure 3 reports the sensitivity results on Qwen2.5-7B-Instruct across the three preference scenarios. The dashed vertical line marks the value used in our main experiments, α = 0.3. The effect of α differs across preference scenarios. In the importance preference scenario, all three metrics increase slightly when α grows from 0 to 0.3, and then decrease as α becomes larger. This suggests that a moderate amount of adaptive fusion

Table 4: Feature contribution rules used to guide the construction of policy-specific training supervision.

Feature

Contribution Rule

exploit 1.0 if KNOWN_EXPLOITED; 0.6 if has_exploit is true; otherwise 0.0 severity If base_score exists, min(1, base_score/10); otherwise use severity mapping patch 1.0 if has_patch_in_references is true; otherwise 0.0 attack_vector NETWORK: 1.0; ADJACENT: 0.5; LOCAL: 0.2; PHYSICAL: 0.1; otherwise 0.0 recency max(0, 1 − days_since_published/365) version_info 0.5 · has_version_info + 0.5 · affects_legacy_versions reference min(1, reference_count/10) cwe min(1, len(cwe_ids)/5) platform 1.0 if platform list is non-empty; otherwise 0.0 scope min(1, len(product_keys)/10) Table 5: Policy weights of the three views global, enterprise and user.

Policy

exploit severity patch attack recency version reference cwe platform scope

global_balanced global_exploit_first global_severity_first global_recent global_version_aware

2.5 3.5 2.0 1.5 1.5

2.0 1.0 2.5 1.0 1.5

0.5 0.3 1.0 0.5 1.0

0.8 0.5 0.5 0.3 0.4

0.5 0.6 0.3 2.5 0.3

0.3 0.2 0.5 0.3 2.0

0.3 0.2 0.2 0.5 0.3

0.2 0.1 0.2 0.2 0.2

0.1 0.0 0.1 0.1 0.2

0.2 0.2 0.2 0.2 0.2

enterprise_patch enterprise_compliance enterprise_scope enterprise_reference

2.0 2.0 2.5 1.5

1.0 2.5 2.0 1.2

2.0 0.8 0.8 1.0

0.3 0.5 0.5 0.4

0.2 0.3 0.4 0.5

0.6 0.4 0.4 0.4

0.4 0.2 0.3 1.5

0.1 0.2 0.2 0.2

0.1 0.1 0.2 0.1

0.2 0.5 1.2 0.2

user_risk user_quick_fix user_awareness

2.5 2.0 2.0

2.0 1.0 1.5

0.5 2.0 0.5

0.8 0.3 0.5

0.5 0.2 0.8

0.3 0.6 0.4

0.3 0.4 1.2

0.2 0.1 1.0

0.1 0.1 0.2

0.2 0.2 0.2

improves overall-priority ranking, while relying too heavily on adaptive fusion weakens the stabilizing effect of the uniform multi-view term. In the exploit-first preference scenario, the curves are more non-monotonic, but the best or near-best results still appear around α = 0.3 for MRR@K and Precision@K, with MAP@K remaining competitive. This indicates that exploit-focused ranking benefits from adaptive view weighting, but the improvement is not strictly monotonic. The patch-order preference scenario shows a different trend. Performance is strongest when α is small and generally decreases as α increases. This suggests that patch-oriented ranking benefits more from preserving balanced evidence across views, and excessive adaptive weighting may overemphasize one view at the cost of other useful patchrelated signals. Overall, α trades off supportconditioned adaptive fusion against uniform multi-

view stability. We select α=0.3 on the development split as a robust operating point across preference scenarios; the optimum can still vary by objective (e.g., patch-order favors smaller α).

J

Case Studies

We present two cases under Qwen2.5-7B-Instruct with α = 0.3 to examine how HARP combines view-specific rankings. Each case reports the ranking question, a brief candidate-set synopsis, the ground-truth ranking, and the rankings produced by the global, enterprise, user, and fusion scores. We focus on top-K behavior: which candidate each view places first, how the fused ranking differs from the single-view rankings, and what the fitted view weights imply about relative view contributions under the selected policy configuration. The case boxes below follow the same structure. A check mark indicates that the corresponding view

Qwen2.5-7B Importance

0.66

Exploit-first

MRR@K

0.660

0.645

0.655

0.640

0.650

0.63

0.635

0.645

0.62

0.630

0.640

0.70

0.740 0.735 0.730 0.725 0.720 0.715 0.710

0.755 0.750 0.745 0.740 0.735 0.730 0.725

0.84

0.840

0.855 0.850 0.845 0.840 0.835 0.830 0.825 0.820

0.64

0.74 0.73 MAP@K

0.665

0.650

0.65

0.72 0.71

0.835

0.83 Precision@K

Patch-order

0.655

0.830

0.82

0.825 0.820

0.81

0.815

0.80

0.810 0.0

0.2

0.4

0.6

0.8

1.0

0.0

0.2

0.4

0.6

0.8

1.0

0.0

0.2

0.4

0.6

0.8

1.0

Figure 3: Sensitivity analysis of the interpolation coefficient α on Qwen2.5-7B-Instruct. We report Precision@K, MAP@K, and MRR@K under the importance, exploit-first, and patch-order preference scenarios. The dashed vertical line indicates the value used in the main experiments, α = 0.3.

or fusion result ranks the ground-truth top candidate at rank 1, while a cross indicates otherwise.

K

Use of AI Assistance

We used ChatGPT only as a writing assistance tool to improve the clarity, grammar, and readability of the manuscript. The tool was not used to generate research ideas, design the method, conduct experiments, produce experimental results, or draw scientific conclusions. All technical content, experimental design, implementation, analysis, and final claims were created and verified by the authors.

Case I — cve_rank_010363 (n = 10) Ranking Question Which vulnerabilities associated with Goodlayers should be addressed first to minimize risk? Candidate-Set Synopsis The candidate set contains legacy Travelon Express XSS/upload issues and recent GoodLayers vulnerabilities with vendor fixes. The patch-order ground truth favors recent patched GoodLayers CVEs, especially CVE-2025-39503 and CVE-2025-59580. Ground Truth Full ranking: CVE-2025-39503✓ (0.559) →CVE-2025-59580 (0.555) →CVE-2025-39502 (0.497) →CVE-2025-53342 (0.494) →CVE-2008-5864 (0.406) →CVE-2024-9458 (0.406) →CVE-2008-0184 (0.403) →CVE-2009-4617 (0.403) →CVE-2012-2938, CVE-2012-2939 (0.230). View Predictions and Fusion Global Enterprise User Fusion

CVE-2008-0184 →CVE-2009-4617 →CVE-2008-5864 CVE-2008-0184 →CVE-2009-4617 →CVE-2025-39503 CVE-2025-59580 →CVE-2025-39503 →CVE-2025-53342 CVE-2025-39503 →CVE-2025-59580 →CVE-2025-39502

GT#1 rank: 8; Top-1: × GT#1 rank: 3; Top-1: × GT#1 rank: 2; Top-1: × GT#1 rank: 1; Top-1: ✓

Analysis In this case, only fusion places GT#1 first and also matches the GT top-3 order. The global view ranks legacy CVEs highly, whereas enterprise and user place more weight on recent patched GoodLayers CVEs. The fitted weights (wg , we , wu ) = (−0.16, +0.36, +0.48) reflect this pattern by down-weighting the global view and increasing the contributions of enterprise and user.

Case II — cve_rank_011853 (n = 10) Ranking Question Which vulnerabilities from GE should be prioritized based on critical impact or widespread usage of their products? Candidate-Set Synopsis The candidate set contains industrial GE vulnerabilities and older web CVEs. The patch-order ground truth favors CVE-2014-0750, a path traversal vulnerability with exploit evidence, over several high-CVSS but lower-ranked industrial entries. Ground Truth Full ranking: CVE-2014-0750✓ (0.461) →CVE-2011-1565 (0.415) →CVE-2006-1216 (0.412) →CVE-2015-8735 (0.412) →CVE-2006-6198 (0.409) →CVE-2009-3967 (0.403) →CVE-2020-36549 (0.321) →CVE-2022-2948 (0.265) →CVE-2017-17576 (0.218) →CVE-2018-10613 (0.049). View Predictions and Fusion Global Enterprise User Fusion

CVE-2006-6198 →... CVE-2006-1216 →... CVE-2011-1565 →CVE-2014-0750 →... CVE-2014-0750 →CVE-2011-1565 →CVE-2015-8735

GT#1 rank: 6; Top-1: × GT#1 rank: 5; Top-1: × GT#1 rank: 2; Top-1: × GT#1 rank: 1; Top-1: ✓

Analysis Here, none of the single views ranks GT#1 first, but fusion places CVE-2014-0750 at the top. The fused ranking therefore does not reduce to majority voting over view-wise top-1 predictions; instead, support-based weighting recombines partial evidence across views under the selected policy configuration.

Algorithm 1 HARP: Hierarchical Adaptive Ranking with Preference-Adaptive Fusion for QueryBased CVE Prioritization Require: Query q, graph G, policy sets {Πl }, adapters A, preference-scenario support bank Bγ , coefficient α Ensure: Ranked CVE list π̂q 1: C ← R(q, G) {Retrieve candidate CVEs} 2: x ← EvidenceBuilder(q, C) {Build candidate feature summary} 3: for l = 1, . . . , L do 4: πl∗ ← PolicySelect(q, Πl ) 5: al ← Score(q, C, x, πl∗ ; A) 6: zl ← Normalize(al ) 7: end for ∗) 8: π ∗ ← (π1∗ , . . . , πL 9: S ← SampleSupport(Bγ , π ∗ ) 10: w ← FitFusionWeights(S) 11: Fadapt ← WeightedFuse({zl }L l=1 , w) L 12: Funi ← UniformFuse({zl }l=1 ) 13: F ← αFadapt + (1 − α)Funi 14: if TopKAgree({zl }L l=1 ) then 15: π̂q ← ConsensusTopK({zl }L l=1 , F ) 16: else 17: π̂q ← RankByScore(F ) 18: end if 19: return π̂q

Related documents

• ESLM: Risk-Averse Selective Language Modeling for Efficient Pretraining#1050755
• Knowledge-Enriched Structured EHR Features for 30-Day Hospital Readmission Prediction on MIMIC-IV#1109684
• The Flaw of Averages: Measuring Benchmark-Level Distributional Robustness#972966
• AutoRelAnnotator: Calibrated Model Cascades for Cost-Efficient Relevance Evaluation in Sponsored Search#307058
• Augmenting language models with information retrieval#8352