Pith. sign in

REVIEW 4 major objections 4 minor 36 references

Tracing Vulnerabilities in Maven: A Study of CVE lifecycles and Dependency Networks

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

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

Pith's one-line read Critical Maven CVEs are patched in 78 days vs 151 for low severity

desk verdict Useful large-scale Maven vulnerability lifecycle data, but the headline response-time claim rests on a metric that is defined inconsistently and reported without uncertainty estimates. read the letter →

arxiv 2502.04621 v2 pith:N4V3AZDH submitted 2025-02-07 cs.SE

Corey Yang-Smith , Ahmad Abdellatif This is my paper · ORCID
classification cs.SE
keywords MavenCVElifecyclevulnerabilitypatchingdependencynetworkspatchadoptionsoftwaresupplychainrepositorymetricsempiricalengineering
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

This paper traces the full lifecycle of 3,362 Maven vulnerabilities, from introduction through disclosure, patching, and adoption by dependent packages. It aims to show that maintainers respond to disclosed vulnerabilities in proportion to severity: critical flaws are patched in about 78 days on average, versus 151 days for low-severity flaws, a 48.3% reduction. It also claims that 81.6% of vulnerabilities are patched before public disclosure, while only 5.6% remain unresolved, and that project characteristics such as issue activity and concentration of contributions among few people correlate with a package having a CVE. Establishing these patterns matters because Maven underpins a large share of Java software, so the speed and behavior of patching in this ecosystem directly affect downstream supply-chain risk.

What carries the argument

The analytical engine is a CVE lifecycle classification built from three dated events: the public disclosure date, the release date of the first patched version, and the first release date of a dependent package that adopts the patch. Comparing the order of these dates partitions vulnerabilities into No-Patch, Patch-Before-Publish, and Publish-Before-Patch categories, and partitions dependent-package behavior into Reactive, Available, and Proactive Adoption. Response time is then measured as the difference between the patch release date and the last vulnerable release date. For the correlation analysis, the mechanism is the rank-biserial correlation coefficient, a non-parametric measure of association between a binary variable and a continuous metric, paired with a non-parametric significance test applied to seventeen repository activity metrics. This machinery is what turns raw vulnerability records and release timestamps into the paper's percentages and day counts.

What would settle it

Recompute the headline numbers using only CVEs whose records give an explicit lower bound for affected versions, and compare patch release dates against the package registry's actual release history for a sample of critical CVEs; if the 151-to-78-day severity gradient or the 81.6% patch-before-publish share collapses, the result is an artifact of incomplete metadata.

Watch

Extended reading notes

Core claim

The central discovery is a severity-driven patching pattern in Maven. In the 12.8% of cases where public disclosure happens before a patch exists, average time-to-patch falls monotonically with severity: 151 days for low, 123 for moderate, 84 for high, and 78 for critical. The other headline result is that the large majority of vulnerabilities, 81.6%, are patched before public disclosure, which the paper interprets as proactive vendor behavior, and only 5.6% have no patch at all. For downstream packages, the most common behavior is adopting an already available patch, accounting for 62.9% of dependency cases, yet adopters still take a median 151 days to do so, while the rarer cases where adoption waits for a post-disclosure patch take 249 days. The paper also reports that repository metrics like issue comment volume, issue closure counts, and contributor concentration correlate with vulnerability presence, though it treats these associations as observational rather than causal.

Load-bearing premise

Every headline number depends on the vulnerability database's publication dates and affected-version ranges being complete and correctly aligned with the dependency graph's release timestamps; if those dates are wrong or missing lower bounds, the 81.6% patch-before-publish share and the 48.3% severity response-time gap can shift or disappear.

Editorial extensions

If this is right

  • If the severity trend holds, security teams can use severity scores to predict which disclosed vulnerabilities will be patched fastest and to flag low-severity backlogs for extra attention.
  • If 81.6% of Maven vulnerabilities are truly patched before disclosure, then public CVE data understates how much proactive patching already happens in the ecosystem.
  • If dependent packages wait a median 151 days even when a fix is available, then ecosystem risk is dominated by adoption lag rather than by patch availability.
  • If activity metrics like issue volume and contributor concentration correlate with CVE presence, then popular, heavily developed libraries deserve extra vulnerability monitoring.
  • If Reactive Adoption takes a median 249 days, then vulnerabilities disclosed before a patch is ready are the highest-leverage target for early-warning tooling.

Reading between the lines

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

  • This synthesis suggests a testable extension: recompute the severity-response gradient after controlling for project size; the paper itself notes issue activity may be a byproduct of scale, and the 48.3% reduction could partly reflect that larger projects have more resources to patch fast.
  • Because vulnerability records often lack lower bounds for affected versions, the paper's negative response times for Patch-Before-Publish cases should be read as lower bounds, meaning true pre-disclosure lead times may be even longer than reported.
  • If the same lifecycle classification were applied to other package ecosystems, the 151-to-78-day severity gradient would become a directly comparable metric for cross-ecosystem patching culture.
  • The correlation results rest on only a small subset of Maven packages that link to publicly accessible development histories, so the CVE-presence correlations may not generalize to the full Maven population.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper studies 3,362 CVEs affecting Maven artifacts by combining OSV.dev vulnerability data with the Goblin dependency graph and OpenDigger GitHub metrics. It formulates three research questions: (RQ1) the lifecycle of vulnerabilities, (RQ2) correlations between repository characteristics and vulnerability presence, and (RQ3) how long directly dependent packages take to adopt patches. The headline finding is that in Publish-Before-Patch cases, maintainers patch critical vulnerabilities in about 78 days compared with 151 days for low-severity vulnerabilities, a 48.3% reduction. The paper also reports that 81.6% of vulnerabilities are patched before public disclosure, that issue-activity and contributor metrics correlate with vulnerability presence, and that Available Patch Adoption is the most common dependent behavior with a median response time of 151 days.

Significance. If the results hold, the paper provides one of the larger automated studies of Maven vulnerability lifecycles, scaling from the 312 manually analyzed CVEs of prior work to 3,362 CVEs. The use of established data sources (OSV.dev, Goblin, OpenDigger), the availability of a replication package, and the explicit acknowledgment of ethical considerations are strengths. The RQ3 dependency-adoption taxonomy (Reactive, Available, Proactive) is a useful framing for patch-propagation behavior. However, the central quantitative claim about severity-dependent response times rests on a metric definition that is internally inconsistent with the reported numbers, and several supporting analyses lack the statistical detail needed to assess their reliability.

major comments (4)
  1. [Section II-B and Table II] The methodology text and the reported numbers contradict each other. Section II-B states that 'the lifecycle is calculated as the time delta, in days, between the CVE Introduction Date and the CVE Patch Date,' which is necessarily non-negative because a patch cannot be released before the vulnerability is introduced. Table II nevertheless reports negative mean times for Patch-Before-Publish (-867, -1128, -897, -790). These values are only possible if the reference point is the CVE Publication Date rather than the CVE Introduction Date. The abstract's phrasing 'after public disclosure' suggests the authors intended publication-to-patch intervals, but the paper never unambiguously defines this metric. The authors must correct this inconsistency: if the intended metric is publication-to-patch, rewrite Section II-B accordingly; if the computed metric is introduction-to-patch, the negative values indicate a computation error. Either way, the headline 48.3% reduction currently lacks a verified and clearly defined measurement basis.
  2. [Section III-A, Table II] The severity trend in Table II is presented as a key result, but no per-cell sample sizes, confidence intervals, or significance tests are reported. The underlying cells are small: low-severity CVEs are 3.12% of the data and Publish-Before-Patch cases are 12.8% overall, so the 151-day versus 78-day comparison may rest on a handful of observations. A point estimate without uncertainty is not sufficient to support the 48.3% reduction claim. Please report the number of CVEs in each Patch-Type by Severity cell, along with confidence intervals or a significance test (e.g., a non-parametric comparison of response-time distributions across severity levels).
  3. [Section II-C and Table III] The correlation analysis acknowledges a 'severe class imbalance between historical repositories with CVEs (456) and those without (10,675)' but does not correct for it. With such imbalance, rank-biserial correlations and Mann-Whitney p-values can be sensitive to base rates and the very large control group can make small differences appear statistically significant. The paper reports effect sizes but no p-values or confidence intervals in Table III, despite claiming 'p < 0.05' for all metrics. Please report the actual p-values or confidence intervals, clarify the unit of analysis (456 CVEs versus 175 repositories with CVEs versus 10,675 non-vulnerable repositories), and consider a sensitivity analysis such as downsampling the majority class or using a prevalence-adjusted effect size.
  4. [Section IV] The threats-to-validity section states that the absence of CVE discovery dates means the calculated time to mitigation 'may not reflect the actual duration maintainers were aware of the vulnerability' and 'providing a lower bound on mitigation delays.' This is directly relevant to the headline interpretation. If the corrected metric is publication-to-patch, the paper should explicitly separate the disclosure-to-patch interval from the introduction-to-patch lifecycle and explain which quantity Table II reports. The current presentation conflates these, and the 'after public disclosure' language in the abstract is not supported by the methodology as written.
minor comments (4)
  1. [Section III-A] There is a typo in the first sentence: 'Patch-Before-Patch' should be 'Patch-Before-Publish'.
  2. [Table II] Table II is labeled 'Mean time to mitigate,' while RQ3 results are reported as medians. Please make the choice of central tendency explicit and consistent, or explain why means are used for RQ1 and medians for RQ3.
  3. [Section III-B] The discussion says 'all metrics (p < 0.05)' but the table does not show the p-values. Please add them or state the exact p-value range, since readers cannot verify the significance claim from Table III.
  4. [Figure 1] The boxplot caption does not indicate what the axes represent or whether the plotted values are raw days or log-transformed. Please clarify, especially since response-time distributions are typically heavy-tailed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all reported metrics are direct measurements from external datasets, with no fitted parameter or self-citation chain.

full rationale

The paper contains no derivation that reduces to its own inputs. Its headline response-time comparisons (151 vs 78 days, 48.3%) are direct arithmetic summaries of OSV.dev publication dates and Goblin release timestamps; no parameter is fitted and then renamed as a prediction. The patch-type taxonomy (Publish-Before-Patch, Patch-Before-Publish, No-Patch) is an operational classification of date order, not a quantity derived from the response-time metric it explains. The severity trend is an observed empirical relationship from external severity labels. The RQ2 correlations are direct rank-biserial effect sizes on OpenDigger metrics, and RQ3 adoption medians are directly measured from dependency graph release dates. Citations to prior work ([12], [13]) are external and not load-bearing for any uniqueness claim. There is a notable internal-consistency concern: Section II-B states the lifecycle is the delta between CVE Introduction Date and CVE Patch Date, while Table II reports negative values for Patch-Before-Publish, which that definition cannot produce; however, an inconsistency between stated metric and reported numbers is a correctness and reporting issue, not circularity. No self-citation chain or definitional equivalence forces these conclusions.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central findings rely on external data completeness and on testing procedures that are used despite acknowledged limitations. No free parameters are fitted, and no new theoretical entities are introduced.

assumptions (5)
  • domain assumption OSV.dev records provide accurate and complete publication dates and vulnerable version ranges for Maven CVEs.
    All lifecycle classifications and response-time calculations use these timestamps as ground truth; the paper notes missing lower bounds as a threat.
  • domain assumption The Goblin dataset accurately represents Maven releases, release timestamps, and dependency edges.
    Release dates and dependency relationships come entirely from this dataset.
  • ad hoc to paper Rank-biserial correlation and Mann-Whitney U tests remain valid despite the severe class imbalance (456 vs 10,675).
    The paper acknowledges the imbalance may compromise reliability but proceeds without correction or matching.
  • domain assumption GitHub repository metrics collected up to the CVE patch date reflect the project state during the vulnerable period.
    Historic metrics are reconstructed by OpenDigger from GHArchive events and assume the SCM link in pom.xml maps to the correct repository.
  • ad hoc to paper Missing CVE discovery dates do not systematically bias the relative severity response-time comparison.
    The paper states no discovery dates are available and time-to-mitigation is a proxy, yet the severity trend is reported as a key finding.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Tracing Vulnerabilities in Maven: A Study of CVE lifecycles and Dependency Networks." pith.science (2026). https://pith.science/paper/N4V3AZDH

@misc{pith2026250204621,
  author       = {Pith},
  title        = {Pith review of: Tracing Vulnerabilities in Maven: A Study of CVE lifecycles and Dependency Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/N4V3AZDH}},
  note         = {Machine review of arXiv:2502.04621}
}
abstract

Software ecosystems rely on centralized package registries, such as Maven, to enable code reuse and collaboration. However, the interconnected nature of these ecosystems amplifies the risks posed by security vulnerabilities in direct and transitive dependencies. While numerous studies have examined vulnerabilities in Maven and other ecosystems, there remains a gap in understanding the behavior of vulnerabilities across parent and dependent packages, and the response times of maintainers in addressing vulnerabilities. This study analyzes the lifecycle of 3,362 CVEs in Maven to uncover patterns in vulnerability mitigation and identify factors influencing at-risk packages. We conducted a comprehensive study integrating temporal analyses of CVE lifecycles, correlation analyses of GitHub repository metrics, and assessments of library maintainers' response times to patch vulnerabilities, utilizing a package dependency graph for Maven. A key finding reveals a trend in "Publish-Before-Patch" scenarios: maintainers prioritize patching severe vulnerabilities more quickly after public disclosure, reducing response time by 48.3% from low (151 days) to critical severity (78 days). Additionally, project characteristics, such as contributor absence factor and issue activity, strongly correlate with the presence of CVEs. Leveraging tools such as the Goblin Ecosystem, OSV$.$dev, and OpenDigger, our findings provide insights into the practices and challenges of managing security risks in Maven.

Figures

Figures reproduced from arXiv: 2502.04621 by the authors.

Figure 1
Figure 1. Boxplot of response time per dependent behavior. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 33 canonical work pages

  1. [1]

    Structure and evolution of package dependency networks,

    R. Kikas, G. Gousios, M. Dumas, and D. Pfahl, “Structure and evolution of package dependency networks,” in 2017 IEEE/ACM 14th Interna- tional Conference on Mining Software Repositories (MSR). IEEE, 2017, pp. 102–112

    work page 2017

  2. [2]

    Analyzing the direct and transitive impact of vulnerabilities onto different artifact repositories,

    J. D ¨using and B. Hermann, “Analyzing the direct and transitive impact of vulnerabilities onto different artifact repositories,” Digital Threats: Research and Practice , vol. 3, no. 4, pp. 1–25, 2022

    work page 2022

  3. [3]

    Software vulnerabilities overview: A descriptive study,

    M. C. S ´anchez, J. M. C. de Gea, J. L. Fern ´andez-Alem´an, J. Garceran, and A. Toval, “Software vulnerabilities overview: A descriptive study,” Tsinghua Science and Technology , vol. 25, no. 2, pp. 270–280, 2020

    work page 2020

  4. [4]

    Common vulnerabilities and exposures (cve): Overview,

    M. Corporation, “Common vulnerabilities and exposures (cve): Overview,” 2024, accessed: 2024-11-30. [Online]. Available: https: //www.cve.org/about/overview

    work page 2024

  5. [5]

    Osv: Open source vulnerabilities,

    G. O. S. S. Team, “Osv: Open source vulnerabilities,” 2024, accessed: 2024-11-30. [Online]. Available: https://osv.dev

    work page 2024

  6. [6]

    Stack overflow developer survey 2024,

    Stack Overflow, “Stack overflow developer survey 2024,” 2024, accessed: 2024-11-30. [Online]. Available: https://survey.stackoverflow. co/2024/

    work page 2024

  7. [7]

    Maven repository: Central repository search,

    “Maven repository: Central repository search,” 2024, accessed: 2024- 12-08. [Online]. Available: https://mvnrepository.com/repos

    work page 2024

  8. [8]

    Empirical analysis of security vulnerabilities in python packages,

    M. Alfadel, D. E. Costa, and E. Shihab, “Empirical analysis of security vulnerabilities in python packages,” Empirical Software Engineering , vol. 28, no. 3, p. 59, 2023

    work page 2023

Show all 36 references
  1. [9]

    On the discoverability of npm vulnerabilities in node.js projects,

    M. Alfadel, D. E. Costa, E. Shihab, and B. Adams, “On the discoverability of npm vulnerabilities in node.js projects,” ACM Transactions on Software Engineering and Methodology, vol. 32, pp. 1 – 27, 2022. [Online]. Available: https://api.semanticscholar.org/CorpusID: 253708713

    2022

  2. [10]

    Vulnerability of package dependency networks,

    D. Set ´o-Rey, J. I. Santos-Mart´ın, and C. L ´opez-Nozal, “Vulnerability of package dependency networks,” IEEE Transactions on Network Science and Engineering, vol. 10, no. 6, pp. 3396–3408, 2023

    2023

  3. [11]

    Understanding the threats of upstream vulnerabilities to downstream projects in the maven ecosystem,

    Y . Wu, Z. Yu, M. Wen, Q. Li, D. Zou, and H. Jin, “Understanding the threats of upstream vulnerabilities to downstream projects in the maven ecosystem,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) , 2023, pp. 1046–1058

    2023

  4. [12]

    Discovery of timeline and crowd reaction of software vulnerability disclosures,

    Y . W. Heng, Z. Ma, H. Zhang, Z. Li et al. , “Discovery of timeline and crowd reaction of software vulnerability disclosures,” arXiv preprint arXiv:2411.07480, 2024

    2024 arXiv

  5. [13]

    Navigating and exploring software dependency graphs using goblin,

    D. Jaime, J. El Haddad, and P. Poizat, “Navigating and exploring software dependency graphs using goblin,” in Proceedings of the In- ternational Conference on Mining Software Repositories (MSR 2025) , 2025

    2025

  6. [14]

    Charac- terizing dependency update practice of npm, pypi and cargo packages,

    I. Rahman, N. Zahan, S. Magill, W. Enck, and L. Williams, “Charac- terizing dependency update practice of npm, pypi and cargo packages,” arXiv preprint arXiv:2403.17382 , 2024

    2024

  7. [15]

    Preprint: Can the openssf scorecard be used to measure the security posture of npm and pypi?

    N. Zahan, P. Kanakiya, B. Hambleton, S. Shohan, and L. Williams, “Preprint: Can the openssf scorecard be used to measure the security posture of npm and pypi?” arXiv preprint arXiv:2208.03412 , 2022

    2022 arXiv

  8. [16]

    Sonatype central search rest api guide,

    Sonatype, Inc., “Sonatype central search rest api guide,” https://central. sonatype.org/search/rest-api-guide/, n.d., accessed: 2024-11-30

    2024

  9. [17]

    OpenDigger,

    S. Zhao, X. Zhang, and X. Xia, “OpenDigger,” Apr. 2021. [Online]. Available: https://github.com/X-lab2017/open-digger

    2021

  10. [18]

    GH Archive,

    GH Archive, “GH Archive,” http://www.gharchive.org, 2024, accessed: 2024-11-30

    2024

  11. [19]

    CHAOSS: Community Health Analytics Open Source Software,

    CHAOSS Community, “CHAOSS: Community Health Analytics Open Source Software,” 2025, accessed: 2025-02-05. [Online]. Available: https://chaoss.community

    2025

  12. [20]

    X-Lab: Unlocking Innovation,

    X-Lab, “X-Lab: Unlocking Innovation,” 2025, accessed: 2025-02-05. [Online]. Available: https://www.x-lab.info

    2025

  13. [21]

    On a test of whether one of two random variables is stochastically larger than the other,

    H. B. Mann and D. R. Whitney, “On a test of whether one of two random variables is stochastically larger than the other,” Annals of Mathematical Statistics, vol. 18, no. 1, pp. 50–60, March 1947

    1947

  14. [22]

    On the use of refactoring in security vulnerability fixes: An exploratory study on maven libraries,

    A. Ikegami, R. G. Kula, B. Chinthanet, V . Maeprasart, A. Ouni, T. Ishio, and K. Matsumoto, “On the use of refactoring in security vulnerability fixes: An exploratory study on maven libraries,” in Proceedings of the 26th International Conference on Evaluation and Assessment in...

    2022

  15. [23]

    Contributor absence factor,

    CHAOSS Project, “Contributor absence factor,” 2025, ac- cessed: 2025-02-01. [Online]. Available: https://chaoss.community/ kb/metric-contributor-absence-factor/

    2025

  16. [24]

    Empirical findings on team size and productivity in software development,

    D. Rodriguez, M. Sicilia, E. Barriocanal, and R. Harrison, “Empirical findings on team size and productivity in software development,”Journal of Systems and Software - JSS , vol. 85, 03 2012

    2012

  17. [25]

    Evaluating complexity, code churn, and developer activity metrics as indicators of software vulnerabilities,

    Y . Shin, A. Meneely, L. Williams, and J. A. Osborne, “Evaluating complexity, code churn, and developer activity metrics as indicators of software vulnerabilities,” IEEE Transactions on Software Engineering , vol. 37, no. 6, pp. 772–787, 2011

    2011

  18. [26]

    An empirical investigation of the security weaknesses in open-source projects,

    H. Al-Shammare, N. Al-Otaiby, M. Al-Otabi, and M. Alshayeb, “An empirical investigation of the security weaknesses in open-source projects,” in Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering , ser. EASE ’24. New York, NY ,...

    2024

  19. [27]

    Correlation between github stars and code vulnerabilities,

    M. S. Naveed, “Correlation between github stars and code vulnerabilities,” Journal of Computing & Biomedical Informatics , vol. 4, no. 01, pp. 141–151, Dec. 2022. [Online]. Available: https://jcbi.org/index.php/Main/article/view/111

    2022

  20. [28]

    Mitigating persistence of open-source vulnerabilities in maven ecosystem,

    L. Zhang, C. Liu, S. Chen, Z. Xu, L. Fan, L. Zhao, Y . Zhang, and Y . Liu, “Mitigating persistence of open-source vulnerabilities in maven ecosystem,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 2023, pp. 191–203

    2023

  21. [29]

    Tracking known security vulnerabilities in proprietary software systems,

    M. Cadariu, E. Bouwers, J. Visser, and A. Van Deursen, “Tracking known security vulnerabilities in proprietary software systems,” in 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER) . IEEE, 2015, pp. 516–519

    2015

  22. [30]

    On the security blind spots of software composition analysis,

    J. Dietrich, S. Rasheed, A. Jordan, and T. White, “On the security blind spots of software composition analysis,” in Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, 2023, pp. 77–87

    2024

  23. [31]

    A large-scale security- oriented static analysis of python packages in pypi,

    J. Ruohonen, K. Hjerppe, and K. Rindell, “A large-scale security- oriented static analysis of python packages in pypi,” in 2021 18th International Conference on Privacy, Security and Trust (PST) , 2021, pp. 1–10

    2021

  24. [32]

    On the impact of security vulnerabilities in the npm and rubygems dependency networks,

    A. Zerouali, T. Mens, A. Decan, and C. De Roover, “On the impact of security vulnerabilities in the npm and rubygems dependency networks,” Empirical Softw. Engg., vol. 27, no. 5, Sep. 2022. [Online]. Available: https://doi.org/10.1007/s10664-022-10154-1

    2022 doi

  25. [33]

    Small world with high risks: A study of security threats in the npm ecosystem,

    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 28th USENIX Security Symposium (USENIX Security 19) . Santa Clara, CA: USENIX Association, Aug. 2019, pp. 995–1010. [Online]. Available: ht...

    2019

  26. [34]

    On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,

    A. M. Mir, M. Keshani, and S. Proksch, “On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,”

  27. [35]

    Ethics in the mining of software repositories,

    N. E. Gold and J. Krinke, “Ethics in the mining of software repositories,” Empirical Software Engineering , vol. 27, no. 1, p. 17, Nov. 2021. [Online]. Available: https://doi.org/10.1007/s10664-021-10057-7

    2021 doi

  28. [2023]

    Available: https://arxiv.org/abs/2301.07972

    [Online]. Available: https://arxiv.org/abs/2301.07972

    arXiv

Pith tools

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