Pith. sign in

REVIEW 3 major objections 4 minor 69 references

Forecasting the risk of software choices: A model to foretell security vulnerabilities from library dependencies and source code evolution

T0 review · 3 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that the probability of a CVE disclosure in a future window can be estimated at library level from dependencies and source-code evolution, via a white-box time dependency tree model.

desk verdict The TDT framework is a genuinely new formalization, but the paper's only empirical demonstration is in-sample: the CVE it claims to 'foretell' was used to fit the very curves that produce the forecast. read the letter →

arxiv 2411.11202 v1 pith:W6AST7KR submitted 2024-11-17 cs.SE cs.CRcs.ET

Carlos E. Budde , Ranindya Paramitha , Fabio Massacci This is my paper · ORCID
classification cs.SEcs.CRcs.ET
keywords vulnerabilityforecastingCVEdisclosurepredictiontimedependencytreesattacktreeanalysissoftwaresupplychainriskkerneldensityestimationlibrarydependenciesMavenecosystem
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that future security vulnerabilities are forecastable at the granularity of individual libraries, not just as aggregate counts for a whole ecosystem. It claims that by combining the dependency tree of a project with the release history of each library, one can compute the probability that the project faces a CVE disclosure within a chosen future window, and can rank which dependency contributes most to that risk. A developer weighing whether to update a library would get a concrete number to compare. The authors demonstrate the model on 1255 CVEs and 768 Java libraries, including a reconstruction of the 2021 jira-core/xstream case where the rising probability signal would have advised the update that hindsight proved correct.

What carries the argument

The load-bearing object is the time dependency tree (TDT): a dependency graph extended with a time dimension. A c-chain orders the versions of one library by release date, and a d-matrix tracks which versions of a dependency appear across successive dependency trees of the main library, allowing version stuttering, adoption, and dropping of dependencies. Indexing the TDT at a time point $t_k$ recovers the ordinary dependency tree, which is converted into an attack tree via the bijection of Section 3.2: each library instance becomes a basic attack step and each non-leaf node becomes an OR gate. Each leaf, a dependency $x$ released $\Delta_x^k$ days before $t_k$, is labelled with $\hat{p}_x^k$ as above, where $F_\iota$ is the CDF of the cluster containing $x$; the cluster CDF is a kernel-density estimate fitted once per ecosystem on historical grace periods, stratified by own-code size (Small/Medium versus Large, threshold 100k LoC) and web-orientation (Remote network versus Local). OR-propagation through standard quantitative attack-tree algorithms yields the project-level estimate $\hat{p}_k$. For the few-dependency case, an analytical alternative uses $F_{A+B}(t) = 1 - S_A(t)S_B(t)$ and inclusion-exclusion.

What would settle it

Re-run the jira-core demonstration with a temporal holdout: fit the cluster CDFs using only CVEs disclosed before, say, 1 June 2021, recompute the 45-day probability for jira-core:8.19.1 at the end of June and July 2021, and check whether the rising signal toward xstream:1.4.17 still appears before CVE-2021-39139's disclosure on 30 August 2021; if the probability no longer rises, or rises only because CVE-2021-39139 is in the fitting data, the forecasting claim is refuted, whereas a positive result would show the signal is not an artifact of in-sample fitting.

Watch

Extended reading notes

Core claim

The paper's central claim is that CVE disclosures are forecastable at library level: the probability that a project faces a CVE in a future window of $n$ days can be computed from the dependency structure and the release history of each library instance. Each dependency contributes a displaced integral of a cluster CDF, $\hat{p}_x^k = F_\iota(\Delta_x^k + n) - F_\iota(\Delta_x^k)$, and these leaf probabilities are combined through an attack-tree aggregation to give the project-level probability. The authors argue the model is white-box and lightweight, and demonstrate it on jira-core in 2021, where the 45-day probability rises from about 0.096 on 25 June to 0.158 on 25 July, driven mainly by mxparser:1.2.1 and xstream:1.4.17 — a signal that would have supported updating xstream before CVE-2021-39139 was disclosed.

Load-bearing premise

The entire method rests on the assumption that the disclosure curves fitted on the full historical CVE record, which includes the very CVEs the demonstration claims to foretell, still hold for future time windows, and the validation never fits on a temporal cutoff to test that assumption.

Editorial extensions

If this is right

  • A developer can compute, for any date and any horizon $n$, the probability that their project faces a CVE, and can compare update policies—keeping a dependency versus moving to a newer instance—by the resulting change in that probability.
  • The attack-tree decomposition exposes which library instances drive the project-level risk, so security-sensitive points can be identified and prioritized for updates.
  • Because cluster CDFs are fitted once per ecosystem and reused, per-project estimation scales linearly in the number of dependencies and takes seconds to minutes, making routine forecasting feasible for projects with dozens of dependencies.
  • For small dependency sets, the analytical survival-function convolution provides the full probability density of the fastest expected CVE, revealing local minima and maxima that point estimates at discrete time points miss.
  • Beyond forecasting, the TDT representation supports detecting pervasive dependencies and single-points-of-failure that threaten several versions of a project at once, and measuring ecosystem health from the fraction of popular c-chains affected by disclosed CVEs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A temporal-holdout re-run would settle the forecasting claim: fitting the cluster CDFs only on CVEs disclosed before the forecast date, then recomputing the jira-core probabilities, would show whether the pre-disclosure signal survives when the predicted CVE is not inside the fitting data—a test the paper's own label-creep discussion calls for but its demonstration does not perform.
  • The same pipeline could be deployed as a release-time check: compute the project-level probability before each release, and treat a rising $n$-day probability concentrated in one dependency as a trigger to update or replace that library; the paper shows the ingredients, such as the pdf reset after an update, but leaves the decision rule implicit.
  • Transfer to other package ecosystems is the natural next experiment, but the cluster features are calibrated on Java/Maven, so a replication on npm or PyPI would test whether the four-cluster stratification generalizes or needs re-calibration.
  • The OR-gate aggregation treats CVE disclosures in different dependencies as independent events, yet the paper itself notes that parallel release chains of one library share vulnerabilities; correlated disclosures would shift the joint probability, and quantifying that correlation is an open direction the TDT machinery could support.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper introduces a white-box model for forecasting the probability that a software project faces a CVE disclosure in a future time window. The model formalizes library dependencies and source-code evolution through 'time dependency trees' (TDTs), clusters libraries by own-code size and web-orientation, fits kernel density estimates (KDEs) to historical grace periods (release-to-CVE times), and propagates per-dependency probabilities through an attack-tree structure. The empirical demonstration uses 1255 CVEs and 768 Java libraries from Maven, focusing on a motivating example where jira-core depends on xstream:1.4.17 and the model allegedly forecasts CVE-2021-39139. The paper claims that the resulting probabilities can guide dependency-update decisions.

Significance. If the forecasting claim were validated, the TDT formalism would be a useful, lightweight, interpretable contribution to vulnerability risk assessment, addressing a gap in the literature that mostly focuses on detection of existing vulnerabilities. The paper's emphasis on white-box modeling, on forecasting rather than detection, and on releasing an open-source artifact are clear strengths. However, the significance is contingent on the empirical demonstration, and that demonstration is invalidated by label creep: the KDEs used for prediction are fitted on data that include the very CVE the paper claims to forecast. Without a valid out-of-sample evaluation, the central claim that the model can forecast future CVE disclosures is unsupported.

major comments (3)
  1. [Sec. 6.2 / 6.3] Section 6.2 fits the KDEs on all 394 evidence instances, which include the grace period of xstream:1.4.17 for CVE-2021-39139; Section 6.3 then uses these KDEs to compute p̂2≈0.096 and p̂3≈0.158 and claims the rise 'could have been produced before Aug 2021'. This violates the paper's own definition of label creep in Section 1 ('data used to foretell an unseen vulnerability κ in a future time window T must exclude information on the occurrence of κ during T') and the warning in Section 8.2. The probability rise is necessarily influenced by the very CVE it claims to forecast, so the validation is in-sample and the central forecasting claim is unsupported as demonstrated.
  2. [Sec. 6] Section 6 contains no out-of-sample evaluation: there is no temporal holdout, no cross-validation, no calibration analysis, and no comparison with a baseline model (e.g., a constant-rate or release-age-only model). The only quantitative validation is the retrospective xstream example, which is contaminated by the fitting data as noted above. Consequently, the manuscript provides no evidence that the model generalizes to CVEs not present in the fitting set.
  3. [Sec. 5.2 / 5.4] Section 5.2 fits F_ι to the grace periods of the 394 evidence instances, i.e., library instances already known to be affected by at least one high/critical CVE; Section 5.4 then uses F_ι(Δ+n)-F_ι(Δ) as the absolute probability that a dependency faces a CVE in the next n days. Because F_ι is a conditional distribution (given that a CVE occurs), it overestimates the risk for library instances that may never receive a CVE. The model lacks a base-rate or zero-inflation component, and this limitation is not acknowledged in the paper.
minor comments (4)
  1. [Fig. 1 caption] The caption spells 'com.attlassian.jira' with a double 't'; the correct Maven coordinate is 'com.atlassian.jira'.
  2. [Sec. 7, Eq. (1)] The inclusion-exclusion formula for the CDF of the fastest CVE is written as F_{A1+...+AN}(t)=∑_{J⊆{1,...,N}}(-1)^{|J|+1}|F_{Σ{A_i|i∈J}}(t)|; this notation is undefined (F of a set? absolute value of a CDF?) and, under the independence assumption used elsewhere in the paper, the correct expression should be 1-∏_{i=1}^N (1-F_{A_i}(t)).
  3. [Fig. 12] The KDE fits in Fig. 12 are presented without confidence bands or any measure of fit uncertainty; given the small cluster sizes (40-188 points), a bootstrap or similar would help assess the reliability of the tail behavior that drives the main example.
  4. [Sec. 5.1] The condition |C_ι|>30 is stated as necessary for fitting a pdf, but no justification or reference is given for this threshold.

Circularity Check

2 steps flagged · score 8.0 of 10

Validation of the forecasting claim is in-sample: cluster CDFs are fitted on all 394 evidence instances, including CVE-2021-39139's evidence instance xstream:1.4.17, and then reused to 'foretell' that same CVE.

  1. fitted input called prediction [Sec. 5.4 (Probabilities estimation) applied in Sec. 6.2-6.3]
    "Then we compute ˆp_x^k = F_ι(Δ_x^k + n) − F_ι(Δ_x^k), where F_ι is the cdf of the cluster C_ι to which dependency ℓ_x belongs. ... A Kernel Density Estimate K_ι was fit from each P_ι ... In particular, ℓ_z = xstream:1.4.17 is a Large (151629 LoC) Remote network library released on May 14, 2021, whose estimate ˆp_z2≈0.032 at t2 increases to ˆp_z3≈0.070 at t3."

    The cluster CDF F_ι used to compute the leaf probability for xstream:1.4.17 is fitted in Sec. 6.2 on the full pool P_ι of grace periods of all 394 evidence instances. CVE-2021-39139 is a high/critical Java CVE in the Snyk selection of Sec. 6.1, and Sec. 5.2 declares the latest vulnerable version—xstream:1.4.17—to be its evidence instance, so the grace period of this exact leaf is one of the data points in P_ι. Thus p̂_z^k = F_ι(Δ_z^k + 45) − F_ι(Δ_z^k) is evaluated on a distribution that already contains the CVE whose Aug 2021 disclosure the text says was 'foretold'. The rise in probability is not an out-of-sample forecast but a re-reading of the fitted KDE mass in that time window.

  2. other [Sec. 1 (Introduction, research-question definition) vs. Sec. 6.2-6.3]
    "Technically, any metric that answers positively this research question must avoid label creep: data used to foretell an unseen vulnerability κ in a future time window T = [tstart, tend] must exclude information on the occurrence of κ during T. Thus, fitting/learning cannot use hindsight data such as cve or kev entries for κ."

    This is the paper's own validity condition for a forecasting metric. The validation in Sec. 6.3 does not satisfy it: no temporal split is made in Sec. 6.2, and the fitting pool includes the target CVE's evidence instance. Hence the 'forecast' of the running example is circular with respect to the paper's own definition of what would count as a forecast.

full rationale

The paper is not circular in its formal structures: TDTs, d-matrices, attack-tree conversion, and OR-propagation are defined independently of the data and are not derived from the target CVE. The circularity lies entirely in the empirical demonstration of forecasting ability. The abstract claims the model 'can estimate the probability that a software project faces a CVE disclosure in a future time window'; Sec. 5.4 operationalizes this as p̂_x^k = F_ι(Δ_x^k + n) − F_ι(Δ_x^k), where F_ι is the KDE-fitted CDF of a cluster. Sec. 6.2 fits K_ι on the full pool P_ι of grace periods from all 394 evidence library instances, without any temporal holdout. Sec. 6.1 built that pool by selecting high/critical Java CVEs from Snyk, which includes CVE-2021-39139; Sec. 5.2 defines the evidence instance as the latest vulnerable version, which for that CVE is xstream:1.4.17, the leaf ℓ_z used in Sec. 6.3. Consequently, the grace period of xstream:1.4.17 for CVE-2021-39139 is part of the fitting data for the very F_ι that Sec. 6.3 evaluates at t2=Jun 25 and t3=Jul 25 to 'foretell' the Aug 2021 disclosure. The predicted rise from p̂_z2≈0.032 to p̂_z3≈0.070 is therefore in-sample: it reflects the placement of the target CVE's grace period in the KDE. The paper's own Sec. 1 states that a forecasting metric 'must avoid label creep' and that fitting cannot use hindsight data for the predicted κ; the validation does exactly what the definition forbids. No out-of-sample evaluation, calibration analysis, or baseline comparison is reported. The TDT/attack-tree contribution has independent content, but the central forecasting claim is supported only by an in-sample demonstration.

Assumptions & free parameters 4 free parameters · 5 assumptions · 2 invented entities

The probability estimates are produced by four cluster-specific KDEs fitted to historical CVE grace periods, plus hand-chosen cluster boundaries and unreported bandwidth. The formal TDT and c-chain constructs are definitions, not empirically validated entities.

free parameters (4)
  • cluster size threshold = 100,000 LoC
    Boundary between Small/Medium and Large libraries, adopted from Massacci and Pashchenko [44]; a hand-chosen modeling input that changes which pdf applies to a library.
  • KDE bandwidth = not reported
    KDEUnivariate from statsmodels [58] is used in Section 6.2, but the bandwidth is not stated; all probability estimates depend on it.
  • cluster grid (2x2) = size class x web-orientation
    The model uses only four clusters produced by two binary properties; this is a pragmatic choice, not derived from data or theory.
  • forecast horizon n in examples = 45 days
    User-supplied horizon; not fitted, but results are not tested for sensitivity to n.
assumptions (5)
  • domain assumption A1: Libraries with similar security-relevant properties face similar numbers of vulnerability disclosures in a given time span.
    Stated in Section 3.3; it justifies clustering libraries together to fit shared pdfs.
  • domain assumption A2: Past vulnerability history of a library or family of libraries is indicative of future disclosures.
    Stated in Section 3.3; it justifies using historical CVE grace periods to forecast future CVEs.
  • domain assumption Temporal stationarity: KDEs fitted on historical data apply unchanged to future time windows.
    Implicit in Sections 5.2 and 6.2; no adjustment is made for disclosure-rate trends, and the validation does not use a temporal holdout.
  • domain assumption Independence of vulnerability events across leaf libraries in OR propagation.
    Section 5.4 propagates leaf probabilities through standard attack-tree algorithms, which combine events as independent; correlated CVEs across dependencies are not modeled.
  • domain assumption Grace periods within a cluster are exchangeable samples for KDE.
    Section 5.2 pools grace periods across library instances; the KDE procedure treats them as independent draws from one density.
invented entities (2)
  • time dependency tree (tdt)
    purpose: Formal graph merging dependency trees with c-chain evolution to propagate vulnerability probabilities over time.
    A mathematical construct defined in Section 4.3; it has no observable handle outside the paper's definitions and demonstration.
  • c-chain
    purpose: Total order of library versions in a development branch, used to align dependency trees in time.
    Formal definition in Section 4.1; it organizes version history but is not independently testable.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Forecasting the risk of software choices: A model to foretell security vulnerabilities from library dependencies and source code evolution." pith.science (2026). https://pith.science/paper/W6AST7KR

@misc{pith2026241111202,
  author       = {Pith},
  title        = {Pith review of: Forecasting the risk of software choices: A model to foretell security vulnerabilities from library dependencies and source code evolution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W6AST7KR}},
  note         = {Machine review of arXiv:2411.11202}
}
read the original abstract

Software security mainly studies vulnerability detection: is my code vulnerable today? This hinders risk estimation, so new approaches are emerging to forecast the occurrence of future vulnerabilities. While useful, these approaches are coarse-grained and hard to employ for project-specific technical decisions. We introduce a model capable of vulnerability forecasting at library level. Formalising source-code evolution in time together with library dependency, our model can estimate the probability that a software project faces a CVE disclosure in a future time window. Our approach is white-box and lightweight, which we demonstrate via experiments involving 1255 CVEs and 768 Java libraries, made public as an open-source artifact. Besides probabilities estimation, e.g. to plan software updates, this formal model can be used to detect security-sensitive points in a project, or measure the health of a development ecosystem.

Figures

Figures reproduced from arXiv: 2411.11202 by the authors.

Figure 1
Figure 1. Update policies that disregard the probability of future vulnerabilities threaten the security of entire software projects [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Dependency tree: arrow means “uses in source code” – The dependent (library) instance is the reciprocal of the dependency, e.g. if ℓ𝑏2 is a dependency of ℓ𝑎1 , then ℓ𝑎1 is a dependent instance of ℓ𝑏2 . ∗ In [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Update policies of ℓ𝑎 need forecasting metrics to avoid future vulnerabilities from dependencies like ℓ𝑑 (same as [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Forecasting vulnerabilities: probability of cve disclosure as a function of time and source code • it should take into account the vulnerabilities that would affect any dependency on the project [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Bijection between dependency trees (left) and [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Tracking different instances of the library [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Time Dependency Trees as per Def. 4.3, illustrative examples [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]
Figure 8
Figure 8. Figure 8: Portion of the tdt for the library from Example 1, for three time points that cover jira-core:{8.17.0, 8.18.0m1, 8.18.1} We produce forecasts on past events as a means to validate the method—technical details are given here, with an empirical demonstration following in…
Figure 9
Figure 9. Figure 9: T3 = at corresponding to time-index 𝑡3 in the tdt from [PITH_FULL_IMAGE:figures/full_fig_p018_9.png]
Figure 10
Figure 10. Figure 10: Data-selection and enrichment process: from Maven libraries to [PITH_FULL_IMAGE:figures/full_fig_p020_10.png]
Figure 11
Figure 11. Figure 11: Histogram of libraries used for clustering: own code size vs. web-orientation [PITH_FULL_IMAGE:figures/full_fig_p021_11.png]
Figure 12
Figure 12. Figure 12: pdf for each cluster of libraries (class × size) fitted using kde can be extrapolated to further libraries, say ℓ𝑥 ∉ 𝐶𝜄, as long as ℓ𝑥 can be identified as belonging to cluster 𝐶𝜄 by virtue of its own-size and web-orientation. 6.3 tdts instantiation and probability es…
Figure 13
Figure 13. Figure 13: Probability of facing a cve from two source codes, one Small/Medium and one Large, applying eq. (1) to [PITH_FULL_IMAGE:figures/full_fig_p023_13.png]
Figure 14
Figure 14. Figure 14: Probabilities of vulnerability from ℓ𝐴 or ℓ𝐵, from class Local, for different release dates of the libraries This convolution of two pdfs generates a probability plane, as the ones shown in figures 13 and 14, whose 45◦ diagonal cut (viz. time passes equally fast for b…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

69 extracted references · 40 canonical work pages

  1. [1]

    Artifact Review and Badging

    ACM 2020. Artifact Review and Badging. Retrieved 29.03.2024 from https://www.acm.org/publications/policies/artifact-review-and-badging-current

    work page 2020

  2. [2]

    Junaid Akram and Ping Luo. 2021. SQVDT: A scalable quantitative vulnerability detection technique for source code security assessment. Software: Practice and Experience 51, 2 (2021), 294–318. https://doi.org/10.1002/spe.2905

    work page doi:10.1002/spe.2905 2021

  3. [3]

    Manar Alohaly and Hassan Takabi. 2017. When Do Changes Induce Software Vulnerabilities?. In CIC. IEEE, 59–66. https://doi.org/10.1109/CIC. 2017.00020

    work page arXiv 2017

  4. [4]

    Henrique Alves, Baldoino Fonseca, and Nuno Antunes. 2016. Software Metrics and Security Vulnerabilities: Dataset and Exploratory Study. In EDCC. IEEE, 37–44. https://doi.org/10.1109/EDCC.2016.34

    work page doi:10.1109/edcc.2016.34 2016

  5. [5]

    Florian Arnold, Dennis Guck, Rajesh Kumar, and Mariële Stoelinga. 2015. Sequential and Parallel Attack Tree Modelling. In SAFECOMP (LNCS, Vol. 9338). Springer International Publishing, 291–299. https://doi.org/10.1007/978-3-319-24249-1_25

    work page doi:10.1007/978-3-319-24249-1_25 2015

  6. [6]

    Florian Arnold, Holger Hermanns, Reza Pulungan, and Mariëlle Stoelinga. 2014. Time-Dependent Analysis of Attacks. In POST (LNCS, Vol. 8414). Springer Berlin Heidelberg, 285–305. https://doi.org/10.1007/978-3-642-54792-8_16

    work page doi:10.1007/978-3-642-54792-8_16 2014

  7. [8]

    Zeki Bilgin, Mehmet Akif Ersoy, Elif Ustundag Soykan, Emrah Tomur, Pinar Çomak, and Leyli Karaçay. 2020. Vulnerability Prediction From Source Code Using Machine Learning. IEEE Access 8 (2020), 150672–150684. https://doi.org/10.1109/ACCESS.2020.3016774

    arXiv 2020

  8. [9]

    Carver, Munawar Hafiz, Patrick Hilley, and Derek Janni

    Amiangshu Bosu, Jeffrey C. Carver, Munawar Hafiz, Patrick Hilley, and Derek Janni. 2014. Identifying the Characteristics of Vulnerable Code Changes: An Empirical Study. In FSE. ACM, 257–268. https://doi.org/10.1145/2635868.2635880

    arXiv 2014

Show all 69 references
  1. [10]

    Budde, Ranindya Paramitha, and Fabio Massacci

    Carlos E. Budde, Ranindya Paramitha, and Fabio Massacci. 2024. Forecasting the risk of software choices: A model to fore- tell security vulnerabilities from library dependencies and source code evolution (experimental reproduction package) . Zen- odo. https://zenodo.org/record...

    2024

  2. [11]

    Marco Carvalho, Jared DeMott, Richard Ford, and David A. Wheeler. 2014. Heartbleed 101. IEEE Security & Privacy 12, 4 (2014), 63–67. https: //doi.org/10.1109/MSP.2014.66

    2014 doi

  3. [12]

    Saikat Chakraborty, Rahul Krishna, Yangruibo Ding, and Baishakhi Ray. 2021. Deep Learning based Vulnerability Detection: Are We There Yet.IEEE Transactions on Software Engineering 48, 9 (2021), 3280–3296. https://doi.org/10.1109/TSE.2021.3087402

    2021

  4. [13]

    Istehad Chowdhury and Mohammad Zulkernine. 2011. Using complexity, coupling, and cohesion metrics as early indicators of vulnerabilities. Journal of Systems Architecture 57, 3 (2011), 294–313. https://doi.org/10.1016/j.sysarc.2010.06.003

    2011 doi

  5. [14]

    CISA, NSA, FBI, ACSC, CCCS, CERT NZ, NCSC-NZ, NCSC-UK, BSI, NCSC-NL, NCSC-NO, NÙKIB, INCD, KISA, NISC-JP, JPCERT/CC, CSA, and CSIRTAMERICAS. 2023. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. https: //www.cisa.gov/resourc...

    2023

  6. [15]

    P. Cousot. 2021. Principles of Abstract Interpretation. MIT Press

    2021

  7. [16]

    Regulation EU 2019/88 (Cybersecurity Act)

    CyberSecAct 2019. Regulation EU 2019/88 (Cybersecurity Act). Retrieved 13.02.2024 from https://eur-lex.europa.eu/eli/reg/2019/881/oj

    2019

  8. [17]

    Brucker, and Fabio Massacci

    Stanislav Dashevskyi, Achim D. Brucker, and Fabio Massacci. 2018. On the Effort for Security Maintenance of Open Source Components. In WEIS. 34 pages. https://www.brucker.ch/bibliography/abstract/dashevskyi.ea-foss-efforts-2018 Manuscript submitted to ACM 28 Budde, Paramitha, Massacci

    2018

  9. [18]

    Dongdong Du, Xingzhang Ren, Yupeng Wu, Jien Chen, Wei Ye, Jinan Sun, Xiangyu Xi, Qing Gao, and Shikun Zhang. 2018. Refining Traceability Links Between Vulnerability and Software Component in a Vulnerability Knowledge Graph. In ICWE (LNCS, Vol. 10845). Springer, 33–49. https: /...

    2018 doi

  10. [19]

    Cybersecurity — security requirements for ICT product certification

    EUCC 2024. Cybersecurity — security requirements for ICT product certification. Retrieved 13.02.2024 from https://ec.europa.eu/info/law/better- regulation/have-your-say/initiatives/13382-Cybersecurity-security-requirements-for-ICT-product-certification_en

    2024

  11. [20]

    Barbara Fila and Wojciech Wideł. 2019. Efficient Attack-Defense Tree Analysis using Pareto Attribute Domains. In CSF. 200–215. https: //doi.org/10.1109/CSF.2019.00021

    2019

  12. [21]

    Sundarakrishnan Ganesh, Tobias Ohlsson, and Francis Palma. 2021. Predicting Security Vulnerabilities using Source Code Metrics. In SweDS. IEEE, 1–7. https://doi.org/10.1109/SweDS53855.2021.9638301

    2021

  13. [22]

    Seyed Mohammad Ghaffarian and Hamid Reza Shahriari. 2017. Software Vulnerability Analysis and Discovery Using Machine-Learning and Data-Mining Techniques: A Survey. ACM Comput. Surv. 50, 4 (2017), 36 pages. https://doi.org/10.1145/3092566

    2017 doi

  14. [23]

    Nate Gruver, Marc Finzi, Shikai Qiu, and Andrew G. Wilson. 2023. Large Language Models Are Zero-Shot Time Series Forecasters. In NeurIPS, Vol. 36. Curran Associates, Inc., 19622–19635. https://doi.org/10.48550/arXiv.2206.04038

    2023 doi arXiv

  15. [24]

    Joseph Hejderup, Arie van Deursen, and Georgios Gousios. 2018. Software Ecosystem Call Graph for Dependency Management. In ICSE-NIER. ACM, 101–104. https://doi.org/10.1145/3183399.3183417

    2018

  16. [25]

    Tamburri

    Daan Hommersom, Antonino Sabetta, Bonaventura Coppola, and Damian A. Tamburri. 2021. Automated Mapping of Vulnerability Advisories onto their Fix Commits in Open Source Repositories. https://arxiv.org/pdf/2103.13375.pdf

    2021 arXiv

  17. [26]

    Nasif Imtiaz, Seaver Thorn, and Laurie Williams. 2021. A Comparative Study of Vulnerability Reporting by Software Composition Analysis Tools. In ESEM. ACM, 11 pages. https://doi.org/10.1145/3475716.3475769

    2021

  18. [27]

    Jay Jacobs, Sasha Romanosky, Octavian Suciu, Benjamin Edwards, and Armin Sarabi. 2023. Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights. https://doi.org/10.48550/arXiv.2302.14172

    2023 doi arXiv

  19. [28]

    Ravi Jhawar, Barbara Kordy, Sjouke Mauw, Saša Radomirović, and Rolando Trujillo-Rasua. 2015. Attack Trees with Sequential Conjunction. In SEC (IFIPAICT, Vol. 455). Springer International Publishing, 339–353. https://doi.org/10.1007/978-3-319-18467-8_23

    2015 doi

  20. [29]

    Hakan Kekül, Burhan Ergen, and Halil Arslan. 2021. A multiclass hybrid approach to estimating software vulnerability vectors and severity score. Journal of Information Security and Applications 63 (2021), 103028. https://doi.org/10.1016/j.jisa.2021.103028

    2021

  21. [30]

    Seulbae Kim, Seunghoon Woo, Heejo Lee, and Hakjoo Oh. 2017. VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery. In SP. IEEE, 595–614. https://doi.org/10.1109/SP.2017.62

    2017 doi

  22. [31]

    Barbara König, Dennis Nolte, Julia Padberg, and Arend Rensink. 2018. A Tutorial on Graph Transformation. Springer International Publishing, 83–104. https://doi.org/10.1007/978-3-319-75396-6_5

    2018 doi

  23. [32]

    Barbara Kordy, Ludovic Piètre-Cambacédès, and Patrick Schweitzer. 2014. DAG-based attack and defense modeling: Don’t miss the forest for the attack trees. Computer Science Review 13-14 (2014), 1–38. https://doi.org/10.1016/j.cosrev.2014.07.001

    2014 doi

  24. [33]

    German, Ali Ouni, Takashi Ishio, and Katsuro Inoue

    Raula Gaikovina Kula, Daniel M. German, Ali Ouni, Takashi Ishio, and Katsuro Inoue. 2018. Do developers update their library dependencies? Empirical Software Engineering 23, 1 (2018), 384–417. https://doi.org/10.1007/s10664-017-9521-5

    2018 doi

  25. [34]

    David Last. 2016. Forecasting Zero-Day Vulnerabilities. In CISRC. ACM, 1–4. https://doi.org/10.1145/2897795.2897813

    2016

  26. [35]

    Éireann Leverett, Matilda Rhode, and Adam Wedgbury. 2022. Vulnerability Forecasting: Theory and Practice. Digital Threats 3, 4 (2022), 42:1–42:27. https://doi.org/10.1145/3492328

    2022 doi

  27. [36]

    Hongzhe Li, Hyuckmin Kwon, Jonghoon Kwon, and Heejo Lee. 2014. A Scalable Approach for Vulnerability Discovery Based on Security Patches. In ATIS (CCIS, Vol. 490). Springer, 109–122. https://doi.org/10.1007/978-3-662-45670-5_11

    2014 doi

  28. [37]

    Qiang Li, Jinke Song, Dawei Tan, Haining Wang, and Jiqiang Liu. 2021. PDGraph: A Large-Scale Empirical Study on Project Dependency of Security Vulnerabilities. In DSN. IEEE, 161–173. https://doi.org/10.1109/DSN48987.2021.00031

    2021

  29. [39]

    Chengwei Liu, Sen Chen, Lingling Fan, Bihuan Chen, Yang Liu, and Xin Peng. 2022. Demystifying the vulnerability propagation and its evolution via dependency trees in the NPM ecosystem. In ICSE. ACM, 672–684. https://doi.org/10.1145/3510003.3510142

    2022

  30. [40]

    Budde, and Mariëlle Stoelinga

    Milan Lopuhaä-Zwakenberg, Carlos E. Budde, and Mariëlle Stoelinga. 2023. Efficient and Generic Algorithms for Quantitative Attack Tree Analysis. IEEE Transactions on Dependable and Secure Computing 20, 5 (2023), 4169–4187. https://doi.org/10.1109/TDSC.2022.3215752

    2023

  31. [41]

    Fabio Massacci. 2024. The Holy Grail of Vulnerability Predictions.IEEE Security & Privacy22, 1 (2024), 4–6. https://doi.org/10.1109/MSEC.2023.3333936

    2024

  32. [42]

    Fabio Massacci and Viet Hung Nguyen. 2014. An Empirical Methodology to Evaluate Vulnerability Discovery Models. IEEE Transactions on Software Engineering 40, 12 (2014), 1147–1162. https://doi.org/10.1109/TSE.2014.2354037

    2014

  33. [43]

    Fabio Massacci and Ivan Pashchenko. 2021. Technical Leverage: Dependencies Are a Mixed Blessing. IEEE Security & Privacy 19, 3 (2021), 58–62. https://doi.org/10.1109/MSEC.2021.3065627

    2021

  34. [44]

    Fabio Massacci and Ivan Pashchenko. 2021. Technical Leverage in a Software Ecosystem: Development Opportunities and Security Risks. In ICSE. ACM, 1386–1397. https://doi.org/10.1109/ICSE43902.2021.00125

    2021

  35. [45]

    Andrew Meneely, Harshavardhan Srinivasan, Ayemi Musa, Alberto Rodríguez Tejeda, Matthew Mokary, and Brian Spates. 2013. When a Patch Goes Bad: Exploring the Properties of Vulnerability-Contributing Commits. In ESEM. IEEE, 65–74. https://doi.org/10.1109/ESEM.2013.19 Manuscript ...

    2013 doi

  36. [46]

    Andrew Meneely and Laurie Williams. 2010. Strengthening the Empirical Analysis of the Relationship between Linus’ Law and Software Security. In ESEM. ACM. https://doi.org/10.1145/1852786.1852798

    2010

  37. [47]

    Viet Hung Nguyen, Stanislav Dashevskyi, and Fabio Massacci. 2016. An automatic method for assessing the versions affected by a vulnerability. Empirical Software Engineering 21, 6 (2016), 2268–2297. https://doi.org/10.1007/s10664-015-9408-2

    2016 doi

  38. [49]

    Ranindya Paramitha, Yuan Feng, Fabio Massacci, and Carlos E. Budde. 2024. Cross-ecosystem categorization: A manual-curation protocol for the categorization of Java Maven libraries along Python PyPI Topics. https://doi.org/10.48550/arXiv.2403.06300

    2024 doi arXiv

  39. [50]

    Emanuel Parzen. 1962. On Estimation of a Probability Density Function and Mode. The Annals of Mathematical Statistics 33, 3 (1962), 1065–1076. https://doi.org/10.1214/aoms/1177704472

    1962

  40. [51]

    Ivan Pashchenko, Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, and Fabio Massacci. 2018. Vulnerable Open Source Dependencies: Counting Those That Matter. In ESEM. ACM, 10 pages. https://doi.org/10.1145/3239235.3268920

    2018

  41. [52]

    Ivan Pashchenko, Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, and Fabio Massacci. 2022. Vuln4Real: A Methodology for Counting Actually Vulnerable Dependencies. IEEE Transactions on Software Engineering 48, 5 (2022), 1592–1609. https://doi.org/10.1109/TSE.2020.3025443

    2022

  42. [53]

    Mike Pittenger. 2016. Open Source Security Analysis: The State of Open Source Security in Commercial Applications. Technical Report. Black Duck Software. https://www.vojtechruzicka.com/bf4dd32d5823c258c319cced38727dce/OSSAReport.pdf

    2016

  43. [54]

    Santosa, Asankhaya Sharma, and David Lo

    Gede Artha Azriadi Prana, Abhishek Sharma, Lwin Khin Shar, Darius Foo, Andrew E. Santosa, Asankhaya Sharma, and David Lo. 2021. Out of sight, out of mind? How vulnerable dependencies affect open-source projects. Empirical Software Engineering 26, 4 (2021), 34 pages. https: //d...

    2021 doi

  44. [55]

    Tom Preston-Werner. 2013. Semantic Versioning 2.0.0. https://semver.org/spec/v2.0.0.html Creative Commons License

    2013

  45. [56]

    Murray Rosenblatt. 1956. Remarks on Some Nonparametric Estimates of a Density Function. The Annals of Mathematical Statistics 27, 3 (1956), 832–837. https://doi.org/10.1214/aoms/1177728190

    1956

  46. [57]

    Nwankpa, and Yazan F

    Yaman Roumani, Joseph K. Nwankpa, and Yazan F. Roumani. 2015. Time series modeling of vulnerabilities. Computers & Security 51 (2015), 32–40. https://doi.org/10.1016/j.cose.2015.03.003

    2015 doi

  47. [58]

    Skipper Seabold and Josef Perktold. 2010. statsmodels: Econometric and statistical modeling with python. In 9th Python in Science Conference

    2010

  48. [59]

    Nahid Shahmehri, Amel Mammar, Edgardo Montes de Oca, David Byers, Ana Cavalli, Shanai Ardi, and Willy Jimenez. 2012. An advanced approach for modeling and detecting software vulnerabilities. Information and Software Technology 54, 9 (2012), 997–1013. https://doi.org/10.1016/j....

    2012 doi

  49. [60]

    Yonghee Shin, Andrew Meneely, Laurie Williams, and Jason A. Osborne. 2011. Evaluating Complexity, Code Churn, and Developer Activity Metrics as Indicators of Software Vulnerabilities. IEEE Transactions on Software Engineering 37, 6 (2011), 772–787. https://doi.org/10.1109/TSE.2010.81

    2011 doi

  50. [61]

    Snyk vulnerability DB

    SnykDB 2022. Snyk vulnerability DB. Retrieved 04.08.2021 from https://snyk.io/vuln

    2022

  51. [62]

    Jonathan Spring, Eric Hatleback, Allen Householder, Art Manion, and Deana Shick. 2021. Time to Change the CVSS? IEEE Security & Privacy 19, 2 (2021), 74–78. https://doi.org/10.1109/MSEC.2020.3044475

    2021

  52. [63]

    Benjamin Steenhoek, Hongyang Gao, and Wei Le. 2024. Dataflow Analysis-Inspired Deep Learning for Efficient Vulnerability Detection. In ICSE. ACM, Article 16. https://doi.org/10.1145/3597503.3623345

    2024

  53. [64]

    Kazi Zakia Sultana, Vaibhav Anu, and Tai-Yin Chong. 2021. Using software metrics for predicting vulnerable classes and methods in Java projects: A machine learning approach. Journal of Software: Evolution and Process 33, 3 (2021), e2303. https://doi.org/10.1002/smr.2303

    2021 doi

  54. [65]

    Williams

    Kazi Zakia Sultana, Ajay Deo, and Byron J. Williams. 2017. Correlation Analysis among Java Nano-Patterns and Software Vulnerabilities. In HASE. IEEE, 69–76. https://doi.org/10.1109/HASE.2017.18

    2017 doi

  55. [66]

    Williams

    Kazi Zakia Sultana and Byron J. Williams. 2017. Evaluating micro patterns and software metrics in vulnerability prediction. In SoftwareMining. IEEE, 40–47. https://doi.org/10.1109/SOFTWAREMINING.2017.8100852

    2017

  56. [67]

    Xu, and Liming Zhu

    Jiamou Sun, Jieshan Chen, Zhenchang Xing, Qinghua Lu, Xiwei S. Xu, and Liming Zhu. 2024. Where is it? Tracing the Vulnerability-relevant Files from Vulnerability Reports. In ICSE. ACM

    2024

  57. [69]

    Apache Tomcat Versions

    Tomcat. Apache Tomcat Versions. Retrieved 28.01.2022 from https://tomcat.apache.org/whichversion.html

    2022

  58. [70]

    Huanting Wang, Zhanyong Tang, Shin Hwei Tan, Jie Wang, Yuzhe Liu, Hejun Fang, Chunwei Xia, and Zheng Wang. 2024. Combining Structured Static Code Information and Dynamic Symbolic Traces for Software Vulnerability Prediction. In ICSE. ACM

    2024

  59. [71]

    Bozhi Wu, Shangqing Liu, Yang Xiao, Zhiming Li, Jun Sun, and Shang-Wei Lin. 2023. Learning Program Semantics for Vulnerability Detection via Vulnerability-Specific Inter-procedural Slicing. In FSE. ACM, 1371–1383. https://doi.org/10.1145/3611643.3616351

    2023

  60. [72]

    Emrah Yasasin, Julian Prester, Gerit Wagner, and Guido Schryen. 2020. Forecasting IT security vulnerabilities – An empirical analysis. Computers & Security 88 (2020), 24 pages. https://doi.org/10.1016/j.cose.2019.101610

    2020

  61. [73]

    COMP" ) OR LIMIT-TO( SUBJAREA,

    Bin Yuan, Yifan Lu, Yilin Fang, Yueming Wu, Deqing Zou, Zhen Li, Zhi Li, and Hai Jin. 2023. Enhancing Deep Learning-based Vulnerability Detection by Building Behavior Graph Model. In ICSE. ACM, 2262–2274. https://doi.org/10.1109/ICSE48619.2023.00190 Manuscript submitted to ACM...

    2023

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.