Pith. sign in

REVIEW 4 major objections 5 minor 57 references

Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?

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

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

Pith's one-line read This paper claims that floating version constraints make dependencies less likely to become outdated than pinning, and that floating-minor constraints are the least likely to yield vulnerable dependencies across npm, PyPI, and Cargo.

desk verdict Useful data and a serious empirical effort, but two headline claims don't survive close reading: the floating-major outdatedness result is close to definitional, and the floating-minor vulnerability claim is likely an ecosystem-confound artifact. read the letter →

arxiv 2510.08609 v3 pith:5EMVQTMK submitted 2025-10-07 cs.SE cs.CRcs.LGcs.PL

Imranur Rahman , Jill Marley , William Enck , Laurie Williams This is my paper · ORCID
classification cs.SEcs.CRcs.LGcs.PL
keywords dependencyversionconstraintspinningvsfloatingoutdateddependenciesvulnerablesurvivalanalysisnpmPyPICargo
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 aims to settle the pin-versus-float trade-off with evidence rather than intuition. It follows millions of dependency intervals in three large package ecosystems, labels each interval as outdated or vulnerable, and uses time-to-event modeling to compare how quickly dependencies under each version-constraint category fall behind or become affected by a fixable security advisory. Its central result is that pinning exact versions is the worst choice for freshness — floating-major has a hazard ratio of 0.01 relative to pinning for becoming outdated — and floating-minor is 43% less likely than pinning to become vulnerable. The paper also finds that most successful remediations involve relaxing a pinned constraint, and it concludes that any floating constraint paired with regularly updated lockfiles is a better balance than pinning.

What carries the argument

The central mechanism is a time-to-event (survival) model built from interval-coded dependency histories. Each package–dependency relationship is split into intervals whose boundaries are releases of either side; at each interval start, the exact resolved dependency version is computed historically, and the interval is labeled outdated if that version is not the newest available and vulnerable if it falls in a fixable advisory range. A time-varying proportional-hazards model then estimates the hazard ratio of each constraint category relative to pinning. This converts a static choice of constraint string into a quantitative risk profile over time, letting the authors compare the tightest con

What would settle it

Take a random sample of package releases that have an accompanying lockfile recording the exact resolved dependency versions, replay the constraints at those release dates to see whether the recorded resolved version matches the range a historical resolution service would report, then rerun the survival model on the verified intervals. If the hazard-ratio ordering between pinning and floating categories changes materially, the central conclusion is an artifact of resolution error.

Watch

Extended reading notes

Core claim

The paper's core claim is that the version constraint a developer writes is a measurable determinant of how long a dependency stays current and secure. Treating pinning as the baseline, a time-varying proportional-hazards model over dependency intervals in the three ecosystems yields hazard ratios of 0.01 for floating-major and 0.44 for floating-minor for becoming outdated, meaning these constraints are far less likely than pinning to leave a dependency behind. For vulnerability, floating-minor has a hazard ratio of 0.57, while floating-patch, fixed-ranging, and complex expressions have hazard ratios of 1.48, 2.69, and 3.52 — all worse than pinning. The authors therefore establish that 'pinn

Load-bearing premise

The load-bearing premise is that the historical dependency resolution (Section III-B) correctly reconstructs which exact dependency version each package used at each past date; the paper states there is no ground truth for this and manually verified only 20 package versions. If that resolution is wrong for a meaningful share of the 1.5M+ intervals, the outdated and vulnerable labels — and every hazard ratio built on them — are corrupted.

Editorial extensions

If this is right

  • Pinning exact versions is the strongest predictor of becoming outdated; every floating category lowers that hazard, with floating-major cutting it by roughly 99% relative to pinning.
  • Floating-minor is the only constraint category that is both less likely than pinning to be outdated and less likely to be vulnerable, making it the paper's best-supported default for dependencies that follow semantic versioning.
  • Incomplete backporting of security fixes means auto-update is not a guarantee: a floating-minor constraint on a vulnerable major branch stays vulnerable, so the upstream project's patch behavior is part of the risk.
  • The dominant successful remediation pattern is changing the constraint value while keeping the constraint type, and the top constraint-type changes that remediate dependencies all remove pinning.
  • The paper's practical recommendation is to avoid pinning direct dependencies and instead use floating constraints with lockfiles that are updated on a schedule.

Reading between the lines

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

  • A decisive check the paper does not report: repeat the survival analysis on releases that carry lockfiles recording exact resolved versions, so the historical-resolution assumption is verified rather than assumed. If the pinning-versus-floating hazard ordering persists there, the conclusion is robust; if not, it is an artifact.
  • Because the model counts every advisory as equally severe and ignores reachability and exploitability, the vulnerability hazard ratios likely overstate real-world breakage risk. A severity-weighted or reachability-filtered reanalysis could plausibly move floating-patch or fixed-ranging relative to floating-minor.
  • The paper's finding that fixes are rarely backported across major versions implies a concrete tool design: a package manager or advisory feed could warn when a floating-minor constraint sits on a major branch that will never receive the fix. That would preserve auto-update benefits and is directly testable.
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 / 5 minor

Summary. The paper studies dependency version constraint types in the npm, PyPI, and Cargo ecosystems. It constructs time intervals for each <package, dependency> relationship from deps.dev data, labels each interval as "outdated" when the resolved dependency version is not the highest SemVer version available at interval start, and labels it "vulnerable" when the resolved version is in a vulnerable range for which a fixed version exists. It then reports the distribution of constraint types (RQ1), the transition patterns when developers change constraints (RQ2), and Cox time-varying proportional hazards models comparing the hazard of becoming outdated or vulnerable across constraint types relative to pinning (RQ3). The headline findings are that floating-major is the least likely to result in outdated dependencies (hazard ratio 0.01) and floating-minor is the least likely to result in vulnerable dependencies (hazard ratio 0.57), leading the authors to recommend avoiding pinning and using floating constraints with lockfiles.

Significance. If valid, the study would provide large-scale, three-ecosystem evidence on a practical question of dependency management. Strengths include a public Zenodo replication package, the use of deps.dev historical dependency resolution and OSV advisories, and a useful discussion of vulnerability fixes not being backported to all affected major versions. However, the two headline claims are not currently established. The outdatedness result is largely a re-encoding of the paper's own definition, and the vulnerability result is confounded by ecosystem because constraint type and ecosystem are strongly correlated and the model includes no ecosystem covariate or stratification. The underlying dataset is valuable and may support a corrected analysis, but the manuscript in its present form does not support the abstract's causal-sounding conclusions.

major comments (4)
  1. [Section III-B and Table VI] The definition of "outdated" makes the floating-major hazard ratio of 0.01 tautological. Section III-B defines a dependency as outdated when "the resolved dependency version is not the highest SemVer version of the dependency present at the start of the interval." Section II-B defines floating-major as a lower-bounded constraint with no upper bound (e.g., ">=1.0.0"). Therefore deps.dev necessarily resolves floating-major to the highest available version, so floating-major can never be outdated under this definition. The survival model is not measuring an empirical association; it is mechanically encoding the outcome definition. The abstract's claim that "floating-major is the least likely to result in outdated" dependencies is unsupported as an empirical finding. The authors should either redefine the outcome (e.g., staleness relative to the constraint's allowed range), restrict the comp
  2. [Section III-E and Table VI (Vulnerability model)] The vulnerability model includes only version-constraint-type covariates; ecosystem is not included as a covariate, stratum, or clustering variable. This is a serious confound. Table II shows floating-minor is roughly 95% of Cargo tuples, about 67% of npm tuples, and under 0.2% of PyPI tuples, while pinning is roughly 30% of npm and PyPI tuples but about 3% of Cargo tuples. Section III-A additionally reports 5,158 PyPI packages but only 92 Cargo packages with vulnerable dependencies. Consequently, the estimated hazard ratio of 0.57 for floating-minor versus pinning can reflect a between-ecosystem contrast in baseline vulnerability rates rather than a within-ecosystem effect of the constraint type. The paper's own explanation in Section IV-C that the 0.57 HR "could be explained by the disproportionate use of floating-minor" acknowledges the imbalance but does not control for it. The autho
  3. [Section IV-C, Time to Vulnerable] The unqualified statement that "floating-minor is the least likely to result in vulnerable dependencies" is not supported by the model actually fit. The authors removed floating-major, or-expression, not-expression, and at-most from the vulnerability model, citing zero events or quasi-separation. Table III shows that floating-major has zero vulnerability events in the remaining ecosystems, which would make floating-major at least as good as, and likely better than, floating-minor on the observed event counts. The paper may legitimately exclude covariates that prevent model convergence, but then the headline must be qualified to the set of estimable constraint types, or a penalized method (e.g., Firth's correction) should be used to estimate the zero-event categories. As written, the abstract's "least likely" claim contradicts the authors' own exclusion note.
  4. [Section III-B] The paper states that "there is no ground truth for verifying the accuracy of historical dependency resolution by deps.dev" and that the authors manually verified only 20 packages' versions and their dependencies. Every outdated/vulnerable label and every interval construction in the 1.5M-row survival dataset depends on deps.dev's historical resolution, so a 20-package manual check is a thin basis for the analysis. The authors should either provide a more extensive validation sample, quantify the expected impact of resolution errors, or explicitly discuss whether such errors could be differential across constraint types. This is particularly important because the outdatedness outcome is directly defined by what deps.dev resolves as the newest version at each interval start.
minor comments (5)
  1. [Section VIII] The conclusion states that "floating-minor is the most likely to result in vulnerable dependencies," which contradicts the abstract and the Section IV-C key insight that floating-minor is least likely. This appears to be a drafting error, but it is a substantive contradiction that must be fixed.
  2. [Table VI] No confidence intervals are reported for any hazard ratio. Given that the paper makes numerical comparative claims (e.g., HR=0.57 with a 43% reduction), 95% confidence intervals should be reported, especially for floating-minor and the dropped covariates.
  3. [Section IV-C] No proportional-hazards diagnostics (e.g., Schoenfeld residuals) are reported for either Cox model. With time-varying covariates and interval-based data spanning years, the PH assumption should be checked and reported.
  4. [Section III-E] The survival dataset is restricted to the top 1000 packages per ecosystem by SourceRank, while RQ1 and RQ2 use the full filtered corpus. A sentence is needed on how the SourceRank restriction affects the generalizability of RQ3, since Table II and Table III are computed on different populations.
  5. [Table IV] The percentages in the text do not exactly match the counts in Table IV for some transition rows (e.g., 246/71,944 is approximately 0.34%, not 0.37%). Please recheck the percentage computations.

Circularity Check

2 steps flagged · score 6.0 of 10

One headline result (floating-major least likely to be outdated) is a restatement of the paper's own outdatedness definition; the vulnerability finding is not circular but suffers from omitted-ecosystem confounding.

  1. self definitional [Section III-B (Dependency Resolution And Data Preparation) and Section II-B.1.2.3 (Floating-major)]
    "The resolved version of the dependency is considered outdated (‘updated’=false) if the resolved dependency version is not the highest SemVer version of the dependency present at the start of the interval."

    Section II-B.1.2.3 defines floating-major as an at-least constraint with no upper bound (e.g., '>= 1.0.0'), which 'will resolve to any version greater than or equal to 1.0.0.' Under standard resolution this is the highest available SemVer version, so an interval labeled floating-major can never be 'outdated' by the Section III-B label rule. The RQ3 hazard ratio HR=0.01 for floating-major is therefore forced by the definition of the outcome, not discovered from the data.

  2. self definitional [Section IV-C (RQ3: Time to Outdatedness)]
    "Floating-major has the lowest hazard ratio, which is expected since floating-major is the most flexible version constraint type. Packages using floating-major essentially keep the latest available version of that dependency."

    The paper's own explanation is the outdatedness definition in different words: 'keep the latest available version' is exactly the condition under which Section III-B marks a dependency as updated. Thus the abstract's claim that floating-major is least likely to result in outdated dependencies is a restatement of the labeling rule, not an independent empirical finding.

full rationale

The RQ3 outdatedness model and the abstract's 'floating-major is the least likely to result in outdated' claim reduce by construction: outdated is defined as not resolving to the highest available SemVer version (III-B), and floating-major is defined as an unbounded at-least constraint (II-B.1.2.3), so floating-major always resolves to that highest version. The paper even says this is 'expected' (IV-C), and the same definitional mechanism is used to explain floating-minor's over-representation in IV-A. The vulnerability headline (floating-minor HR=0.57) is not circular: nothing in the definitions guarantees floating-minor is least vulnerable, and the paper's backporting analysis shows it can remain vulnerable. The omission of ecosystem covariates in the Cox model is a genuine confounding risk for that claim, but it is a correctness/validity issue, not circularity. The deps.dev ground-truth caveat (manual check of 20 packages) also weakens data validity but is not circular. The self-citation to Rahman et al. [30] is only for interval-splitting methodology and is not load-bearing. Since one of the two headline findings is forced by the paper's own definitions, the circularity score is 6 (partial circularity).

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

The paper introduces no new physical or conceptual entities; its version-constraint taxonomy is a classification scheme. The load-bearing assumptions are data-source reliability (deps.dev, OSV), the outdatedness operationalization, and untested survival-model assumptions.

assumptions (5)
  • domain assumption deps.dev historical dependency resolution correctly reconstructs the dependency version selected at each past interval start.
    Section III-B: the paper states there is no ground truth for deps.dev's time-travel resolution and that only 20 packages were manually verified. All interval labels and survival results depend on this.
  • domain assumption OSV security advisories correctly and completely map vulnerable ranges to fixed versions for npm, PyPI, and Cargo.
    Section III-A2: the analysis relies on OSV data, which the paper acknowledges may miss advisories; unfixed vulnerabilities are excluded by design.
  • ad hoc to paper A dependency is 'outdated' exactly when its resolved version is not the highest SemVer version available at the interval start.
    Section III-B: this operationalization makes floating-major constraints almost definitionally non-outdated and ignores the possibility that developers intentionally stay on an older major branch.
  • domain assumption The time-varying Cox proportional hazards model's assumptions (independent censoring, proportional hazards) hold for the interval data.
    Section III-E: the model is used without reporting proportional-hazards tests or censoring diagnostics.
  • domain assumption Regular-expression classification correctly assigns every dependency constraint to exactly one taxonomy category.
    Section III-C: constraint types are classified with regexes; exotic or malformed constraint syntaxes are assigned to 'unclassified' or may be misbinned.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?." pith.science (2026). https://pith.science/paper/5EMVQTMK

@misc{pith2026251008609,
  author       = {Pith},
  title        = {Pith review of: Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5EMVQTMK}},
  note         = {Machine review of arXiv:2510.08609}
}
read the original abstract

Developers consistently use version constraints to specify acceptable versions of the dependencies for their project. Pinning dependencies can reduce the likelihood of breaking changes, but comes with a cost of manually managing the replacement of outdated and vulnerable dependencies. On the other hand, floating can be used to automatically get bug fixes and security fixes, but comes with the risk of breaking changes. Security practitioners advocate pinning dependencies to prevent against software supply chain attacks, e.g., malicious package updates. However, since pinning is the tightest version constraint, pinning is the most likely to result in outdated dependencies. Nevertheless, how the likelihood of becoming outdated or vulnerable dependencies changes across version constraint types is unknown. The goal of this study is to aid developers in making an informed dependency version constraint choice by empirically evaluating the likelihood of dependencies becoming outdated or vulnerable across version constraint types at scale. In this study, we first identify the trends in dependency version constraint usage and the patterns of version constraint type changes made by developers in the npm, PyPI, and Cargo ecosystems. We then modeled the dependency state transitions using survival analysis and estimated how the likelihood of becoming outdated or vulnerable changes when using pinning as opposed to the rest of the version constraint types. We observe that among outdated and vulnerable dependencies, the most commonly used version constraint type is floating-minor, with pinning being the next most common. We also find that floating-major is the least likely to result in outdated and floating-minor is the least likely to result in vulnerable dependencies.

Figures

Figures reproduced from arXiv: 2510.08609 by the authors.

Figure 1
Figure 1. Taxonomy of version constraint types with examples. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Spectrum of version constraint types. 1.2.2 Floating-minor. If the version constraint of a depen￾dency is specified in such a way that the package gets an automatic update when there is a new minor or patch released by the dependency, we call the constraint floating-minor. For example, postcss specified 5.x.x for meow in Listing 1, and 5.x.x will resolve to [>= 5.0.0, < 6.0.0]. 1.2.3 Floating-major. If the version c… view at source ↗
Figure 3
Figure 3. According to our time intervals model, such transitions [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 3 canonical work pages

  1. [1]

    Dependency Versioning in the Wild,

    J. Dietrich, D. Pearce, J. Stringer, A. Tahir, and K. Blincoe, “Dependency Versioning in the Wild,” in2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), May 2019, pp. 349–359, iSSN: 2574-3864. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/8816809?casa token=KYt KkGU9INEAAAAA:inn0e5XiBymxMDQ-m4nXcdomVIXG...

    arXiv 2019

  2. [2]

    Dependency Smells in JavaScript Projects,

    A. J. Jafari, D. E. Costa, R. Abdalkareem, E. Shihab, and N. Tsantalis, “Dependency Smells in JavaScript Projects,”IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 3790–3807, Oct. 2022. [Online]. Available: https://ieeexplore.ieee.org/document/9519532

    arXiv 2022

  3. [3]

    A formal framework for measuring technical lag in component repositories — and its application to npm,

    A. Zerouali, T. Mens, J. Gonzalez-Barahona, A. Decan, E. Constantinou, and G. Robles, “A formal framework for measuring technical lag in component repositories — and its application to npm,”Journal of Software: Evolution and Process, vol. 31, no. 8, p. e2157, 2019, eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/smr.2157. [Online]. Available: http...

    doi:10.1002/smr.2157 2019

  4. [4]

    When It Breaks, It Breaks: How Ecosystem Developers Reason about the Stability of Dependencies,

    C. Bogart, C. K ¨astner, and J. Herbsleb, “When It Breaks, It Breaks: How Ecosystem Developers Reason about the Stability of Dependencies,” in 2015 30th IEEE/ACM International Conference on Automated Software Engineering Workshop (ASEW), Nov. 2015, pp. 86–89. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/7426643

    arXiv 2015

  5. [5]

    When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems,

    C. Bogart, C. K ¨astner, J. Herbsleb, and F. Thung, “When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems,”ACM Trans. Softw. Eng. Methodol., vol. 30, no. 4, pp. 42:1–42:56, Jul. 2021. [Online]. Available: https://dl.acm.org/doi/10.1145/3447245

    doi:10.1145/3447245 2021

  6. [6]

    Semantic versioning and impact of breaking changes in the Maven repository,

    S. Raemaekers, A. Van Deursen, and J. Visser, “Semantic versioning and impact of breaking changes in the Maven repository,”Journal of Systems and Software, vol. 129, pp. 140–158, Jul. 2017. [Online]. Available: https://linkinghub.elsevier.com/retrieve/pii/S0164121216300243

    2017

  7. [7]

    Semantic Versioning versus Breaking Changes: A Study of the Maven Repository,

    S. Raemaekers, A. van Deursen, and J. Visser, “Semantic Versioning versus Breaking Changes: A Study of the Maven Repository,” in2014 IEEE 14th International Working Conference on Source Code Analysis and Manipulation, Sep. 2014, pp. 215–224. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/6975655

    arXiv 2014

  8. [8]

    SoK: Taxonomy of Attacks on Open-Source Software Supply Chains,

    P. Ladisa, H. Plate, M. Martinez, and O. Barais, “SoK: Taxonomy of Attacks on Open-Source Software Supply Chains,” inIEEE Symposium on Security and Privacy (SP). arXiv, 2023, arXiv:2204.04008 [cs] type: article. [Online]. Available: http://arxiv.org/abs/2204.04008

    arXiv 2023

Show all 57 references
  1. [9]

    OpenSSF Scorecard: On the Path Toward Ecosystem-Wide Automated Security Metrics,

    N. Zahan, P. Kanakiya, B. Hambleton, S. Shohan, and L. Williams, “OpenSSF Scorecard: On the Path Toward Ecosystem-Wide Automated Security Metrics,”IEEE Security & Privacy, vol. 21, no. 6, pp. 76–88, Nov. 2023. [Online]. Available: https://ieeexplore.ieee.org/document/1 0163720/

    2023

  2. [10]

    OSSF Scorecard: Build better security habits, one test at a time,

    “OSSF Scorecard: Build better security habits, one test at a time,” https: //scorecard.dev/, last accessed: 31-May-2025

    2025

  3. [11]

    Pinning Is Futile: You Need More Than Local Dependency Versioning to Defend against Supply Chain Attacks,

    H. He, B. Vasilescu, and C. K ¨astner, “Pinning Is Futile: You Need More Than Local Dependency Versioning to Defend against Supply Chain Attacks,” inProceedings of the ACM on Software Engineering, Volume 2, Number FSE, Article FSE013 (July 2025), Feb. 2025, arXiv:2502.06662 [c...

    2025 arXiv

  4. [12]

    Replication Package,

    “Replication Package,” https://doi.org/10.5281/zenodo.15559007, last accessed: 31-May-2025

    2025 doi

  5. [13]

    What is an Open Source Package,

    Sonarcube, “What is an Open Source Package,” https://www.sonarsou rce.com/learn/open-source-package/#: ∼:text=An%20open%20sourc e%20package%20is,freely%20in%20their%20own%20projects., last accessed: 31-May-2025

    2025

  6. [14]

    Open Source Insights: Understand your dependencies,

    “Open Source Insights: Understand your dependencies,” https://deps.d ev/, last accessed: 31-May-2025

    2025

  7. [15]

    Understanding vulnerabilities in software supply chains,

    Y . Shen, X. Gao, H. Sun, and Y . Guo, “Understanding vulnerabilities in software supply chains,”Empirical Software Engineering, vol. 30, no. 1, p. 20, Nov. 2024. [Online]. Available: https://doi.org/10.1007/s1 0664-024-10581-2

    2024 doi

  8. [16]

    Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystem,

    J. Hu, L. Zhang, C. Liu, S. Yang, S. Huang, and Y . Liu, “Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystem,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY , USA: Association for Computing M...

    2024

  9. [17]

    Detecting and removing bloated dependencies in CommonJS packages,

    Y . Liu, D. Tiwari, C. Bogdan, and B. Baudry, “Detecting and removing bloated dependencies in CommonJS packages,” May 2025, arXiv:2405.17939 [cs]. [Online]. Available: http://arxiv.org/abs/2405.1 7939

    2025 arXiv

  10. [18]

    DepsRAG: Towards Agentic Reasoning and Planning for Software Dependency Management,

    M. Alhanahnah and Y . Boshmaf, “DepsRAG: Towards Agentic Reasoning and Planning for Software Dependency Management,” Oct. 2024, arXiv:2405.20455 [cs]. [Online]. Available: http://arxiv.org/abs/ 2405.20455

    2024 arXiv

  11. [19]

    MoreFixes: A Large-Scale Dataset of CVE Fix Commits Mined through Enhanced Repository Discovery,

    J. Akhoundali, S. R. Nouri, K. Rietveld, and O. Gadyatskaya, “MoreFixes: A Large-Scale Dataset of CVE Fix Commits Mined through Enhanced Repository Discovery,” inProceedings of the 20th International Conference on Predictive Models and Data Analytics in Software Engineering, s...

    2024

  12. [20]

    OSV .dev : A distributed vulnerability database for open source,

    “OSV .dev : A distributed vulnerability database for open source,” https: //osv.dev, last accessed: 31-May-2025

    2025

  13. [21]

    GitHub Advisory Database,

    “GitHub Advisory Database,” https://github.com/advisories, last accessed: 31-May-2025

    2025

  14. [22]

    OSV: Current data sources,

    “OSV: Current data sources,” https://google.github.io/osv.dev/data/#cur rent-data-sources, last accessed: 31-May-2025

    2025

  15. [23]

    Self-Admitted Library Migrations in Java, JavaScript, and Python Packaging Ecosystems: A Comparative Study,

    H. Gu, H. He, and M. Zhou, “Self-Admitted Library Migrations in Java, JavaScript, and Python Packaging Ecosystems: A Comparative Study,” in2023 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), Mar. 2023, pp. 627–638, iSSN: 2640-7574. [On...

    2023

  16. [24]

    Towards Better Dependency Management: A First Look at Dependency Smells in Python Projects,

    Y . Cao, L. Chen, W. Ma, Y . Li, Y . Zhou, and L. Wang, “Towards Better Dependency Management: A First Look at Dependency Smells in Python Projects,”IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 1741–1765, Apr. 2023, conference Name: IEEE Transactions on Softw...

    2023

  17. [25]

    MigrationAdvisor: Recommending Library Migrations from Large-Scale Open-Source Data,

    H. He, Y . Xu, X. Cheng, G. Liang, and M. Zhou, “MigrationAdvisor: Recommending Library Migrations from Large-Scale Open-Source Data,” in2021 IEEE/ACM 43rd International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), May 2021, pp. 9–12, iSSN: 2574-...

    2021

  18. [26]

    Investigating diversity and impact of the popularity metrics for ranking software packages,

    M. Saini, R. Verma, A. Singh, and K. K. Chahal, “Investigating diversity and impact of the popularity metrics for ranking software packages,” Journal of Software: Evolution and Process, vol. 32, no. 9, p. e2265, 2020, eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/smr...

    2020 doi

  19. [27]

    Using the uniqueness of global identifiers to determine the provenance of Python software source code,

    Y . Sun, D. German, and S. Zacchiroli, “Using the uniqueness of global identifiers to determine the provenance of Python software source code,”Empirical Software Engineering, vol. 28, no. 5, pp. 1–35, Sep. 2023, company: Springer Distributor: Springer Institution: Springer Lab...

    2023 doi

  20. [28]

    Understanding the Response to Open-Source Dependency Abandon- ment in the npm Ecosystem,

    C. Miller, M. Jahanshahi, A. Mockus, B. Vasilescu, and C. Kastner, “Understanding the Response to Open-Source Dependency Abandon- ment in the npm Ecosystem,” inInternational Conference on Software Engineering, 2025

    2025

  21. [29]

    Comparison and Evaluation on Static Application Security Testing (SAST) Tools for Java,

    K. Li, S. Chen, L. Fan, R. Feng, H. Liu, C. Liu, Y . Liu, and Y . Chen, “Comparison and Evaluation on Static Application Security Testing (SAST) Tools for Java,” inProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of So...

    2023

  22. [30]

    No Vulnerability Data, No Problem: Towards Predicting Mean Time To Remediate In Open Source Software Dependencies,

    I. Rahman, R. Paramitha, N. Zahan, S. Magill, W. Enck, and L. Williams, “No Vulnerability Data, No Problem: Towards Predicting Mean Time To Remediate In Open Source Software Dependencies,” Mar. 2025, arXiv:2403.17382 [cs]. [Online]. Available: http://arxiv.org/ abs/2403.17382

    2025

  23. [31]

    Why modern open source projects fail,

    J. Coelho and M. T. Valente, “Why modern open source projects fail,” in Proceedings of the 2017 11th Joint meeting on foundations of software engineering, 2017, pp. 186–196

    2017

  24. [32]

    A Large Scale Analysis of Semantic Versioning in NPM,

    D. Pinckney, F. Cassano, A. Guha, and J. Bell, “A Large Scale Analysis of Semantic Versioning in NPM,” inProceedings of the 20th International Conference on Mining Software Repositories, 2023. [Online]. Available: https://www.jonbell.net/preprint/msr23-npm.pdf

    2023

  25. [33]

    Survival analysis for the duration of software projects,

    P. Sentas and L. Angelis, “Survival analysis for the duration of software projects,” in11th IEEE International Software Metrics Symposium (METRICS’05), 2005, pp. 10 pp.–5

    2005

  26. [34]

    Survival analysis on the duration of open source projects,

    I. Samoladas, L. Angelis, and I. Stamelos, “Survival analysis on the duration of open source projects,”Information and Software Technology, vol. 52, no. 9, pp. 902–922, 2010

    2010

  27. [35]

    Application of biostatistics in dental public health,

    D. V . Dawson, D. R. Blanchette, and B. L. Pihlstrom, “Application of biostatistics in dental public health,” inBurt and Eklund’s Dentistry, Dental Practice, and the Community. Elsevier, 2021, pp. 131–153

    2021

  28. [36]

    Statistics review 12: survival analysis,

    V . Bewick, L. Cheek, and J. Ball, “Statistics review 12: survival analysis,”Critical care, vol. 8, pp. 1–6, 2004

    2004

  29. [37]

    Concepts in cancer survival analysis: Research questions, data, and models,

    E. W. Steyerberg and T. A. Gerds, “Concepts in cancer survival analysis: Research questions, data, and models,”Surgical oncology, vol. 19, no. 2, p. 52, 2010

    2010

  30. [38]

    lifelines: survival analysis in python,

    C. Davidson-Pilon, “lifelines: survival analysis in python,”Journal of Open Source Software, vol. 4, no. 40, p. 1317, 2019. [Online]. Available: https://doi.org/10.21105/joss.01317

    2019 doi

  31. [39]

    Time-varying covariates and coefficients in cox regression models,

    Z. Zhang, J. Reinikainen, K. A. Adeleke, M. E. Pieterse, and C. G. Groothuis-Oudshoorn, “Time-varying covariates and coefficients in cox regression models,”Annals of translational medicine, vol. 6, no. 7, p. 121, 2018

    2018

  32. [40]

    Semantic Versioning 2.0,

    “Semantic Versioning 2.0,” https://semver.org/, last accessed: 31-May- 2025

    2025

  33. [41]

    A Large-Scale Empirical Study on Semantic Versioning in Golang Ecosystem,

    W. Li, F. Wu, C. Fu, and F. Zhou, “A Large-Scale Empirical Study on Semantic Versioning in Golang Ecosystem,” in2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), Sep. 2023, pp. 1604–1614, iSSN: 2643-1572. [Online]. Available: https://ieeexplo...

    2023

  34. [42]

    Back to the Past – Analysing Backporting Practices in Package Dependency Networks,

    A. Decan, T. Mens, A. Zerouali, and C. De Roover, “Back to the Past – Analysing Backporting Practices in Package Dependency Networks,”IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 4087–4099, Oct. 2022. [Online]. Available: https: //ieeexplore.ieee.org/documen...

    2022

  35. [43]

    R. W. Nahhas,Introduction to Regression Methods for Public Health Using R. CRC Press, 2024

    2024

  36. [44]

    What Do Package Dependencies Tell Us About Semantic Versioning?

    A. Decan and T. Mens, “What Do Package Dependencies Tell Us About Semantic Versioning?”IEEE Transactions on Software Engineering, vol. 47, no. 6, pp. 1226–1240, Jun. 2021, conference Name: IEEE Transactions on Software Engineering. [Online]. Available: https://ieeexplore.ieee....

    2021

  37. [45]

    Trusting a library: A study of the latency to adopt the latest Maven release,

    R. G. Kula, D. M. German, T. Ishio, and K. Inoue, “Trusting a library: A study of the latency to adopt the latest Maven release,” in2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), Mar. 2015, pp. 520–524, iSSN: 1534-5351. [Onl...

    2015

  38. [46]

    Do developers update their library dependencies?

    R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies?”Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, Feb. 2018. [Online]. Available: https://doi.org/10.1007/s10664-017-9521-5

    2018 doi

  39. [47]

    Measuring Dependency Freshness in Software Systems,

    J. Cox, E. Bouwers, M. van Eekelen, and J. Visser, “Measuring Dependency Freshness in Software Systems,” in2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2, May 2015, pp. 109–118, iSSN: 1558-1225. [Online]. Available: https://ieeexplore.ieee.org...

    2015

  40. [48]

    Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android,

    E. Derr, S. Bugiel, S. Fahl, Y . Acar, and M. Backes, “Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android,” inProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. Dallas Texas USA: ACM, Oct. 2017, pp. 2187–2200....

    2017

  41. [49]

    An Empirical Study of Usages, Updates and Risks of Third- Party Libraries in Java Projects,

    Y . Wang, B. Chen, K. Huang, B. Shi, C. Xu, X. Peng, Y . Wu, and Y . Liu, “An Empirical Study of Usages, Updates and Risks of Third- Party Libraries in Java Projects,” in2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), Sep. 2020, pp. 35–45, iSS...

    2020

  42. [50]

    Characterizing usages, updates and risks of third-party libraries in Java projects,

    K. Huang, B. Chen, C. Xu, Y . Wang, B. Shi, X. Peng, Y . Wu, and Y . Liu, “Characterizing usages, updates and risks of third-party libraries in Java projects,”Empirical Software Engineering, vol. 27, no. 4, p. 90, Apr

  43. [51]

    Vulnerable open source dependencies: counting those that matter,

    I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vulnerable open source dependencies: counting those that matter,” inProceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. Oulu Finland: ACM, Oct. 2018, pp....

    2018

  44. [52]

    Vuln4Real: A Methodology for Counting Actually Vulnerable Dependencies,

    ——, “Vuln4Real: A Methodology for Counting Actually Vulnerable Dependencies,”IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1592–1609, May 2022, conference Name: IEEE Transactions on Software Engineering

    2022

  45. [53]

    A Comprehensive Study on the Impact of Vulnerable Dependencies on Open-Source Software,

    S. H. B. I. Kumar, L. R. Sampaio, A. Martin, A. Brito, and C. Fetzer, “A Comprehensive Study on the Impact of Vulnerable Dependencies on Open-Source Software,” in2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE), Oct. 2024, pp. 96–107, iSSN: 23...

    2024

  46. [54]

    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,” inIEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2023, arXiv:2301.07972 [cs]. [Online]. A...

    2023 arXiv

  47. [55]

    A Closer Look at the Security Risks in the Rust Ecosystem,

    X. Zheng, Z. Wan, Y . Zhang, R. Chang, and D. Lo, “A Closer Look at the Security Risks in the Rust Ecosystem,”ACM Trans. Softw. Eng. Methodol., vol. 33, no. 2, pp. 34:1–34:30, Dec. 2023. [Online]. Available: https://dl.acm.org/doi/10.1145/3624738

    2023 doi

  48. [56]

    Vulnerability Exploitability eXchange (VEX) : Use Cases,

    CISA, “Vulnerability Exploitability eXchange (VEX) : Use Cases,” ht tps://www.cisa.gov/sites/default/files/2023-01/VEX Use Cases Aprill2 022.pdf, last accessed: 31-May-2025

    2023

  49. [2022]

    Available: https://doi.org/10.1007/s10664-022-10131-8

    [Online]. Available: https://doi.org/10.1007/s10664-022-10131-8

    doi

Pith tools

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