KEVGraph: Exploitation-Aware Dependency Vulnerability Remediation Daniel Okumu Omondi
arXiv:2609.24164v1 [cs.CR] 21 Sep 2026
daniel [email protected] [email protected]
concrete, measurable exploitation risk—not a theoretical score. Prioritising KEV elimination over severity-bucket ordering is directly mandated under CISA’s Binding Operational Directive (BOD) 22-01, which requires federal civilian agencies to remediate KEV-listed vulnerabilities within strict deadlines and has been broadly adopted as a best-practice framework [1]. KEVG RAPH addresses three practical questions simultaneously: 1) What is the minimum number of upgrade actions required to cover all coverable vulnerabilities? 2) In what order should those actions be performed to eliminate actively-exploited (KEV-listed) vulnerabilities as early as possible? 3) Can the plan be independently verified—can we confirm, without re-running the pipeline, that the plan covers every coverable vulnerability? We make the following contributions: • An end-to-end open-source pipeline (collect → fetch → parse → join → fixes → plan → evaluate → plot) that reproduces all results from raw lockfile data. • A KEV-aware greedy set-cover planner with classical approximation guarantees: O(log |U |) factor for minimum set cover [10] and (1 − 1/e) of maximum coverage under a budget [9]. • An exact ILP formulation of minimum-set-cover remediation with proven optimality in plan cardinality. • The AUCCKEV metric—Area Under the KEV Coverage Curve—which measures how early a plan eliminates I. I NTRODUCTION actively-exploited vulnerabilities, independent of plan Modern software projects depend on large transitive depenlength. dency trees. The npm ecosystem alone hosts over two million • Per-installed-version fix generation that creates genuine packages; Java (Maven) and Python (PyPI) ecosystems are set-cover overlap, enabling both planners to select a similarly expansive. The average project carries hundreds of minimum-cardinality subset of upgrade actions. third-party packages, many of which contain known security • Statistical evaluation against four baselines with a 30-seed vulnerabilities. random ensemble and empirical 95th-percentile intervals. Automated tools such as GitHub Dependabot [5] and npm • A pluggable ecosystem-adapter architecture demonstrated audit [6] surface vulnerability lists, but present them without on three package managers (npm, Maven, PyPI), showing strategic ordering. When a developer has limited time, which consistent KEV-prioritisation gains across ecosystems. package should be upgraded first? The dominant practice— • Machine-verifiable remediation certificates supporting ordering by CVSS base score or severity label—conflates automated compliance workflows. theoretical severity with actual exploitation risk. II. BACKGROUND The CISA Known Exploited Vulnerability (KEV) catalogue [1] provides an authoritative, continuously updated list of A. CISA Known Exploited Vulnerability Catalogue vulnerabilities confirmed to be actively exploited in the wild. A The CISA KEV catalogue [1] lists CVE identifiers for KEV-listed vulnerability in a production dependency represents which CISA has confirmed active in-the-wild exploitation. Each
Abstract—Dependency scanning tools surface hundreds of vulnerabilities but provide no exploitation-aware ordering—leaving practitioners to decide which upgrades to perform first with no principled guidance. The dominant practice, ordering by CVSS severity, is structurally misaligned with active exploitation: in our npm corpus, 186 non-KEV vulnerabilities carry CVSS > 8, all outranking three CISA Known Exploited Vulnerability (KEV [1])listed packages and causing CVSS-first tools to defer the first actively-exploited fix by 17 upgrade actions. KEVG RAPH is an eight-stage pipeline that frames remediation as a KEV-aware setcover problem: it constructs per-repository dependency graphs from lockfiles, joins them against OSV [2] and the CISA KEV catalogue, and produces a minimum-cardinality upgrade plan ordered to eliminate actively-exploited vulnerabilities as early as possible via exact Integer Linear Programming (ILP) or a KEV-aware greedy algorithm. Evaluated on 924 real-world npm repositories (1,046 vulnerabilities, 5 KEV-listed), the ILP planner achieves AUCCKEV = 0.997 vs. a random-baseline mean of 0.663 (95% CI [0.519, 0.831], n = 30), resolves the first KEV vulnerability at plan step 1, and requires only 417 upgrade actions—15.9% fewer than the random mean of 495.4. CVSS-first and Dependabot-style ordering are strictly dominated: they defer the first KEV fix to step 18 while requiring more actions (419 and 421, respectively). The framework generalises: Maven (1,200 repos) achieves AUCCKEV = 0.988 vs. random mean 0.486; PyPI (300 repos) achieves AUCCKEV = 1.000. Each plan is accompanied by a machine-verifiable certificate enabling automated compliance verification under CISA BOD 22-01. Index Terms—vulnerability remediation, dependency graphs, CISA KEV, set cover, integer linear programming, npm, Maven, PyPI, software supply chain security, exploitation-aware prioritisation
entry records: a CVE ID, vendor/product identifiers, a short description, the date the entry was added (dateAdded), and a remediation due date (dueDate) for federal agencies. As of March 2026 the catalogue contains over 1,200 entries. Unlike CVSS scores, KEV membership directly reflects observed attacker behaviour. B. OSV Vulnerability Database The Open Source Vulnerability (OSV) database [2] aggregates security advisories from GitHub Security Advisories (GHSA), NVD, and ecosystem-specific feeds. Each record carries: a primary identifier (typically GHSA-* for npm), CVE aliases, affected package ranges, fixed versions, CVSS vectors, and textual summaries. KEVG RAPH queries the OSV batch API (/v1/querybatch) to obtain per-package vulnerability stubs, then fetches full records via GET /vulns/{id} for CVE alias extraction. C. EPSS The Exploit Prediction Scoring System (EPSS) [3] from FIRST.org provides daily-updated probabilities (0–1) that a given CVE will be exploited in the wild within the next 30 days. KEVG RAPH enriches each vulnerability record with EPSS scores via the FIRST API and uses EPSS as a tie-breaker in baseline comparisons. D. Lockfiles and Dependency Graphs A lockfile records the exact resolved version of every dependency installed in a project. KEVG RAPH parses each lockfile into a directed acyclic graph (DAG) stored as GraphML, with nodes annotated by package name and version, and edges representing depends-on relationships. npm uses package-lock.json (v1/v2/v3 formats), PyPI uses poetry.lock (TOML), and Maven uses pom.xml. Because Maven has no ecosystem-standard lockfile, KEVG RAPH’s Maven adapter extracts direct declared dependencies only; transitive resolution is not performed. This is a deliberate conservative choice discussed further in Section VIII. III. T HREAT M ODEL Assets. The protected assets are the application runtimes that execute package code across any supported ecosystem. Adversary. We model an adversary who exploits a publicly disclosed vulnerability in a transitive dependency. The adversary has knowledge of the CVE (it is publicly listed) and exploits it remotely or through a supply-chain mechanism. We do not model zero-day vulnerabilities or adversaries with package-registry write access. Vulnerability condition. A package-version pair (p, v) is vulnerable if the OSV database contains a record for package p whose affected range includes version v. It is KEV-critical if at least one CVE alias of that record appears in the CISA KEV catalogue. Remediation action. A remediation action is an in-place upgrade of package p from installed version vfrom to a fixed version vfix > vfrom in the project’s dependency manifest. We
assume each upgrade can be performed independently (no circular dependencies) and that the fixed version is obtainable from the relevant package registry. Out of scope. Runtime isolation, sandboxing, networklevel mitigations, and vulnerabilities in non-package-manager dependencies are out of scope. IV. P ROBLEM F ORMULATION Inputs. • A set of vulnerability records V = {v1 , . . . , vm }, each annotated with KEV status κ(v) ∈ {0, 1}, CVSS score σ(v) ∈ [0, 10], and EPSS score ϵ(v) ∈ [0, 1]. • A set of candidate fixes F = {f1 , . . . , fn }, where each fix fi = (pkgi , vifrom , vifix , Si ) specifies an upgrade action and the set Si ⊆ V of vulnerabilities it resolves. Sn Universe. Let U = i=1 Si ⊆ V be the set of coverable vulnerabilities—those addressed by at least one candidate fix. Remediation plan. A remediation plan is an ordered sequence π = (fπ(1) , fπ(2) , . . . , fπ(k) ) of distinct fixes from F. ∗ Minimum set-cover Skobjective. Find a plan π of minimum length k such that i=1 Sπ(i) = U . This is equivalent to weighted set cover with unit weights, which is NP-hard in general [8]. KEV-early objective. Among all plans π of minimum length, prefer those that minimise the rank at which the last KEV-listed vulnerability in U is first covered. Formally, let rankπ (v) be the step index at which vulnerability v is first covered by π; then minimise maxv∈U :κ(v)=1 rankπ (v). V. T HE KEVG RAPH F RAMEWORK A. Pipeline Architecture KEVG RAPH is implemented as an eight-stage Python pipeline: 1) Collect – query GitHub Search API for repositories with manifest files above a stars threshold; write a manifest CSV. 2) Fetch – download the lockfile or manifest for each repository. 3) Parse – dispatch to the appropriate ecosystem adapter; parse into a directed dependency graph (GraphML) annotated with package name and version. 4) Join – enumerate unique (package, version) pairs across all graphs; batch-query OSV; fetch full records for CVE alias extraction; enrich with EPSS; match CVE aliases against CISA KEV; write data/vulns.json. 5) Fixes – for each vulnerable package, collect all installed versions from corpus graphs; generate one CandidateFix per (package, installed-version) pair where installed-version < fixed-version; write data/fixes.json. 6) Plan – run greedy and ILP planners; run four baselines including 30-seed random ensemble; store all plans in data/evaluation.json.
7) Evaluate – compute all metrics for every plan; compute Algorithm 1 KEV-Aware Greedy Set-Cover empirical 95th-percentile intervals for the random ensem- Require: fixes F, vulns V, KEV function κ 1: R ← U ; π ← [ ]; F ′ ← F ble; write data/results.csv. 2: while R = ̸ ∅ and F ′ ̸= ∅ do 8) Plot – generate publication figures. ∗ 3: f ← arg maxf ∈F ′ score(f, R, κ) 4: if Sf ∗ ∩ R = ∅ then break B. Ecosystem Adapters 5: end if 6: R ← R \ Sf ∗ KEVG RAPH uses a pluggable EcosystemAdapter in7: Append f ∗ to π; remove f ∗ from F ′ terface with implementations for three package managers: 8: end while npm. Parses package-lock.json (v1, v2, and v3 for9: return π mats), extracting all transitive dependencies with exact resolved versions. The full transitive closure is used for vulnerability matching. E. KEV-Aware Greedy Set-Cover Planner PyPI. Parses poetry.lock (TOML), which records all Algorithm 1 describes the greedy planner. At each iteration resolved transitive dependencies. Development dependencies we select the fix f ∗ that maximises are identified via Poetry 1.2+ groups metadata. Maven. Parses pom.xml and extracts direct declared |Sf ∩ R|, dependencies only. Maven has no ecosystem-standard lockfile X κ(v), analogous to package-lock.json; full transitive resolu v∈Sf ∩R tion would require invoking the Maven build toolchain, which score(f ) = max σ(v), is out of scope. Version expressions containing variables or v∈S ∩R f ranges are excluded when a concrete version cannot be resolved max ϵ(v) statically. This conservative approach under-counts transitive v∈Sf ∩R vulnerabilities and is noted as a limitation (Section VIII). using lexicographic comparison, where R is the set of currently uncovered vulnerabilities. The primary objective (first component) maximises the number of newly-covered vulnerabilities; C. Vulnerability Join the secondary, tertiary, and quaternary tie-breakers prefer fixes The join stage (Stage 4) performs three network round-trips that cover KEV vulnerabilities, high-CVSS vulnerabilities, and per unique vulnerability: (i) a batch OSV query to obtain stub high-EPSS vulnerabilities, respectively. records; (ii) a full OSV record fetch to obtain CVE aliases; For minimum set cover, the greedy algorithm has plan length (iii) an EPSS batch query. All responses are disk-cached so at most k ∗ · ⌈ln |U | + 1⌉ [10]. For maximum coverage under a subsequent runs are instantaneous. fixed budget B, it achieves at least 1 − 1/e of the maximum CVSS base scores are computed from OSV severity vector possible coverage [9]. These are distinct guarantees for distinct strings using a pure-Python implementation of the CVSS 3.1 problem formulations; KEVG RAPH uses the greedy strategy formula [4]. OSV stores CVSS as a vector string (e.g., CVS for the minimum set-cover objective. S:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) rather than a numeric score; the pipeline parses and evaluates F. ILP Exact Planner this vector in-house without external scoring libraries. The exact planner solves the following binary integer programme: n X D. Per-Version Candidate Fix Generation min xi (1) A naive approach generates one fix per vulnerable package, but this yields zero set-cover overlap—every vulnerability appears in exactly one fix, making the greedy and ILP solutions trivially identical. KEVG RAPH instead generates one fix per (package, installed-version) pair: for each vulnerable package p with known fixed version v ∗ , and for each installed version vj < v ∗ found across corpus graphs, we create: f = p, vj , v ∗ , {v ∈ Vp : vj < vvfix } where Vp is the set of vulnerabilities for package p. This creates genuine overlap: a vulnerability v that affects all installed versions of p will appear in |{j : vj < v ∗ }| different candidate fixes, giving the set-cover planners real optimisation choices.
i=1
subject to
∀v ∈ U :
X
xi ≥ 1
(2)
i: v∈Si
xi ∈ {0, 1}
∀i
(3)
where xi = 1 indicates that fix fi is included in the plan. After solving with CBC [11] (via the PuLP interface [12]), the selected fixes are ordered using the same KEV-aware priority function as the greedy planner. The ILP is provably optimal in remediation cardinality. The post-processing ordering step (KEV-aware priority) is a heuristic applied to the already-selected optimal set; joint optimality of cardinality and KEV-early ordering is not guaranteed in general.
G. The AUCCKEV Metric Standard metrics such as T1 (fraction covered after the first action) and T5 (after five actions) are informative but orderinsensitive with respect to KEV timing. We introduce Area Under the KEV Coverage Curve (AUCCKEV ), defined as: 1 X AUCCKEV (π) = max n − rankπ (v) + 1, 0 n · |K| v∈K
where n = |π| is the total number of plan steps, K = {v ∈ U : κ(v) = 1} is the set of KEV-listed coverable vulnerabilities, and rankπ (v) is the step at which vulnerability v is first covered. AUCCKEV ranges from 0 to 1. A plan that covers all KEV vulnerabilities at step 1 achieves AUCCKEV = 1; a plan that never covers any achieves AUCCKEV = 0. Crucially, AUCCKEV is order-sensitive: two plans that eventually cover all KEV vulnerabilities but differ in the step at which they do so receive different AUCCKEV scores. The formula is equivalent to the average fraction of KEV vulnerabilities covered at each step, integrated uniformly over the plan. It can be computed in O(|K|) time once the per-KEV ranks are known.
TABLE I S AMPLE OF NPM REPOSITORIES IN THE CORPUS Repository
Stars
segment-boneyard/nightmare BrasilAPI/BrasilAPI evolus/pencil dice2o/BingGPT anvaka/city-roads locomotivemtl/locomotive-scroll codecombat/codecombat amsul/pickadate.js shentao/vue-multiselect kska32/ebooks FaisalUmair/udemy-downloader-gui ractivejs/ractive ExactTarget/fuelux ConsenSys-archive/ganache-ui sweet-js/sweet-core
19,972 10,270 9,586 9,046 9,029 8,704 8,437 7,681 6,783 6,833 6,248 5,926 5,152 4,716 4,568
(web frameworks, desktop applications, data tools, UI libraries, blockchain tooling). A representative sample appears in Table I. The npm pipeline produced the following corpus statistics: • 924 dependency graphs (GraphML). • 1,046 unique vulnerability records from OSV. • 5 KEV-listed vulnerabilities affecting electron (2), jquery H. Remediation Certificates (1), puppeteer (1), and vite (1). • 2,741 per-version candidate fixes. Each remediation plan is accompanied by a certificate: the • 937 coverable vulnerabilities (109 vulns have no known set of (fi , vj ) pairs asserting that fix fi covers vulnerability vj . fix and are excluded from planning). The certificate allows independent verification—a third party can confirm coverage without re-running the planner, in time The five KEV vulnerabilities and their properties are: proportional to the number of certificate edges. • GHSA-qqvq-6xgj-jw8g (electron): libvpx heap buffer Formally, given the certificate C ⊆ F × U , the verifier overflow in VP8 encoding (CVSS 8.8; KEV added 2023checks: 10-02) ∀v ∈ U : ∃(f, v) ∈ C with f ∈ π • GHSA-j7hp-h8jx-5ppr (electron): libwebp OOB write in BuildHuffmanTable (CVSS 8.8; KEV added 2023Verification times on our corpora are reported in Table II. 09-13) • GHSA-jpcq-cgw6-v4j6 (jquery): Potential XSS vulI. Theoretical Properties nerability (CVSS 6.9; KEV added 2025-01-23) Proposition 1 (ILP Cardinality Optimality). The ILP planner • GHSA-c2gp-86p4-5935 (puppeteer): Use-after-free produces a planPof minimum cardinality. By construction: the (CVSS 6.5; KEV added 2022-05-23) ILP minimises xi subject to full-coverage constraints; any • GHSA-4r4m-qw57-chr8 (vite): server.fs.deny feasible solution with fewer selected fixes would violate at least bypass via ?import query (CVSS 5.3) one coverage constraint. Multi-ecosystem corpora. To evaluate ecosystem generProposition 2 (Greedy Set-Cover Bound). Let k ∗ be the alisability, we applied the same pipeline (with ecosystemoptimal plan length. The greedy planner produces a plan appropriate adapters) to: (i) 1,200 Maven repositories (pom.xml, of length at most k ∗ · ⌈ln |U | + 1⌉ [10], the classical set- direct dependencies only) yielding 295 coverable vulnerabilities cover approximation ratio. Separately, as a maximum-coverage across 7 KEV-listed entries (KEV density 2.37%); and (ii) 300 algorithm under a cardinality budget, the greedy strategy PyPI repositories (poetry.lock) yielding 818 coverable vulnerachieves at least (1 − 1/e) of the maximum achievable abilities with 1 KEV-listed entry (density 0.12%). Maven’s coverage [9]; these are distinct guarantees for distinct problem higher KEV density reflects the prevalence of high-profile variants. Java library vulnerabilities (Apache Struts, Tomcat, Spring Framework, and Log4j) in the KEV catalogue. VI. E MPIRICAL E VALUATION A. Dataset
B. Baselines
npm corpus. We collected 924 open-source GitHub repositories with package-lock.json lockfiles, selected by GitHub stars and representativeness across application domains
We compare KEVG RAPH against four baselines, all of which use the same candidate fix set and the same set-cover selection logic (i.e., only non-redundant fixes are included):
T1 Fraction of coverable vulnerabilities eliminated after the first upgrade action. T5 Fraction eliminated after the first five upgrade actions. AUCCKEV Area Under the KEV Coverage Curve (Section V-G). Range [0, 1]; higher means KEV vulnerabilities are fixed earlier. kev first rank The plan step at which the first KEV-listed vulnerability is first covered. Lower is better. #actions Total upgrade actions required to cover all 937 coverable vulnerabilities. cert size Number of (fix, vuln) certificate edges. verify time Wall-clock time (seconds) to verify that the plan covers all coverable vulnerabilities.
Non-KEV (1041 vulns) KEV-listed (5 vulns)
1.0
vite electron (EPSS(libwebp, 0.744) puppeteer EPSS 0.941) (EPSS 0.896)
0.8
186 non-KEV vulns with CVSS > 8
0.6 jquery (EPSS 0.369)
0.4
Low EPSS
0.2
despite KEV electron (libvpx, EPSS 0.048)
0.0 0
2
4
6
8
CVSS Base Score
10
Fig. 1. CVSS structurally misorders the remediation queue: 186 nonKEV vulnerabilities outrank three of five KEV-listed packages in severity ordering, causing CVSS-first to defer the first KEV fix 17 steps. CVSS base score vs. EPSS 30-day exploitation probability for all 1,046 npm vulnerabilities (grey); the 5 KEV-listed vulnerabilities are highlighted as diamonds. This is not a corner case: with CVSS scores of 5.3 (vite), 6.5 (puppeteer), and 6.9 (jquery), three KEV-listed packages fall below 186 non-KEV vulnerabilities— including 118 with CVSS > 9.0—in severity ordering. The result is a deterministic 17-step window in which actively-exploited packages remain unpatched while theoretically severe but unexploited CVEs are addressed first. EPSS partially corrects for exploitation risk (four of five KEV vulnerabilities have EPSS > 0.35), but electron/libvpx (EPSS = 0.048) is confirmed actively exploited by CISA yet invisible to the EPSS probability model—motivating the KEV catalogue as the authoritative primary ordering signal.
Step at which each KEV vulnerability is first covered (green = early, red = late; ILP covers all 5 KEVs by step 4) KEVGraph (ILP)
1
1
2
3
4
KEVGraph (Greedy)
2
2
4
47
155
D. Main Results (npm)
EPSS-first
1
1
5
18
4
The central result is that KEVG RAPH (ILP) achieves the trifecta: minimum upgrade count (417 actions), first KEV vulnerability resolved at step 1, and AUCCKEV = 0.997— all simultaneously optimal. CVSS-first and Dependabot, by contrast, require more actions (419 and 421) while deferring the first KEV fix to step 18. More work; worse exploitationaware ordering. The four figures below build the argument from root cause to statistical proof. Figure 1 establishes why severity-based ordering fails: 186 non-KEV vulnerabilities structurally outrank three of the five KEV-listed packages in CVSS ordering. Figure 2 shows the direct consequence: a per-plan, per-KEV heatmap that makes the exposure window quantitatively unavoidable. Figure 3 traces the trajectory: in the first 30 upgrade actions, KEVG RAPH covers all KEV vulnerabilities in four steps; CVSS-first and Dependabot register zero. Figure 4 delivers the statistical proof : the ILP AUCCKEV of 0.997 lies 0.166 above the random baseline’s 95% CI upper bound, ruling out chance. Table II reports all metrics.
CVSS-first
18
18
88
242
251
Dependabot
18
18
234
287
314
Random
20
20
40
1 Dependabot’s severity-bucket ordering is described at https: //docs.github.com/en/code-security/dependabot/dependabot-security-updates/ about-dependabot-security-updates. Our model captures the severity-first, alphabetical tie-breaking behaviour; it does not replicate ecosystem-specific scoring adjustments, patch-availability weighting, or alert-freshness signals present in the production implementation.
electron electron vite (libvpx, CVSS (libwebp, 8.8) CVSS 8.8)(CVSS 5.3)
199
279
jquery (CVSS 6.9)
puppeteer (CVSS 6.5)
420 100
10
Plan step (log scale)
C. Metrics
CVSS score does not predict active exploitation (KEV membership) High CVSS exploited; EPSS correlates better but has critical outliers EPSS Score (30-day exploitation probability)
Random Fixes are shuffled with a fixed random seed. This baseline estimates the performance of an uninformed practitioner. We run 30 seeds (0–29) and report mean and 95% percentile CI. CVSS-first Fixes are sorted by the maximum CVSS score of their covered vulnerabilities, descending. This simulates tools that order purely by theoretical severity. EPSS-first Fixes are sorted by the maximum EPSS probability of their covered vulnerabilities, descending. This simulates exploitation-probability-aware tools. Dependabot Fixes are sorted by severity bucket (Critical > High > Medium > Low) then alphabetically by package name within each bucket. This is a simplified approximation of Dependabot-style ordering [5]1 ; actual Dependabot behaviour includes additional heuristics not modelled here.
1
Fig. 2. CVSS-first and Dependabot leave every KEV vulnerability open through the first 17 upgrade actions; KEVG RAPH (ILP) closes all five in four steps. Per-plan, per-KEV coverage heatmap (npm corpus; green = early, red = late; cell value = plan step at first coverage). KEVG RAPH (ILP) reaches full KEV coverage at step 4 versus step 251 for CVSS-first and step 314 for Dependabot—a 62–79× longer exposure window. During those 17 initial steps, an attacker with knowledge of the KEV catalogue faces zero remediating actions against any of the five confirmed active-exploit vulnerabilities. EPSSfirst matches the ILP on kev first rank (= 1) but misses electron/libvpx at step 4, reaching full coverage later.
Key findings. •
ILP achieves the trifecta simultaneously. kev first rank = 1 (first action upgrade:[email protected] → @35.7.5, covering 2 KEV vulnerabilities immediately), AUCCKEV = 0.9971 (2nd-highest possible after a hypothetical
TABLE II F ULL EVALUATION ON THE NPM CORPUS (924 REPOS , 937 COVERABLE VULNERABILITIES , 5 KEV- LISTED ). KEVG RAPH (ILP) ACHIEVES THE LOWEST KEV FIRST RANK (= 1), HIGHEST AUCCKEV (= 0.997), AND MINIMUM # ACTIONS (= 417)— SIMULTANEOUSLY OPTIMAL ON ALL THREE PRIMARY OBJECTIVES . CVSS- FIRST AND D EPENDABOT DEFER THE FIRST KEV FIX TO STEP 18 WHILE REQUIRING more UPGRADE ACTIONS (419 AND 421), DEMONSTRATING THAT SEVERITY- BUCKET ORDERING IS STRICTLY DOMINATED : MORE WORK , WORSE EXPLOITATION - AWARE ORDERING . H IGHER T1 /T5 /AUCCKEV IS BETTER ; LOWER KEV FIRST RANK AND # ACTIONS IS BETTER . R ANDOM REPORTS SEED = 0; EMPIRICAL CI IN TABLE III. Plan KEVGraph (ILP) KEVGraph (Greedy) EPSS-first CVSS-first Random (seed=0) Dependabot
T1
T5
AUCCKEV
kev first rank
#actions
cert size
verify time (s)
0.0235 0.0352 0.0235 0.0011 0.0021 0.0011
0.0811 0.1121 0.0822 0.0512 0.0139 0.0053
0.9971 0.9017 0.9885 0.7079 0.7797 0.5886
1 2 1 18 20 18
417 417 417 419 502 421
937 937 937 937 937 937
0.221 0.211 0.192 0.313 0.210 0.192
KEV vulnerability coverage in first 30 upgrade actions ILP covers all 5 KEVs by step 4; CVSS/Dependabot stay at 0 until step 18 KEV vulnerabilities covered
5
0.7797
Random
All 5 KEVs covered
ILP: all 5 covered by step 4
4
KEV prioritisation score (AUCCKEV) per plan ILP exceeds random 95th-percentile CI upper bound 0.5886
Dependabot
0.7079
CVSS-first
3
0.9885
EPSS-first 2
0
0.9017
KEVGraph (Greedy)
1
KEVGraph (Greedy) KEVGraph (ILP) Random
0
5
10
15
20
Number of upgrade actions
CVSS-first EPSS-first Dependabot
25
Gap: 0.167 above CI Random 95% CI [0.519, 0.831] Random mean (0.663) 0.9971
KEVGraph (ILP) 0.5 30
Fig. 3. KEVG RAPH (ILP) achieves full KEV coverage in 4 steps; CVSSfirst and Dependabot register zero KEV coverage across the entire 30step window. KEV-specific coverage trajectory over the first 30 upgrade actions (npm corpus, 5 KEV-listed vulnerabilities). Unlike total-coverage curves—where all plans converge to 100% at step 417 and ordering differences vanish—this view isolates the exploitation-risk ordering objective. KEVG RAPH (Greedy) covers 3 of 5 KEV vulnerabilities by step 4 but reaches full KEV coverage only at step 155; the delay stems from a non-KEV fix selected at step 1 under coverage-maximising greedy logic. The 30-step window captures the decision horizon for a practitioner triaging a backlog under a one-sprint remediation budget.
oracle), and 417 upgrade actions (ILP-proven minimum). Full KEV coverage is reached in four steps: electron at step 1, vite at step 2, jquery at step 3, puppeteer at step 4. No other plan achieves all three objectives simultaneously. • Severity-based ordering is strictly dominated: more actions, worse KEV ordering. CVSS-first requires 419 actions (2 more than ILP) and defers the first KEV fix to step 18. Dependabot requires 421 actions and also defers to step 18. These plans are not just suboptimal in KEV ordering—they are also less efficient in total upgrade count. The conclusion is unambiguous: replacing CVSS-first with KEVG RAPH reduces both dimensions of remediation cost. • The mechanism is structural, not accidental. Figure 1 shows that 186 non-KEV vulnerabilities carry CVSS > 8— outranking vite (5.3), puppeteer (6.5), and jquery (6.9). CVSS-first’s kev first rank = 18 follows deterministically
0.6
0.7
0.8
0.9
AUCCKEV (higher = KEV fixed earlier)
1.0
Fig. 4. Statistical proof: KEVG RAPH (ILP) AUCCKEV of 0.997 lies 0.166 above the random baseline’s 95% CI upper bound and is unachievable by chance ordering. AUCCKEV scores for all plans on the npm corpus; the shaded band is the empirical 95% CI of the 30-seed random baseline ([0.519, 0.831]). Dependabot achieves the lowest AUCCKEV of any plan (0.589)— below the random mean of 0.663—because severity-bucket ordering actively anti-correlates with KEV membership, performing worse than random expectation. The 0.408 gap between ILP and Dependabot is the full cost of severity-first ordering when exploitation risk is the target.
from this score distribution. No change to the ordering heuristic within a CVSS-first framework can recover KEVearly performance without incorporating KEV membership as a first-class signal. • Greedy: competitive on KEV ordering, superior on coverage sprint. The greedy planner achieves kev first rank = 2 and AUCCKEV = 0.902—well above all non-KEVaware baselines. Its T5 of 0.112 exceeds the ILP’s 0.081, because the greedy strategy maximises marginal coverage at each step while the ILP re-orders the optimal set by KEV priority. Practitioners who need to maximise total vulnerability coverage in a 5-upgrade sprint should prefer greedy; those targeting KEV compliance should prefer ILP. • Ordering, not cardinality, is the differentiator. All deterministic plans achieve near-optimal cardinality (417– 421 actions vs. an ILP-proven minimum of 417). The entire performance spread—from Dependabot (AUCCKEV = 0.589) to ILP (AUCCKEV = 0.997)—is attributable to fix ordering, not total action count. Cardinality optimi-
TABLE III E MPIRICAL 95 TH - PERCENTILE INTERVAL FOR NPM RANDOM BASELINE (n = 30 SEEDS ). KEVG RAPH (ILP) VALUES ARE PROVIDED FOR COMPARISON . Metric
Mean
CI low
CI high
ILP value
T1 T5 AUCCKEV #actions
0.0030 0.0156 0.663 495.4
0.0011 0.0061 0.519 481.9
0.0149 0.0473 0.831 506.3
0.0235 0.0811 0.9971 417
Cross-ecosystem KEV prioritisation advantage ILP ( ) exceeds random 95% CI in all three ecosystems npm (924 repos, 5 KEV, 0.48% density)
0.9971 +0.167 above CI
Maven (1,200 repos, 7 KEV, 2.37% density) PyPI (300 repos, 1 KEV, 0.12% density)
0.9881 +0.295 above CI
KEVGraph ILP Random 95% CI Random mean EPSS-first
0.2
TABLE IV C ROSS - ECOSYSTEM EVALUATION : ILP VS RANDOM BASELINE . KEVG RAPH (ILP) AUCCKEV EXCEEDS THE RANDOM 95% CI UPPER BOUND IN ALL THREE ECOSYSTEMS . Eco
Repos Vulns KEV ILP AUCCKEV Rand. AUCCKEV Acts
npm Maven PyPI
924 1,046 1,200 295 300 818
5 7 1
0.997 0.988 1.000
0.663 [0.52, 0.83] 0.486 [0.27, 0.69] 0.670 [0.23, 0.98]
417 84 99
sation alone is insufficient; exploitation-aware ordering is the critical contribution.
0.4
1.0000 +0.021 above CI
0.6
0.8
AUCCKEV (higher = better)
1.0
Fig. 5. KEVG RAPH (ILP) AUCCKEV exceeds the random 95% CI upper bound in all three ecosystems, across KEV densities ranging from 0.12% to 2.37%. Forest plot: each row shows KEVG RAPH (ILP, diamond) and EPSS-first (triangle) AUCCKEV against the random 95% CI (shaded bar, n = 30 seeds). Maven shows the largest absolute advantage: ILP 0.988 vs. random mean 0.486 (gap = 0.502), consistent with its 4.5× higher KEV density (2.37%) versus npm (0.53%). This scaling behaviour is theoretically expected—a KEV-first planner gains more leverage as KEV density increases—and is empirically confirmed across all three ecosystems. PyPI achieves ILP AUCCKEV = 1.000 with a single KEV target; the wide random CI ([0.232, 0.979]) confirms that a single KEV vulnerability is sufficient to produce a statistically significant ordering advantage.
E. Statistical Analysis of Random Baseline • The advantage scales with KEV prevalence. Maven’s To robustly characterise the random baseline, we ran 30 AUCCKEV gap (0.502) is 50% larger than npm’s (0.334) independent seeds (seeds 0–29) and report the 2.5th–97.5th in direct proportion to its 4.5× higher KEV density. Orpercentile interval across the 30 seed outcomes as an empirical ganisations with Java-heavy stacks—where Struts, Tomcat, 95th-percentile interval. Table III reports the results. and Spring Framework KEV entries are prevalent—gain KEVG RAPH (ILP) exceeds the random 95% CI upper bound the most from switching to KEV-aware planning. on every metric. The AUCCKEV gap is the sharpest signal: ILP • Cardinality optimisation generalises. Maven: 84 ILP = 0.997 vs. CI upper bound = 0.831—a margin of 0.166 that actions vs. random mean 96.2 (95% CI [92.0, 99.6]), cannot be attributed to fortunate random ordering (p ≪ 0.05 a 12.7% reduction. Even in a direct-dependency-only under the empirical distribution). For #actions, ILP requires 417 analysis, the ILP finds a meaningfully more compact vs. a random mean of 495.4 (95% CI [481.9, 506.3]), saving remediation set. 78.4 actions (15.9%) even at the pessimistic end of the random CI. G. Scalability The width of the random CI ([0.519, 0.831], range = 0.312) A common objection to exact ILP optimisation in operational reveals a second practical risk: an organisation that happens tooling is solve time. Figure 6 refutes this objection empirically: to choose a poor-seed random ordering faces worst-case the CBC solver produces a provably optimal plan in under AUCCKEV = 0.519—a gap of 0.478 from ILP’s value. 130 ms on 924 repositories with 2,741 candidate fixes—well Random ordering is not only suboptimal in expectation; within a 200 ms CI/CD gate budget. The greedy planner’s 4.4 s it is unreliable. KEVG RAPH eliminates this variance by wall-clock time at full scale remains suitable for batch-mode construction. pipelines, and both planners exhibit sub-linear growth with corpus size. F. Cross-Ecosystem Evaluation
Table IV and Figure 5 compare KEVG RAPH across all three ecosystems using a forest-plot layout where the ILP result (diamond) is compared against the shaded random 95% CI for each ecosystem. Three ecosystem-specific conclusions follow from Table IV and Figure 5: • The advantage is universal. In every ecosystem the ILP AUCCKEV exceeds the random CI upper bound, ruling out the explanation that KEV-aware ordering is only beneficial in specific package ecosystems or vulnerability distributions.
H. Case Study: ExactTarget/fuelux To illustrate KEVG RAPH’s practical output within the corpus-level plan, we examine ExactTarget/fuelux (5,152 stars), a JavaScript UI component library with 664 dependency nodes in its lockfile graph. Vulnerability landscape. The OSV join identified 194 unique vulnerabilities across packages in this repository’s dependency graph. Of these, 3 are KEV-listed: •
GHSA-qqvq-6xgj-jw8g (electron 1.6.11): libvpx heap buffer overflow, CVSS 8.8
Solve time (ms, log scale)
Planning runtime vs corpus size (npm) ILP stays under 130 ms across all sizes; 2,741 candidate fixes
103
KEVGraph ILP (CBC solver) KEVGraph Greedy
ILP max: 126 ms
200 ms budget
102 50 100
200
500
Number of repositories in corpus
924
Fig. 6. The exact ILP planner solves in under 130 ms on 924 repositories with 2,741 candidate fixes—refuting the objection that exact optimisation is impractical for operational dependency tooling. Planning runtime vs. corpus size (npm, log–log scale). ILP solve time (CBC via PuLP) is bounded below 130 ms across the full 50–924 repository range, satisfying a 200 ms CI/CD gate budget with margin. Greedy runtime grows sub-linearly to 4.4 s at full scale due to its O(|U | · |F |) iterative selection loop; both planners are suitable for real-time automation.
GHSA-j7hp-h8jx-5ppr (electron 1.6.11): libwebp OOB write, CVSS 8.8 • GHSA-jpcq-cgw6-v4j6 (jquery 3.2.1): XSS vulnerability, CVSS 6.9 (KEV added 2025-01-23) Corpus plan — first actions. The corpus-level KEVGraph ILP plan’s first upgrade action is: •
upgrade:[email protected] → @35.7.5 This single action covers both KEV-listed electron vulnerabilities in fuelux (CVSS 8.8 each), along with many other electron vulnerabilities corpus-wide. Within four plan steps all five KEV vulnerabilities across the entire corpus are resolved: electron at step 1, vite at step 2, jquery at step 3, and puppeteer at step 4. Comparison with simplified Dependabot-style ordering. The Dependabot-style baseline’s alphabetical-within-severitybucket ordering delays the electron upgrade to step 18, leaving the libvpx and libwebp KEV vulnerabilities unpatched through 17 intervening upgrades. An organisation applying the Dependabot ordering expends engineering effort on lower-risk packages before addressing actively exploited ones. Certificate. The corpus-level remediation certificate records all 937 (fix, vuln) coverage edges, enabling automated verification (0.221 s) that all coverable vulnerabilities—including the three KEV-listed ones present in fuelux—are addressed by the plan. VII. D ISCUSSION EPSS-first is competitive but structurally incomplete. EPSS-first achieves kev first rank = 1 and AUCCKEV = 0.989 on npm—the closest any non-ILP plan comes to the ILP’s 0.997. The reason it performs well is visible in Figure 1: four of five KEV vulnerabilities have EPSS > 0.35, far above the corpus median. The reason it falls short is equally visible: electron/libvpx (EPSS = 0.048) is confirmed actively exploited
by CISA but rates below median exploitation probability in FIRST’s model. This is not a modelling error—it is an inherent limitation of probabilistic exploitation prediction. EPSS scores update daily and lag KEV list additions; KEV membership is a deterministic signal reflecting attacker behaviour CISA has already observed. The ∆AUCCKEV = 0.009 between EPSS-first and ILP may appear small, but the ILP additionally provides a cardinality-optimality guarantee that EPSS-first cannot claim. CVSS is structurally uncorrelated with active exploitation. The npm corpus contains 186 non-KEV vulnerabilities with CVSS > 8.0 (118 above 9.0); three KEV-listed packages score below 7.0. CVSS-first’s kev first rank = 18 and AUCCKEV = 0.708 follow deterministically from this score distribution— no parameter tuning within a CVSS-first framework can recover KEV-early performance. This extends Spring et al. [15]’s empirical result across three package ecosystems and demonstrates its direct consequence in operational remediation planning. Per-version fix generation creates genuine optimisation choices. Without per-version candidate generation, every vulnerability appears in exactly one fix and set-cover degenerates: all planners select identical fix sets and differ only in ordering. The 2,741 candidate fixes generated across 924 npm repositories (vs. the naive 1-fix-per-package approach) give the ILP and greedy planners real overlap to exploit, enabling the ILP-proven 15.9% cardinality reduction over random ordering. Greedy vs. ILP: two distinct operating points. The greedy planner achieves T5 = 0.112 vs. ILP’s 0.081, covering more vulnerabilities in a 5-upgrade sprint. The ILP achieves AUCCKEV = 0.997 vs. greedy’s 0.902, with first KEV at step 1 vs. step 2. These are not contradictory results: they reflect a true trade-off between maximum marginal coverage (greedy) and maximum KEV-early exposure reduction (ILP). The appropriate choice is determined by the practitioner’s compliance objective. Maven direct-dependency limitation understates the advantage. Maven results use direct pom.xml dependencies only; transitive Java dependencies—frequently the source of highprofile KEV entries such as log4j (Log4Shell)—are not resolved. The observed ILP AUCCKEV = 0.988 and gap = 0.502 are therefore conservative lower bounds. Full transitive resolution would increase KEV hit count and is expected to further widen the advantage of KEV-aware planning. Direct compliance relevance under BOD 22-01. CISA Binding Operational Directive 22-01 mandates remediation of KEV-listed vulnerabilities within prescribed deadlines for federal civilian agencies. The 17-step deferral window produced by CVSS-first and Dependabot represents a systematic compliance risk: KEV-affected packages remain unpatched through actions directed at theoretically severe but unconfirmed-exploitation CVEs. KEVG RAPH’s ILP planner eliminates this deferral by construction, and the machine-verifiable certificate provides the coverage proof required for automated compliance audit workflows. Reproducibility. The full pipeline is deterministic given fixed random seeds and a snapshotted KEV catalogue
(KEVGRAPH_KEV_SNAPSHOT environment variable). All intermediate artefacts are persisted to disk and all results are regenerable with: python -m src.pipeline --stage plan VIII. L IMITATIONS KEV sparsity. Across our corpora, KEV-listed vulnerabilities are rare: 0.53% in npm, 2.37% in Maven, 0.12% in PyPI. This sparsity means that KEV-first ordering has limited impact on aggregate coverage curves (T1 , T5 ) but has a large impact on AUCCKEV and kev first rank—the intended metrics. Corpora with higher KEV density would provide stronger differentiation signals. Maven direct-dependency extraction only. The Maven adapter extracts direct dependencies from pom.xml only. Transitive dependencies are not resolved, under-counting total vulnerability exposure. A full Maven evaluation would require invoking the Maven build system or a dependency-resolution library, which is left to future work. Transitive upgrade effects. KEVG RAPH treats each upgrade as independent. In practice, upgrading package A may force a version change in package B (through shared transitive dependencies), which may resolve or introduce additional vulnerabilities. We do not model these transitive effects. Coverable vs. reachable. KEVG RAPH identifies coverable vulnerabilities—those for which at least one candidate upgrade fix exists in the corpus. This is not equivalent to graph-traversal or runtime reachability analysis: a vulnerability is counted even if the affected package code is never executed on a live execution path. Plate et al. [17] demonstrate that call-graphbased reachability filtering can substantially reduce the set of vulnerabilities that require remediation; integrating such analysis into KEVG RAPH is left to future work. Fix feasibility. KEVG RAPH assumes that upgrading to the latest fixed version is always feasible (no breaking API changes). In practice, major-version upgrades may require code changes not captured in the remediation plan. Corpus size and generalisability. The npm corpus (924 repositories) spans diverse domains but represents a small fraction of the npm ecosystem. Generalisability to the broader ecosystem requires evaluation at larger scale. Maven (1,200 repos) and PyPI (300 repos) corpora are comparably limited. OSV and KEV freshness. Results depend on the state of the OSV database and the CISA KEV catalogue at the time of the join stage. Snapshotting ensures experiment reproducibility but means results do not reflect vulnerabilities discovered after the snapshot date. IX. R ELATED W ORK Dependency vulnerability prioritisation. Decan et al. [13] study the propagation of vulnerabilities through the npm ecosystem and find that a small fraction of packages account for the majority of downstream exposure. Kikas et al. [14] analyse the structural evolution of dependency networks across npm, RubyGems, and CRAN. Neither work addresses prioritised remediation planning. Zimmermann et al. [16] conduct a
large-scale empirical study of security threats in the npm ecosystem across 610,000 packages, finding that a small number of high-centrality packages account for a disproportionate share of transitive vulnerability exposure—a structural property that KEVG RAPH’s set-cover formulation directly exploits to achieve compact remediation plans. Reachability-based vulnerability assessment. Plate et al. [17] introduce Eclipse Steady (Vulas), which uses callgraph reachability analysis to determine whether vulnerable code is actually reachable in a given application. Their work addresses the coverable-versus-reachable gap we identify as a limitation (Section VIII); integrating reachability filtering as a pre-processing stage to KEVG RAPH’s fix generation would reduce the planning universe to only genuinely reachable vulnerabilities. Software Bills of Materials and supply-chain attestation. The NTIA Minimum Elements for an SBOM [18] and the SLSA supply-chain levels framework [19] provide machinereadable dependency inventories and provenance attestations that complement KEVG RAPH’s approach: an SBOM supplies the component list that KEVG RAPH’s parser otherwise derives from lockfiles, and SLSA attestations can encode KEVG RAPH’s fix certificates as verifiable provenance records, enabling fully automated compliance pipelines under BOD 2201. Automated dependency updates. Dependabot [5], Renovate [7], and commercial software composition analysis (SCA) tools provide automated pull requests for dependency upgrades ordered by severity bucket. KEVG RAPH differs by using KEV membership as the primary ordering signal and by minimising total upgrade count via set-cover optimisation—two properties absent from existing tooling. Vulnerability scoring and exploitation. Spring et al. [15] show that CVSS score is a poor predictor of exploitation. The EPSS system [3] provides daily probability estimates of exploitation within 30 days. Our results confirm the CVSS finding across all three ecosystems—CVSS-first defers KEV fixes to step 18 in npm—and further show that even EPSSfirst, while competitive (AUCCKEV = 0.989), is marginally suboptimal compared to exact ILP optimisation when KEV membership is the target signal. Formal optimisation for security. Set-cover and integer programming have been applied to network hardening [8]. Our contribution is the application of ILP minimum set cover to the ordered remediation problem, with KEV-early as an explicit secondary objective and machine-verifiable certificates as output. X. C ONCLUSION The dominant approach to dependency vulnerability ordering—sorting by CVSS severity—is structurally misaligned with active exploitation risk. We demonstrated this concretely: in a corpus of 924 npm repositories, CVSS-first defers the first actively-exploited (KEV-listed) fix by 17 steps while simultaneously requiring more upgrade actions than KEVG RAPH.
KEVG RAPH addresses this gap by framing remediation as a KEV-aware set-cover problem solved exactly by ILP. On the npm corpus (1,046 vulnerabilities, 5 KEV-listed), the ILP planner achieves AUCCKEV = 0.997 (vs. random mean 0.663, 95% CI [0.519, 0.831], n = 30), resolves the first KEV vulnerability at step 1, and requires only 417 upgrade actions— 15.9% fewer than random and fewer than any severity-based baseline. The statistical gap—0.166 above the random CI upper bound—rules out chance. The framework generalises across ecosystems: Maven (1,200 repos) achieves an AUCCKEV gap of 0.502 over random, proportional to its 4.5× higher KEV density; PyPI (300 repos) achieves perfect ILP AUCCKEV = 1.000. The pluggable adapter architecture requires only a new lockfile parser to extend to additional package managers. KEVG RAPH’s machine-verifiable remediation certificates provide the coverage proof required for automated compliance audit under CISA BOD 22-01. Future work will incorporate full Maven transitive resolution, model transitive upgrade interactions, integrate reachability-based filtering [17], and connect plan output to pull-request generation pipelines and SBOM-driven workflows [18]. R EPRODUCIBILITY All code, data artefacts, and figures are available in the project repository. To regenerate all npm results from precached intermediate artefacts (no network access required): pip install -r requirements.txt python -m src.pipeline --stage plan cat data/results.csv # Table 2 cat data/random_ci.json # Table 3 Expected key values: ILP AUCCKEV = 0.9971, ILP #actions = 417, random AUCCKEV mean = 0.663, random #actions mean = 495.4. To regenerate from raw lockfiles (requires GitHub and OSV API access): python -m src.pipeline --resume All figures (data/plots/) are regenerated automatically at the plot stage. ACKNOWLEDGEMENTS Pipeline code, evaluation artefacts, and reproduction instructions are available at the project repository. All data artefacts required for reproduction are included under data/. AIassisted coding tools were used during software development; all experimental design, result verification, and manuscript content are the responsibility of the author. R EFERENCES [1] Cybersecurity and Infrastructure Security Agency (CISA), “Known Exploited Vulnerabilities Catalog,” https://www.cisa.gov/ known-exploited-vulnerabilities-catalog, Accessed March 2026. [2] Open Source Vulnerability (OSV) Database, https://osv.dev, Accessed March 2026. [3] FIRST.org, “Exploit Prediction Scoring System (EPSS),” https://www. first.org/epss/, Accessed March 2026.
[4] FIRST.org, “Common Vulnerability Scoring System v3.1: Specification Document,” https://www.first.org/cvss/v3.1/specification-document, 2019. [5] GitHub, “Dependabot security updates,” https://docs.github.com/en/ code-security/dependabot, Accessed March 2026. [6] npm, “npm audit,” https://docs.npmjs.com/cli/v10/commands/npm-audit, Accessed March 2026. [7] Mend.io, “Renovate Bot,” https://docs.renovatebot.com, Accessed March 2026. [8] M. R. Garey and D. S. Johnson, Computers and Intractability: A Guide to the Theory of NP-Completeness. W. H. Freeman, 1979. [9] G. L. Nemhauser, L. A. Wolsey, and M. L. Fisher, “An Analysis of Approximations for Maximizing Submodular Set Functions—I,” Mathematical Programming, vol. 14, no. 1, pp. 265–294, 1978. [10] D. S. Johnson, “Approximation Algorithms for Combinatorial Problems,” Journal of Computer and System Sciences, vol. 9, no. 3, pp. 256–278, 1974. [11] J. Forrest and R. Lougee-Heimer, “CBC User Guide,” in Emerging Theory, Methods, and Applications, INFORMS, 2005, pp. 257–277. [12] S. Mitchell, M. OSullivan, and I. Dunning, “PuLP: A Linear Programming Toolkit for Python,” Department of Engineering Science, University of Auckland, 2011. [13] A. Decan, T. Mens, and E. Constantinou, “On the Impact of Security Vulnerabilities in the npm Package Dependency Network,” in Proc. MSR, 2018, pp. 181–191. [14] R. Kikas, G. Gousios, M. Dumas, and D. Pfahl, “Structure and Evolution of Package Dependency Networks,” in Proc. MSR, 2017, pp. 102–112. [15] J. Spring et al., “Time to Change the CVSS?,” in Proc. IEEE EuroS&P Workshops, 2021. [16] M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small World with High Risks: A Study of Security Threats in the npm Ecosystem,” in Proc. USENIX Security Symposium, 2019, pp. 995–1010. [17] H. Plate, S. E. Ponta, and A. Sabetta, “Impact Assessment for Vulnerabilities in Open-Source Software Libraries,” in Proc. IEEE ICSME, 2015, pp. 411–420. [18] National Telecommunications and Information Administration (NTIA), “The Minimum Elements For a Software Bill of Materials (SBOM),” U.S. Department of Commerce, July 2021, https://www.ntia.doc.gov/report/ 2021/minimum-elements-software-bill-materials-sbom. [19] Google and Open Source Security Foundation (OpenSSF), “Supply Chain Levels for Software Artifacts (SLSA) v1.0,” https://slsa.dev/spec/v1.0/, 2023.