Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Open Source, Open Threats? Investigating Security Challenges in Open-Source Software

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

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

Pith's one-line read Open-source security is worsening: reported vulnerabilities grow 98% a year, fixes take longer, and NPM and PyPI carry large malicious-package shares.

desk verdict Worth reviewing, but the headline growth numbers are shaky until the authors clarify their counting rules and fix internal inconsistencies. read the letter →

arxiv 2506.12995 v1 pith:5KPGZMSG submitted 2025-06-15 cs.CR

Seyed Ali Akhavani , Behzad Ousat , Amin Kharraz This is my paper
classification cs.CR
keywords open-sourcesoftwaresecuritysupplychainattacksvulnerabilitytrendsCommonWeaknessEnumerationCWE-506maliciouspackagesNPMecosystemPyPI
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 sets out to establish that the security posture of open-source software is deteriorating as the ecosystem expands, based on 31,267 vulnerability reports covering 14,675 packages across 10 programming languages and 8 package managers from 2017 to 2025. The headline evidence is that reported vulnerabilities grew at an average annual rate of 98% while the total package count grew about 25% per year, and that the average lifespan of a vulnerability rose by 85% over the same period. The paper also finds a striking concentration: on average, just seven Common Weakness Enumeration (CWE) types account for over 50% of all reported vulnerabilities, and intentionally malicious packages make up 48.58% of NPM reports and 13.92% of PyPI reports. A sympathetic reader would care because these numbers quantify the supply-chain risk of the foundational libraries that modern applications depend on, and because they suggest where defenses could be targeted.

What carries the argument

The instrument carrying the argument is a unified longitudinal dataset built by merging 31,267 deduplicated vulnerability reports from the GitHub Advisory Database and Snyk.io with package-count and version-release metadata from Libraries.io and archived Wayback Machine snapshots. The key derived metric is vulnerability lifespan, defined as the sum, over a package's affected version ranges, of the time from the first vulnerable release to the first patched release; this measure is what supports the claim that vulnerabilities persist longer over time. The second mechanism is CWE classification, especially CWE-506 (Embedded Malicious Code), which separates intentionally malicious packages from accidental flaws and drives the supply-chain attack analysis.

What would settle it

Re-run the vulnerability-lifespan analysis as a survival study: treat every report with no patched release as still open on the data cutoff date, and recompute the average time from first vulnerable release to first patched release. If the 85% rise over 2017-2024 shrinks or disappears once these censored cases are counted, the persistence finding is an artifact of dropping unfixed recent vulnerabilities rather than a real slowdown in fixes.

Watch

Extended reading notes

Core claim

The central discovery, stated on the paper's own terms, is that open-source package ecosystems are becoming less secure even as they grow: reported vulnerabilities increased at an average annual rate of 98% during the study period, far outpacing the 25% average growth in the number of packages. Vulnerability lifespans grew from roughly 1,056 to 1,956 days on average, an increase of about 85%, which the paper interprets as evidence that fixes are not keeping pace with discoveries. The paper further finds that a small set of weakness classes drives most reports - on average seven CWEs account for over half of all vulnerabilities across ecosystems - with web-oriented weaknesses such as cross-site scripting (CWE-79) and path traversal (CWE-22) appearing broadly while memory-safety weaknesses such as heap-based buffer overflow (CWE-122) are tied to C/C++ and prototype pollution (CWE-1321) to JavaScript. Finally, it documents a large and growing class of intentionally malicious packages (CWE-506), with 4,456 reports concentrated almost entirely in NPM and PyPI, and attacks executed through typosquatting, dependency confusion, and installation-hook exploitation.

Load-bearing premise

The claim that vulnerabilities persist 85% longer assumes that summing, for each package, the time from the first affected version to the first patched version over all affected ranges gives a fair measure of persistence, with no clear treatment of vulnerabilities that still have no patched release, and version-release metadata exists for only 11,316 of the 14,675 affected packages.

Editorial extensions

If this is right

  • If the 98% annual growth in reported vulnerabilities is real, security teams can expect the volume of newly disclosed open-source flaws to roughly quadruple relative to the package base they support, making automated triage necessary.
  • If vulnerabilities persist 85% longer on average, prompt upgrading to patched versions becomes more valuable, because the window in which a known flaw remains exploitable is widening.
  • Because on average seven CWEs account for over half of all reported vulnerabilities per ecosystem, defenses aimed at those specific weakness classes could plausibly address a majority of reports.
  • Because malicious packages account for 48.58% of NPM reports and 13.92% of PyPI reports, registry operators need detection oriented to intentional attacks, such as name-similarity checks, dependency-confusion scanning, and install-script monitoring, alongside classic patching workflows.

Reading between the lines

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

  • Implicit in the data but not tested by the paper: the 98% versus 25% comparison counts reported vulnerabilities, not vulnerability incidence, so rising reporting effort from scanners, researchers, and regulation could explain part of the gap; the true per-package risk increase is likely smaller than fourfold.
  • A testable extension of the lifespan analysis would re-run it with survival analysis that treats unpatched vulnerabilities as censored; the reported 85% increase may shrink or vanish once recent, still-unfixed reports are included.
  • The CWE-506 shares are computed within advisory databases whose malicious packages were removed after takedown; a registry-wide cohort study of all published NPM and PyPI packages could turn the 49% and 14% figures into true prevalence estimates.
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 / 6 minor

Summary. This paper presents a longitudinal observational study of 31,267 vulnerability reports collected from the GitHub Advisory Database and Snyk.io, covering 14,675 packages across 10 programming languages and 8 package managers from 2017 to January 2025. The authors report three main findings: (i) the annual growth rate of vulnerable packages (98% in the abstract, 91% in Section 5.1) far exceeds the 25% growth of total packages; (ii) the average vulnerability lifespan increased by 85% (1,056 to 1,956 days); and (iii) on average, seven CWEs account for over 50% of reported vulnerabilities across ecosystems. The paper also analyzes CWE-506 (embedded malicious code), reporting that it constitutes 48.58% of NPM and 13.92% of PyPI vulnerability reports, and discusses attack vectors such as typosquatting, dependency confusion, and installation-hook abuse. The authors release the dataset and analysis scripts.

Significance. If the reported trends are robust, this work would provide the most comprehensive cross-ecosystem longitudinal view of OSS vulnerabilities to date, extending prior studies to C/C++ and to a substantially larger report corpus, and would offer a useful baseline for policy discussions and for the design of automated vulnerability detection. The public release of the dataset and scripts is a concrete strength. However, the central quantitative claims (the 98%/91% vs 25% growth comparison and the 85% lifespan increase) are sensitive to counting definitions, data filtering, and censoring, and the paper does not currently provide the sensitivity analyses needed to establish that these results are not artifacts of those choices.

major comments (4)
  1. [Section 5.1 / Figure 3 / Abstract] The definition of the 'vulnerable packages' count used for growth-rate calculation is not specified. The text defines growth rate as year-over-year percentage change, but it does not state whether the vulnerable-package count is the number of packages newly reported as vulnerable in each year, the cumulative number of distinct vulnerable packages, or the count of affected package-version records. The total-package counts, taken from Libraries.io snapshots via the Wayback Machine (Section 4.2), are point-in-time registry sizes; comparing them to an unspecified vulnerable-package count may not be apples-to-apples. Moreover, the abstract and conclusion report a 98% annual increase while Section 5.1 reports 91%, and this discrepancy is never reconciled. No confidence intervals or significance tests are reported for either growth rate. Since this comparison is the central RQ1 claim, please clarify the counting unit and provide the underlying time series and uncertainty estimates.
  2. [Section 5.2 / Appendix A] The lifespan analysis sums, for each package, the durations of all affected version ranges from the first vulnerable release to the first patched release (Appendix A). The paper does not state how vulnerabilities with no patched release are treated, and Section 4.2 reports that version metadata is available for only 11,316 of the 14,675 affected packages. If vulnerabilities lacking a patched release are excluded, the reported increase in average lifespan from 1,056 to 1,956 days (an 85% increase) could be an artifact of right-censoring: recent vulnerabilities are less likely to have a patched release yet. Please report the proportion of observations with a patched release, and provide a sensitivity analysis that treats unfixed cases as censored (e.g., a survival-based estimator or a lower-bound analysis).
  3. [Section 4.3] The filtering decisions in dataset generation are not tested for their effect on the headline results. Removing 6,770 reports with discouraged or prohibited CWEs (including CWE-400 and CWE-200) can remove a large share of early NVD-sourced reports, mechanically increasing year-over-year growth rates. Similarly, using only GitHub-reviewed advisories and excluding 242,000+ unreviewed advisories changes the denominator and the vulnerability mix. The paper should quantify how the RQ1 growth rates, the 'seven CWEs account for over 50%' finding, and the CWE-506 percentages change when these exclusions are relaxed or when unreviewed advisories are included as a robustness check.
  4. [Abstract / Introduction / Section 7] The headline numbers are inconsistent across the paper: the abstract and conclusion state a 98% annual increase in vulnerable packages, while Section 5.1 states 91%; the introduction states that lifespan increased by 95% from 2017 to 2024, while the abstract, RQ2, and Section 5.2 state 85%. These discrepancies are not explained and directly affect the paper's central claims. Please reconcile them or clarify that different time windows or metrics produce the different values.
minor comments (6)
  1. [Table 3 / Section 5.4] The reported percentages for CWE-506 (48.58% for NPM and 13.92% for PyPI) do not match the totals in Table 2 (3,893/8,237 = 47.3% and 518/3,907 = 13.3%). Please recompute these values or clarify the denominator used.
  2. [Section 5.2] The sentence 'The data suggests that RubyGems and NPM have the highest number of published versions of different packages per day, with an average of 0.06 versions while we saw that it has the largest vulnerability lifespan' is confusingly worded; please rephrase to indicate which ecosystem has the largest lifespan and how version publication frequency is computed.
  3. [Section 5.4] The analysis of attack vectors names typosquatting, dependency confusion, and installation-hook exploitation as the three dominant vectors, but the paper does not report how many of the 4,456 CWE-506 packages fall into each category. Providing these counts would strengthen the claim.
  4. [Section 4.2] For the historical package counts collected from the Wayback Machine, please state the exact snapshot dates and how missing snapshots are handled; this affects the reproducibility of the 25% growth figure.
  5. [Figure 5] The 'Overall Average' series in Figure 5 is not defined; please specify whether it is an unweighted average over ecosystems or a vulnerability-weighted average.
  6. [General] There are several minor typos, e.g., 'detail analysis' in the contribution list and 'Pashchenko et al. [29] study' in Section 2.3; proofreading is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an observational study of external advisory databases whose reported trends are direct aggregations of the data, not outputs of a fitted model or of a self-citation chain.

full rationale

This paper does not derive its conclusions from its own assumptions in a circular way. The central claims—vulnerability growth outpacing package growth, increasing vulnerability lifespan, CWE concentration, and the prevalence of CWE-506 packages—are all computed directly from external vulnerability advisories (GitHub Advisory Database and Snyk.io) and package metadata. No parameter is fitted to the data and then renamed as a prediction, and no result is defined in terms of the quantity it claims to explain. The growth rates are year-over-year percentage changes in reported counts, which are straightforward summaries of the collected dataset. The paper makes no self-citations that carry a load-bearing argument, and it does not invoke any uniqueness theorem or prior-authority result to force its interpretation. The identified methodological concerns, such as the unreported handling of vulnerabilities without patched versions in the lifespan calculation and the discrepancy between the 98% and 91% growth figures, are empirical or reporting issues that could affect validity, but they are not circularity: the conclusions are not equivalent to the inputs by construction. Overall, the derivation chain is self-contained relative to the external data sources, and the paper's findings remain independently checkable against those sources. Therefore, the circularity score is 0.

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

No fitted constants or hand-tuned parameters are introduced, and the paper postulates no new entities. All reported quantities are direct aggregations of the advisory datasets. The analysis rests on data-source representativeness and measurement definitions.

assumptions (4)
  • domain assumption GitHub-reviewed advisories and Snyk provide a representative sample of OSS vulnerabilities
    Section 4.1 excludes 242,000+ unreviewed GitHub advisories; if unreviewed advisories follow different trends, the reported growth rates are biased.
  • domain assumption Vulnerability lifespan is accurately measured as the summed durations of affected version ranges
    Sections 5.2 and Appendix A define this metric, but no treatment of censored or unfixed vulnerabilities is described.
  • domain assumption Removing MITRE-discouraged CWEs removes noise rather than signal
    Section 4.3 removes 6,770 reports with CWEs such as CWE-400 and CWE-200; this can materially affect the seven CWEs account for 50% result.
  • domain assumption Wayback Machine snapshots of Libraries.io provide accurate historical package counts
    Section 4.2 uses two snapshots per year; temporary registry cleanups such as the Go 2021 drop are interpreted as real package declines.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Open Source, Open Threats? Investigating Security Challenges in Open-Source Software." pith.science (2026). https://pith.science/paper/5KPGZMSG

@misc{pith2026250612995,
  author       = {Pith},
  title        = {Pith review of: Open Source, Open Threats? Investigating Security Challenges in Open-Source Software},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5KPGZMSG}},
  note         = {Machine review of arXiv:2506.12995}
}
read the original abstract

Open-source software (OSS) has become increasingly more popular across different domains. However, this rapid development and widespread adoption come with a security cost. The growing complexity and openness of OSS ecosystems have led to increased exposure to vulnerabilities and attack surfaces. This paper investigates the trends and patterns of reported vulnerabilities within OSS platforms, focusing on the implications of these findings for security practices. To understand the dynamics of OSS vulnerabilities, we analyze a comprehensive dataset comprising 31,267 unique vulnerability reports from GitHub's advisory database and Snyk.io, belonging to 14,675 packages across 10 programming languages. Our analysis reveals a significant surge in reported vulnerabilities, increasing at an annual rate of 98%, far outpacing the 25% average annual growth in the number of open-source software (OSS) packages. Additionally, we observe an 85% increase in the average lifespan of vulnerabilities across ecosystems during the studied period, indicating a potential decline in security. We identify the most prevalent Common Weakness Enumerations (CWEs) across programming languages and find that, on average, just seven CWEs are responsible for over 50% of all reported vulnerabilities. We further examine these commonly observed CWEs and highlight ecosystem-specific trends. Notably, we find that vulnerabilities associated with intentionally malicious packages comprise 49% of reports in the NPM ecosystem and 14% in PyPI, an alarming indication of targeted attacks within package repositories. We conclude with an in-depth discussion of the characteristics and attack vectors associated with these malicious packages.

Figures

Figures reproduced from arXiv: 2506.12995 by the authors.

Figure 1
Figure 1. Number of vulnerabilities reported across ecosystems [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Overview of total packages existing in each package man [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 5
Figure 5. Vulnerability lifespans trend across platforms. While the [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figures from the paper (3 more)
Figure 6
Figure 6. Figure 6: Vulnerability concentration in vulnerable packages across [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Cumulative graph of vulnerabilities based on top CWEs. A [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 9
Figure 9. Figure 9: Top five most reported CWEs in each ecosystem over time. [PITH_FULL_IMAGE:figures/full_fig_p014_9.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images

    cs.CR 2026-08 conditional novelty 6.0 of 10

    Near-universal vulnerabilities and misconfigurations among high-exposure Docker Hub images, with three scanners agreeing on only 2.7% of distinct vulnerability groups.

Reference graph

Works this paper leans on

80 extracted references · 77 canonical work pages · cited by 1 Pith paper

  1. [1]

    As- apy: A python library for aerospace simulation analysis,

    J. P. Dantas, S. R. Silva, V . C. Gomes, A. N. Costa, A. R. Samersla, D. Geraldo, M. R. Maximo, and T. Yoneyama, “As- apy: A python library for aerospace simulation analysis,” in Proceedings of the 38th ACM SIGSIM Conference on Principles of Advanced Discrete Simulation, pp. 15–24, 2024

    work page 2024

  2. [2]

    A comprehensive review of cyber-attacks and defense mechanisms for improving security in smart grid en- ergy systems: Past, present and future,

    M. Ghiasi, T. Niknam, Z. Wang, M. Mehrandezh, M. Dehghani, and N. Ghadimi, “A comprehensive review of cyber-attacks and defense mechanisms for improving security in smart grid en- ergy systems: Past, present and future,”Electric Power Systems Research, vol. 215, p. 108975, 2023

    work page 2023

  3. [3]

    Formation control method based on artificial potential fields for aircraft flight simulation,

    A. N. Costa, F. L. Medeiros, J. P. Dantas, D. Geraldo, and N. Y . Soma, “Formation control method based on artificial potential fields for aircraft flight simulation,”Simulation, vol. 98, no. 7, pp. 575–595, 2022

    work page 2022

  4. [4]

    Open source soft- ware and global entrepreneurship,

    N. L. Wright, F. Nagle, and S. Greenstein, “Open source soft- ware and global entrepreneurship,”Research Policy, vol. 52, no. 9, p. 104846, 2023

    work page 2023

  5. [5]

    Fingpt: Open- source financial large language models,

    H. Yang, X.-Y . Liu, and C. D. Wang, “Fingpt: Open- source financial large language models,”arXiv preprint arXiv:2306.06031, 2023

    arXiv 2023

  6. [6]

    Improving uptake of simulation in healthcare: User-driven development of an open-source tool for modelling patient flow,

    J. M. Tyler, B. J. Murch, C. Vasilakis, and R. M. Wood, “Improving uptake of simulation in healthcare: User-driven development of an open-source tool for modelling patient flow,” Journal of Simulation, vol. 17, no. 6, pp. 765–782, 2023

    work page 2023

  7. [7]

    Open source development: A double-edged sword,

    vUpgradeU, “Open source development: A double-edged sword,” 2023. Accessed: 2024-10-15

    work page 2023

  8. [8]

    Impact of using open source software on cyberse- curity,

    CyberSaint, “Impact of using open source software on cyberse- curity,” 2023. Accessed: 2024-10-15

    work page 2023

Show all 80 references
  1. [9]

    27 malicious pypi packages with info- stealing capabilities discovered,

    The Hacker News, “27 malicious pypi packages with info- stealing capabilities discovered,” 2023. Accessed: 2024-10-14

    2023

  2. [10]

    The hidden economy of open source software,

    Sysdig, “The hidden economy of open source software,” 2023. Accessed: 2024-10-15

    2023

  3. [11]

    Dozens of npm packages caught attempting to deploy reverse shell,

    Phylum, “Dozens of npm packages caught attempting to deploy reverse shell,” 2023

    2023

  4. [12]

    Hundreds of malicious python packages found stealing sensitive data,

    Bleeping Computer, “Hundreds of malicious python packages found stealing sensitive data,” 2023. Accessed: 2024-10-14

    2023

  5. [13]

    Securing open source software act

    United States Congress, “Securing open source software act.” https://www.govinfo.gov/content/pkg/BILLS-117s4913is/ pdf/BILLS-117s4913is.pdf, 2021. Accessed: 2024-10-07

    2021

  6. [14]

    Summary of the 2023 request for information on open source software security

    The White House, “Summary of the 2023 request for information on open source software security.” https://www.whitehouse.gov/wp-content/uploads/2024/08/ Summary-of-the-2023-Request-for-Information-on-Open- Source-Software-Security.pdf, 2024. Accessed: 2024-10-07

    2023

  7. [15]

    Cisa open source software security roadmap

    Cybersecurity and I. S. A. (CISA), “Cisa open source software security roadmap.” https://www.cisa.gov/resources-tools/ resources/cisa-open-source-software-security-roadmap, 2023. Accessed: 2025-01-22

    2023

  8. [16]

    Top web development languages

    GeeksforGeeks, “Top web development languages.” Accessed: 2024-12-16

    2024

  9. [17]

    Best languages for web development

    LambdaTest, “Best languages for web development.” Accessed: 2024-12-16

    2024

  10. [18]

    Best languages for web development

    BrowserStack, “Best languages for web development.” Ac- cessed: 2024-12-16

    2024

  11. [19]

    Best languages for web development

    S. Academy, “Best languages for web development.” Accessed: 2024-12-16

    2024

  12. [20]

    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. 59, 2023

    2023

  13. [21]

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

    M. Zimmermannet al., “Small world with high risks: A study of security threats in the npm ecosystem,” in28th USENIX Security Symposium (USENIX Security 19), pp. 995–1010, 2019. 12

    2019

  14. [22]

    Towards measuring supply chain attacks on package managers for interpreted languages,

    R. Duanet al., “Towards measuring supply chain attacks on package managers for interpreted languages,”arXiv preprint arXiv:2002.01139, 2021. Presented at NDSS

    2002 arXiv

  15. [23]

    Do software security practices yield fewer vul- nerabilities?,

    N. Zahanet al., “Do software security practices yield fewer vul- nerabilities?,” in2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pp. 231–240, IEEE, 2023

    2023

  16. [24]

    An empirical comparison of dependency issues in oss packaging ecosystems,

    A. Decan, T. Mens, and M. Claes, “An empirical comparison of dependency issues in oss packaging ecosystems,” in2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 2–12, IEEE, 2017

    2017

  17. [25]

    An empirical comparison of dependency network evolution in seven software packaging ecosystems,

    A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,”Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019

    2019

  18. [26]

    Structure and evolution of package dependency networks,

    R. Kikaset al., “Structure and evolution of package dependency networks,” in2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR), pp. 102–112, IEEE, 2017

    2017

  19. [27]

    On the impact of se- curity vulnerabilities in the npm package dependency network,

    A. Decan, T. Mens, and E. Constantinou, “On the impact of se- curity vulnerabilities in the npm package dependency network,” inProceedings of the 15th International Conference on Mining Software Repositories, pp. 181–191, 2018

    2018

  20. [28]

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

    A. Zeroualiet al., “On the impact of security vulnerabilities in the npm and rubygems dependency networks,”Empirical Software Engineering, vol. 27, no. 5, p. 107, 2022

    2022

  21. [29]

    Vulnerable open source dependen- cies: Counting those that matter,

    I. Pashchenkoet al., “Vulnerable open source dependen- cies: Counting those that matter,” inProceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 2018

    2018

  22. [30]

    Common vulnerabilities and exposures (cve)

    MITRE, “Common vulnerabilities and exposures (cve).” https: //cve.mitre.org/about/, 2024. Accessed: 2024-10-13

    2024

  23. [31]

    Mitre corporation

    MITRE, “Mitre corporation.” https://www.mitre.org/. Accessed: 2024-10-13

    2024

  24. [32]

    Common weakness enumeration (cwe)

    C. Team, “Common weakness enumeration (cwe).” https:// cwe.mitre.org/, 2024. Accessed: 2024-10-13

    2024

  25. [33]

    National vulnerability database (nvd)

    N. I. of Standards and T. (NIST), “National vulnerability database (nvd).” https://nvd.nist.gov/. Accessed: 2024-10-13

    2024

  26. [34]

    What are weak links in the npm supply chain?,

    N. Zahan, T. Zimmermann, P. Godefroid, B. Murphy, C. Mad- dila, and L. Williams, “What are weak links in the npm supply chain?,” inProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, pp. 331–340, 2022

    2022

  27. [35]

    github/advisory-database,

    “github/advisory-database,” Oct. 2024. [Online; accessed 3. Oct. 2024]

    2024

  28. [36]

    Snyk vulnerability database

    Snyk, “Snyk vulnerability database.” https://snyk.io/vuln. Ac- cessed: 2024-10-13

    2024

  29. [37]

    Libraries.io - discover open source libraries

    Libraries.io, “Libraries.io - discover open source libraries.” https://libraries.io/. Accessed: 2024-10-13

    2024

  30. [38]

    Build software better, together

    Github.com, “Build software better, together.” https://github.com/. Accessed: 2024-10-13

    2024

  31. [39]

    Open Source Vulnerability format - Open Source Vulnerability schema,

    “Open Source Vulnerability format - Open Source Vulnerability schema,” Oct. 2024. [Online; accessed 3. Oct. 2024]

    2024

  32. [40]

    On measuring vulner- able javascript functions in the wild,

    M. Kluban, M. Mannan, and A. Youssef, “On measuring vulner- able javascript functions in the wild,” inProceedings of the 2022 ACM on Asia conference on computer and communications security, pp. 917–930, 2022

    2022

  33. [41]

    To de- tect and mitigate the risk in continuous integration and continues deployments (ci/cd) pipelines in supply chain using snyk tool,

    D. Sushma, M. Nalini, R. A. Kumar, and M. Nidugala, “To de- tect and mitigate the risk in continuous integration and continues deployments (ci/cd) pipelines in supply chain using snyk tool,” in2023 7th International Conference on Computation System and Information Technology f...

    2023

  34. [42]

    Why johnny can’t use secure docker images: Investigating the usability challenges in using docker image vulnerability scanners through heuristic evalua- tion,

    T. Kim, S. Park, and H. Kim, “Why johnny can’t use secure docker images: Investigating the usability challenges in using docker image vulnerability scanners through heuristic evalua- tion,” inProceedings of the 26th International Symposium on Research in Attacks, Intrusions an...

    2023

  35. [43]

    Can large language models find and fix vulnerable software?,

    D. Noever, “Can large language models find and fix vulnerable software?,”arXiv preprint arXiv:2308.10345, 2023

    2023 arXiv

  36. [44]

    Wayback machine,

    Internet Archive, “Wayback machine,” 2024. Accessed: 2024- 10-14

    2024

  37. [45]

    Log4shell: The vulnerability explained,

    IBM, “Log4shell: The vulnerability explained,” 2024. Accessed: 2024-10-14

    2024

  38. [46]

    US govt offers $10 mil- lion bounty for info on Clop ransomware

    Lawrence Abrams, “US govt offers $10 mil- lion bounty for info on Clop ransomware.” https://www.bleepingcomputer.com/news/security/us-govt- offers-10-million-bounty-for-info-on-clop-ransomware/, Accessed: 06-30-2023

    2023

  39. [47]

    Active exploitation of the MOVEit Transfer vulnerability by Clop ransomware group

    Cisco Talos, “Active exploitation of the MOVEit Transfer vulnerability by Clop ransomware group.” https://blog.talosintelligence.com/active-exploitation-of-moveit/, Accessed: 06-30-2023

    2023

  40. [48]

    The SolarWinds Cyber-Attack: What You Need to Know

    Center of Internet Security, “The SolarWinds Cyber-Attack: What You Need to Know.” https://www.cisecurity.org/solarwinds, Accessed: 06-30-2023

    2023

  41. [49]

    Go modules reference

    G. Team, “Go modules reference.” https://go.dev/ref/mod, 2023. Online; Accessed: 2024-10-12

    2023

  42. [50]

    Go proxy

    G. Team, “Go proxy.” https://proxy.golang.org/, 2023. Online; Accessed: 2024-10-12

    2023

  43. [51]

    Using theGO111MODULEeverywhere!

    M. Valais, “Using theGO111MODULEeverywhere!.” https://maelvls.dev/go111module-everywhere/#go111module- with-go-116, 2021. Online; Accessed: 2024-10-12

    2021

  44. [52]

    I know what you imported last summer: A study of security threats in thepython ecosystem,

    A. Bagmar, J. Wedgwood, D. Levin, and J. Purtilo, “I know what you imported last summer: A study of security threats in thepython ecosystem,” 2021

    2021

  45. [53]

    An empirical study of malicious code in pypi ecosystem,

    W. Guo, Z. Xu, C. Liu, C. Huang, Y . Fang, and Y . Liu, “An empirical study of malicious code in pypi ecosystem,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 166–177, 2023

    2023

  46. [54]

    Backstabber’s knife collection: A review of open source software supply chain attacks,

    M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” inDetection of Intrusions and Malware, and Vulnera- bility Assessment: 17th International Conference, DIMVA 2020, Lisbon, Portugal, June 24–26, ...

    2020

  47. [55]

    Dependency confusion: How i hacked into apple, microsoft and dozens of other companies

    A. Birsan, “Dependency confusion: How i hacked into apple, microsoft and dozens of other companies.” https://medium.com/ @alex.birsan/dependency-confusion-4a5d60fec610, 2021. Ac- cessed: 2025-05-15

    2021

  48. [56]

    npm dependency confusion attack targeting gxm refer- ence

    Snyk, “npm dependency confusion attack targeting gxm refer- ence.” https://snyk.io/blog/npm-dependency-confusion-attack- gxm-reference/, 2022. Accessed: 2025-05-15

    2022

  49. [57]

    SNYK-JS-IBMPTCGREETME-8518693: Malicious Package in @ibm-ptc/greet-me

    Snyk, “SNYK-JS-IBMPTCGREETME-8518693: Malicious Package in @ibm-ptc/greet-me.” https://security.snyk.io/vuln/ SNYK-JS-IBMPTCGREETME-8518693, 2024. Accessed: 2025-05-25

    2024

  50. [58]

    SNYK-JS-SWIGGYPRIV ATEANALYTICS- 8553970: Malicious Package in @swiggy- private/analytics

    Snyk, “SNYK-JS-SWIGGYPRIV ATEANALYTICS- 8553970: Malicious Package in @swiggy- private/analytics.” https://security.snyk.io/vuln/SNYK-JS- SWIGGYPRIV ATEANALYTICS-8553970, 2024. Accessed: 2025-05-25

    2024

  51. [59]

    SNYK-JS-POSTINSTALLDUMMY-2847431: Mali- cious Package in postinstall-dummy

    Snyk, “SNYK-JS-POSTINSTALLDUMMY-2847431: Mali- cious Package in postinstall-dummy.” https://security.snyk.io/ vuln/SNYK-JS-POSTINSTALLDUMMY-2847431, 2022. Accessed: 2025-05-25. 13

    2022

  52. [60]

    SNYK-JS-NODEIPC-2426370: Malicious Package in node-ipc

    Snyk, “SNYK-JS-NODEIPC-2426370: Malicious Package in node-ipc.” https://security.snyk.io/vuln/SNYK-JS-NODEIPC- 2426370, 2022. Accessed: 2025-05-16

    2022

  53. [61]

    The family of safe golang libraries is growing,

    G. B. Hunters, “The family of safe golang libraries is growing,”

  54. [62]

    Introducing npm package provenance,

    B. D. Harrison, Philip, “Introducing npm package provenance,” Apr. 2023. Accessed: 2024-10-14

    2023

  55. [63]

    rc - npm package,

    npm, “rc - npm package,” 2024. Accessed: 2024-10-14

    2024

  56. [64]

    coa - npm package,

    npm, “coa - npm package,” 2024. Accessed: 2024-10-14

    2024

  57. [65]

    ua-parser-js - npm package,

    npm, “ua-parser-js - npm package,” 2024. Accessed: 2024-10- 14

    2024

  58. [66]

    CWE - CWE-79: Improper Neutralization of Input During Web Page Generation (’Cross Site Scripting’),

    “CWE - CWE-79: Improper Neutralization of Input During Web Page Generation (’Cross Site Scripting’),” 2024. Accessed: 2024-10-14

    2024

  59. [67]

    CWE - CWE-22: Improper limitation of a pathname to a restricted directory (’path traversal’),

    “CWE - CWE-22: Improper limitation of a pathname to a restricted directory (’path traversal’),” 2024. Accessed: 2024- 10-14

    2024

  60. [68]

    CWE - CWE-94: Improper control of generation of code (’code injection’),

    “CWE - CWE-94: Improper control of generation of code (’code injection’),” 2024. Accessed: 2024-10-14

    2024

  61. [69]

    CWE - CWE-1321: Improper Handling of Prototype Pollu- tion,

    “CWE - CWE-1321: Improper Handling of Prototype Pollu- tion,” 2024. Accessed: 2024-10-14

    2024

  62. [70]

    CWE - CWE-122: Heap-based Buffer Overflow,

    “CWE - CWE-122: Heap-based Buffer Overflow,” 2024. Ac- cessed: 2024-10-14

    2024

  63. [71]

    CWE - CWE-416: Use After Free,

    “CWE - CWE-416: Use After Free,” 2024. Accessed: 2024-10- 14

    2024

  64. [72]

    CWE - CWE-787: Out-of-Bounds Write,

    “CWE - CWE-787: Out-of-Bounds Write,” 2024. Accessed: 2024-10-14

    2024

  65. [73]

    Range operator

    Microsoft, “Range operator.” Microsoft Docs, 2024. Accessed: 2024-10-14

    2024

  66. [74]

    CWE - CWE-362: Concurrent Execution using Shared Re- source with Improper Synchronization (’Race Condition’),

    “CWE - CWE-362: Concurrent Execution using Shared Re- source with Improper Synchronization (’Race Condition’),”

  67. [77]

    Below, we provide the formulas and definitions for each term used in our study to ensure clarity and precision

    Terminology Definitions. Below, we provide the formulas and definitions for each term used in our study to ensure clarity and precision. Vulnerability LifespanThe vulnerability lifespan mea- sures the duration a vulnerability persists in a package before being patched. Since a...

  68. [78]

    These CWEs have either become more prominent or less frequent due to improvements in ecosystem security practices

    Rise and Fall of Top CWEs Figure 9 illustrates different ecosystem’s top five most reported CWEs over time. These CWEs have either become more prominent or less frequent due to improvements in ecosystem security practices. 20182019202020212022202320242025 0 1000 2000 3000 4000...

    2000

  69. [79]

    Discouraged and Prohibited CWEs Table 4 includes the CWEs that are marked as discouraged or prohibited to use by MITRE

  70. [80]

    14 TABLE 4

    Common and Ecosystem-Specific CWEs Table 5 includes examples for common and ecosystem-specific CWEs. 14 TABLE 4. DISCOURAGED ANDPROHIBITEDCOMMONWEAKNESSENUMERATION(CWE)ANDTHEIRDESCRIPTION CWE ID Description CWE ID Description CWE-19 Data Processing Errors CWE-200 Exposure of S...

  71. [2023]

    Accessed: 2024-10-14

    2024

  72. [2024]

    Appendix

    Accessed: 2024-10-14. Appendix

    2024

Pith tools

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