{"id":"e5849705-685d-42c4-8d39-a7297ca020a9","arxiv_id":"2601.06201","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"A weighted sum of CVSS, EPSS, and KEV indicators, marketed as a zero-day exposure model, is combined with compliance deadlines and set-cover optimization; the claimed 88% risk reduction is not backed by released artifacts.","lead":"RiskBridge is a proposed enterprise patching framework that fuses CVSS, EPSS, and CISA KEV data into a hand-weighted score, adds compliance-deadline logic, and uses set-cover optimization. The authors claim 88% risk reduction, 18-day SLA gains, and 100% top-3 precision, but provide no code, data, or evaluation protocol to support those numbers.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline metrics are not auditable: KEV is both an input feature (Eq. 1, Table 1) and the unstated ground truth, so Precision@3=1.00 and the 88% risk reduction may be artifacts of target leakage.","rationale":"The paper is best read as an engineering integration: the three modules are a weighted sum, policy rules, and set cover. The contribution, if any, is the claimed empirical outcome. That outcome is not reproducible from the manuscript. The most load-bearing assumption is that Precision@3=1.00 was computed against a non-contaminated label; if that assumption fails, all downstream operational claims (88% risk reduction, 18-day SLA tightening, ROI 4.7) lose their evidential base. One nuance: Table 3's CISA KEV Matching baseline scores 0.79, not 1.00, which could indicate the label is not simply current KEV membership. But because Section 4 names KEV as providing 'ground-truth binary labels' and never defines the label, the paper gives no way to determine whether the label is contemporaneous KEV, future KEV, or another exploit feed. That ambiguity is precisely the problem. The proposed test forces the authors to expose the label and temporal structure; until then, the central claim is unverified. This aligns with the reader's weakest assumption, so no verdict change is needed.","tokens_in":9396,"tokens_out":5310,"duration_ms":58512,"concrete_test":"Re-run the Table 3 evaluation with a date-stamped protocol: fix snapshot T (e.g., 2025-06-01), use features from EPSS/KEV as of T, candidate set = CVEs published before T, and label = CVE added to KEV during (T, T+90]. Exclude CVEs already in KEV at T from the evaluation or report with/without exclusion. If RiskBridge's Precision@3 drops below 1.00 or no longer beats the KEV baseline after removing the same-time KEV feature, leakage is confirmed; if it remains 1.00, the claim survives. Also report N, error bars, and the residual-risk formula used for the 88% figure.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central empirical claim—88% risk reduction, 18-day SLA tightening, Precision@3=1.00—rests on an evaluation protocol that is never specified. Section 4.1 reports Precision@3 as 'top-K exploit prediction accuracy' but does not define the label, the evaluation date, the candidate set, or the temporal split. The only candidate ground-truth source named in Section 4 is 'CISA KEV Catalog (2025)—offering ground-truth binary labels for known exploited vulnerabilities.' Meanwhile ZDES (Eq. 1) includes 0.2(1−KEV) as a scored feature and Table 1 categorizes any KEV-listed CVE as 'Urgent.' Thus KEV status is simultaneously a predictor and a plausible label. A ranker that simply places KEV-listed CVEs at the top would trivially achieve Precision@3=1.00 under that label, making the 25% compliance-gain and 20% ROI improvements over Tenable VPR (Table 3) and the '88% residual risk reduction' (Abstract/§6, never computed in §4) uninterpretable. I am not alleging fraud; I am claiming the manuscript provides no way to rule out this leakage, and the perfect score is exactly what leakage would produce. Even if the label is future KEV entries, the absence of dataset size, date-stamped snapshots, and release code means the result cannot be checked.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes RiskBridge, an enterprise vulnerability-prioritization framework that fuses CVSS v4, EPSS, and CISA KEV data through a Zero-Day Exposure Simulation (ZDES) scoring model, a Policy-as-Code compliance engine, and a set-cover ROI optimizer. The authors report Precision@3 = 1.00, F1 = 0.80, Compliance Gain = 19.3 days, ROI = 4.7 risk/hr, an 88% total risk reduction, and an 18-day SLA tightening relative to CVSS-only, EPSS, CISA KEV, and Tenable VPR baselines. The paper also includes an ablation study and two case studies intended to demonstrate operational impact.","tokens_in":9827,"tokens_out":5115,"duration_ms":54284,"significance":"If the evaluation were auditable, the paper would be a practical contribution to vulnerability management: it targets a real operational problem, combines multiple public intelligence sources, and emphasizes explainability via compliance-basis annotations and BII/ZDES traces. The deterministic, API-driven pipeline and the stated intent to release scripts are also strengths. However, the central evaluation as presented is not reproducible and the headline numbers are consistent with target leakage: KEV appears both as an input feature and as the only named ground-truth label, while the Precision@3 protocol is never defined. Because the primary claims rest on this evaluation, the paper cannot be accepted in its current form.","major_comments":[{"comment":"Precision@3 and downstream metrics are not defined against a specified ground-truth label, while KEV appears as both a predictor and the only named ground truth. §4 calls CISA KEV 'offering ground-truth binary labels for known exploited vulnerabilities'; Eq. (1) scores 0.2(1−KEV) and Table 1 marks any KEV-listed CVE as 'Urgent.' If the Precision@3 label is KEV membership, then a ranker that places KEV-listed CVEs at the top trivially achieves Precision@3 = 1.00. The paper never states the label definition, the evaluation date, the candidate CVE set, or a temporal split between feature and label, so the central result cannot be distinguished from this leakage artifact.","section":"§4.1, Table 3; Eq. (1); Table 1"},{"comment":"No dataset cardinality, date-stamped snapshots, or common evaluation set is given. Table 3 evaluates each baseline on a different 'Dataset' (NVD, EPSS, KEV, Mixed, NVD+EPSS+KEV), so the claimed 25% compliance-gain improvement and 20% ROI improvement over Tenable VPR are not apples-to-apples comparisons. No error bars, confidence intervals, or repeated trials are reported. This makes the quantitative superiority claims uncheckable.","section":"§4, Table 3"},{"comment":"The headline '88% reduction in residual risk' appears in the abstract and conclusion but is never computed, defined, or derived in Section 4. There is no residual-risk metric, formula, or measurement protocol. Similarly, the '18-day SLA tightening' is not connected to the Compliance Gain metric (19.3 days) or to any SLA simulation. These are load-bearing quantitative claims, and they are unsupported by the experimental section.","section":"Abstract, §6, §4"},{"comment":"The ablation study does not resolve the underlying evaluation problem. Removing ZDES or BII changes Precision@3 from 1.00 to 0.85/0.78, but because the label is never defined, those numbers carry the same ambiguity as the main result. The claimed module contributions (40%/35% drops) are not accompanied by any statistical test or confidence interval. Additionally, §4.2 states that ZDES uses 'EPSS and CVSS parameters in the absence of KEV listings,' which conflicts with Eq. (1) where 0.2(1−KEV) is explicitly scored; this inconsistency matters for interpreting what ZDES predicts.","section":"§4.2, §4.4, Eq. (1)"}],"minor_comments":[{"comment":"The axes in Figure 4 appear mismatched with the caption: the x-axis is labeled 'Compliance Gain (days)', the y-axis 'Risk Reduced', and the color scale 'CVSS Severity', while the title says 'ROI vs Compliance Gain Across CVEs.' ROI is not plotted.","section":"Figure 4"},{"comment":"The percentage claims in the text are not fully consistent with the table: 1.00/0.73 ≈ 1.37×, not 1.4×; (19.3−15.2)/15.2 ≈ 27%, not 26%; (4.7−3.4)/3.4 ≈ 38%, not 35%. The numbers are close but should be reconciled.","section":"§5.1, Table 5"},{"comment":"The Business Impact Index (BII) is described in prose but no formula is given, and the Policy-as-Code expression `Due = Base SLA × Threat(E) × Env` leaves Base SLA, Threat(E), and Env undefined. Since the paper stresses explainability, these definitions should be provided.","section":"§3"},{"comment":"The appendix says 'evaluation scripts will be released on GitHub,' but no repository URL or artifact version is given. In addition, 'Napkin AI' and 'Google Colab' appear as references, which is unusual and should be removed or properly justified.","section":"Appendix D"}],"recommendation":"reject","confidential_remarks":"The paper has a clear evaluation-validity problem that is central to all headline claims. The perfect Precision@3 is exactly what a trivial KEV-membership ranker would produce if KEV is both a feature and the label, and the manuscript does not provide enough protocol detail to rule that out. I am not questioning the authors' integrity, but the current submission is not auditable. The editor may want to require a full evaluation protocol — dataset size, temporal split, label definition, error bars, and released code/data — before any resubmission is considered."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, quick read on RiskBridge. The core idea—combine EPSS, CVSS, and KEV status into a single score, wrap it with Policy-as-Code compliance SLAs and a set-cover optimizer—is a reasonable engineering recipe. The paper's related work is fair: it cites EPSS, Shimizu-Hashimoto, and others, and it's honest that ZDES is a weighted sum of existing signals. The system-level thinking is coherent; the compliance-SLA mapping is a nice practical touch. I'd believe this could be a useful internal tool.\n\nThe problem is the evaluation. Section 4 never defines the ground truth or the temporal split. The only candidate label mentioned is CISA KEV, and KEV is also an input feature (Eq. 1, Table 1). So Precision@3=1.00 is exactly what you'd get if the ranker just puts KEV-listed CVEs on top. The perfect score is a red flag, not a result. The 88% residual risk reduction appears only in the abstract and conclusion; it's never computed. No dataset size, no error bars, no released code or data—the checklist says 'will be released,' which is a promise, not evidence. The case studies read like anecdotes with convenient numbers.\n\nThere's a kernel of a useful contribution: the Policy-as-Code engine, the ROI formulation, and the idea of linking patch decisions to compliance deadlines. But as a research preprint, the central empirical claims are unsupported. The novelty is thin—ZDES is a hand-tuned linear combination, and the optimizer is standard weighted set cover. The paper's own related work already includes integrated models.\n\nIf a student were writing this, I'd tell them to redo the evaluation with a proper temporal split (train on past, test on future KEV entries), specify the label, report variability, and release the code. As it stands, I wouldn't cite the numbers, but I'd mention the framework as a design pattern in a survey. For peer review: a serious editor would desk-reject this version because the load-bearing evidence is missing. If they add a real protocol, it could become a passable systems paper.\n\nNet: not a takedown—the engineering is plausible—but the research claims don't survive contact with the methods. Maybe show it to students as a warning about target leakage.\n\nRecommendation: don't send to peer review in this state; ask for a major rewrite with a real evaluation.","headline":"A plausible engineering integration pulled down by a non-auditable evaluation; the KEV circularity makes the headline numbers uninterpretable.","tokens_in":10339,"tokens_out":2581,"would_cite":false,"duration_ms":27858,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"RiskBridge claims a compliance-aware, explainable pipeline turns CVE feeds into patch decisions that cut residual risk by 88% and tighten patch SLAs by 18 days, with near-perfect top-3 exploit prediction precision.","keywords":["vulnerability prioritization","exploit prediction","compliance-aware patching","CVSS","EPSS","CISA KEV","ROI optimization","explainable AI"],"falsifier":"Take a historical cutoff date, run RiskBridge using only KEV, EPSS, and CVSS data available before that date, then measure Precision@3 against CVEs that first appear in the KEV catalog after the cutoff. If precision drops well below 1.00, the reported perfect score reflects label leakage rather than predictive power.","tokens_in":9294,"feed_emoji":"🛡️","tokens_out":3496,"duration_ms":34616,"temperature":0.7,"pith_summary":"RiskBridge aims to turn raw CVE feeds into business-aligned patch priorities by combining three components: a probabilistic exploit-likelihood model (ZDES), a policy-as-code engine that derives SLA deadlines from compliance rules, and an ROI optimizer that selects patch bundles with maximal risk reduction per hour. The paper argues that this integration substantially outperforms CVSS-only, EPSS-only, KEV matching, and a commercial priority rating system, reporting 88% residual risk reduction, 18-day SLA tightening, Precision@3 = 1.00, and ROI = 4.7 risk units per hour. If these results hold, RiskBridge would give security teams an auditable reason for each patch decision, something current black-box commercial tools do not provide.","feed_headline":"Patch scheduling with RiskBridge cuts risk 88% and SLAs 18 days","feed_subtitle":"Probabilistic exploit scoring plus policy-coded deadlines and ROI optimization outranks CVSS, EPSS, KEV, and Tenable VPR.","key_machinery":"The central mechanism is the Zero-Day Exposure Simulation (ZDES) score: ZDES = 0.35·EPSS + 0.3·(CVSS/10) + 0.2·(1−KEV) + 0.15·Recency. It converts three independent public intelligence sources into a single forecast of near-term exploitation. The other load-bearing components are the Policy-as-Code Engine, which compiles PCI DSS 6.3.3 and NIST SP 800-53 requirements into SLA deadlines annotated with a due_basis for auditability, and a weighted set-cover ROI optimizer that maximizes cumulative risk reduction per patch hour.","core_discovery":"The paper's central claim is that exploit likelihood, business impact, and compliance deadlines can be fused into a single explainable priority score, and that doing so yields empirically strong remediation outcomes on public CVE data. RiskBridge's ZDES model combines EPSS probability (weight 0.35), CVSS severity (0.30), absence from the CISA KEV list (0.20), and vulnerability recency (0.15) into a near-term exploitability estimate. A Business Impact Index blends severity, exploitability, asset criticality, and patch effort into a normalized 0–1 score, while a policy engine maps PCI DSS and NIST rules to concrete due dates, and a weighted set-cover optimizer minimizes redundant patching. The","pith_inferences":["The paper leaves implicit that the ZDES weights (0.35/0.30/0.20/0.15) are hand-set; a natural testable extension is to learn these weights from historical exploit outcomes, which could either strengthen or undermine the reported gains.","The KEV-absence term in ZDES creates a potential circularity risk: if the evaluation's positive labels are KEV entries, the (1−KEV) feature could encode the label itself. A clean holdout test using future KEV additions as ground truth would separate genuine prediction from labeling feedback.","The compliance-gain metric is computed relative to SLA deadlines the policy engine itself sets; an independent auditor would need to verify that these deadlines match the external regulatory text, not just the engine's interpretation."],"forward_implications":["If the ZDES weighting is sound, security teams can produce a dynamic, daily-updated priority queue rather than relying on static CVSS severity.","If the policy engine works as described, compliance deadlines (e.g., PCI DSS one-month patching) become machine-enforced, with each recommendation traceable to a specific regulation.","If the ROI optimizer is correct, organizations can cover more CVEs with fewer patches—reported 71% coverage and 1.5 CVEs per patch effort—reducing remediation cost.","If the evaluation is uncontaminated, RiskBridge's Precision@3 of 1.00 suggests near-perfect identification of the top-three most likely exploited CVEs in the test period, which would beat all four baselines by a substantial margin.","The reported 18-day SLA tightening implies that shifting from severity-only to exploit/compliance-aware scheduling can materially reduce mean time to remediate."],"fun_headline_variants":["RiskBridge fuses CVSS, EPSS, KEV into business-aligned patches","Patches prioritized by exploit odds, compliance, ROI in one score","88% risk cut, 18-day SLA gain via explainable patch ranking","From static CVSS to dynamic business-aligned patch priorities"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The evaluation assumes that Precision@3 = 1.00 is measured against a ground truth that is independent of the KEV status used as a feature in ZDES; if the model is effectively predicting the same KEV list it consumes, the headline accuracy and the 88% risk reduction collapse.","fun_headline_variants_meta":{"raw":{"variants":["RiskBridge fuses CVSS, EPSS, KEV into business-aligned patches","Patches prioritized by exploit odds, compliance, ROI in one score","88% risk cut, 18-day SLA gain via explainable patch ranking","From static CVSS to dynamic business-aligned patch priorities"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000109,"raw_usage":{"total_tokens":905,"prompt_tokens":783,"completion_tokens":122,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":527,"completion_tokens_details":{"reasoning_tokens":55}},"tokens_in":527,"tokens_out":122,"duration_ms":2349,"temperature":1.0,"reasoning_tokens":55,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T11:53:52.382552+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a historical cutoff date, run RiskBridge using only KEV, EPSS, and CVSS data available before that date, then measure Precision@3 against CVEs that first appear in the KEV catalog after the cutoff. If precision drops well below 1.00, the reported perfect score reflects label leakage rather than predictive power.","supporting_citations":[],"review_version":1}