CHRONO - RESOLUTION: A Dependency Resolution
Dataset at Release Points for npm, PyPI, and crates.io Packages Imranur Rahman, Jill Marley, Ranindya Paramitha, Laurie Williams
arXiv:2607.15315v1 [cs.SE] 15 Jul 2026
North Carolina State University Raleigh, NC, USA {irahman3, jahmad5, rparami, lawilli3}@ncsu.edu Abstract—Dependency resolution at a specified point in time in the past can provide insight into software evolution in software ecosystems and facilitate the design of dynamic metrics (e.g., dependency freshness, dependency update rhythm). However, dependency resolution at specified points in time is not possible in major software ecosystems due to a lack of support from package management tools. The goal of this paper is to aid practitioners and researchers in analyzing the state of the ecosystem dependency graph at release points using an enriched dataset with dependency resolution at release points for npm, PyPI, and crates.io packages. In this paper, we present a methodology to construct dependency resolution at release points of packages in software ecosystems, which we enrich with vulnerability data from OSV. We apply our methodology to construct CHRONO RESOLUTION , a dataset of dependency resolution at release points for npm, PyPI, and crates.io packages, and release it for future research. Index Terms—Software evolution, software ecosystem, version constraint, dependency resolution, mining software repositories, software supply chain security, empirical software engineering
I. I NTRODUCTION Reusing software as dependencies improves developers’ productivity [6]. To facilitate software reuse, package registries, e.g., npm for JavaScript, PyPI for Python, and crates.io for Rust, store, manage, and distribute software packages and their dependencies. However, the proliferation of packages in software registries makes software supply chain attacks via vulnerable dependencies an increasingly attractive attack vector [28]. For example, npm had 1M packages in 2019 and now has 3.67M packages as of 2025 [2]. To better understand <package, dependency> relationships and defend against software supply chain attacks through vulnerable dependencies, several researchers analyzed package version release information, <package, dependency> relationships, and proposed metrics to measure package characteristics [17], [24], [9], [25]. For example, Rahman et al. [25] designed two metrics, Mean-Time-To-Updatedep (MTTUdep ), and Mean-Time-To-Remediatedep (MTTRdep ), to measure how quickly development teams update their vulnerable dependencies. However, several of such metrics are dynamic, e.g., Common Vulnerabilities and Exposures (CVEs), dependency freshness, MTTUdep , and MTTRdep . In addition, packages use dependency version constraints to specify which versions of dependencies they depend on. For example, a package can
specify >=1.0.0 or ==1.0.0 as a version constraint for a dependency. As a result, the version of the dependency that ends up installed in the end applications may change with different upstream releases. To analyze the state of the package at release points, we need to resolve the dependency graph at some point in the past. Release points are either the major, minor, or patch releases made by a package. Such dependency resolution at release points is non-trivial since we need to reconstruct the state of ecosystems (e.g., npm, PyPI, and crates.io) at those times. npm command-line tool has a time-traveling feature (an undocumented --before argument found by Pinckney et al. [20]) to conduct a dependency resolution at specified points in time. However, the time-traveling feature does not exist for other major ecosystems (e.g., PyPI or crates.io). Research with dynamic metrics or involving longitudinal analysis would benefit from a dataset of dependency resolution at specified points in time for software ecosystems. The goal of this paper is to aid practitioners and researchers in analyzing the state of the ecosystem dependency graph at release points using an enriched dataset with dependency resolution at release points for npm, PyPI, and crates.io packages. We release the dataset, construction scripts, and usage examples for future research. Our dataset contains 146, 651 npm, 48, 608 PyPI, and 15, 690 crates.io packages with 2, 221, 947 npm, 360, 969 PyPI, and 158, 849 crates.io <package, dependency> relationships and 6, 948 security advisories. Our provided dataset presents static dependency resolution from the past, and our provided methodology would allow future research to conduct dependency resolution at release points of their choice. II. R ELATED W ORK A ND T HE O RIGINALITY O F T HE DATASET A variety of tools and services are available that store package metadata from software registries. Libraries.io [27] hosts a detailed dataset of metadata across multiple package registries. Similar websites are available, e.g., World of Code [18] and ecosyste.ms [3], to gather package metadata, source code, and dependency resolution from software registries. However, no tools or websites exist for dependency resolution at release points in software registries.
TABLE I. Description of the RELATIONS table columns of CHRONO - RESOLUTION and how it was built. Column name Type Description Initiated with data collection from npm, PyPI, and crates.io (Section III-A1, row filtering in Section III-A2) ecosystem String The name of the ecosystem registry. package String The name of the package in the ecosystem. package version SemVer The version of the package in the ecosystem. dependency String The dependency of the package. String The version constraint set by the developers for the ‘dependency.’ dependency constraint constraint type String The type of the version constraint ‘dependency constraint’ according to Rahman et al. [22]. Added after dependency resolution at release points (Section III-A3) dependency version SemVer The resolved dependency version with the ‘dependency constraint’ at the beginning of ‘Interval start.’ dependency highest version SemVer The highest available version of the dependency at the beginning of column ‘Interval start.’ Timestamp The start time of the interval for this <package, dependency> relationship. Interval start Interval end Timestamp The end time of the interval for this <package, dependency> relationship. Added in the data processing step, for remediated using vulnerability data (Table III) (Section III-C2) updated Boolean If the ‘dependency version’ matches with ‘dependency highest version’ or not. remediated Boolean If ‘dependency version’ falls inside any CVE vulnerability ranges.
Dependency Version Constraints Released Versions
FINAL DATASET
Package Inclusion Criteria
Dependency Resolution At Release Points
Relations Table
vulnerability remediation information
Security Advisories Vulnerability Data Collection and Filtering
OSV-extended Table
F IG . 1. CHRONO - RESOLUTION construction workflow. Research has shown the importance of dependency resolution at specific points in time for software registries [15], [20], [12]. Jaime et al. [15] presented GOBLIN to “rewind” the dependency graph at some point in time to facilitate research on dynamic metrics (e.g., freshness [9], rhythm [14]). However, their dataset contains only Maven Central packages and is not suitable for cross-ecosystem analysis. Other research used the time-traveling feature of npm (with the --before argument) to conduct a large-scale analysis [20] and a simulation study [12]. However, no research or dataset is available for dependency resolution at release points for other major software ecosystems (e.g., the oldest ecosystem PyPI or one of the newest ecosystems crates.io are often ignored). We performed two studies using the dataset presented in this paper. For the first study, we designed two dependency update metrics, Mean-Time-To-Updatedep (MTTUdep ) and MeanTime-To-Remediatedep (MTTRdep ), to measure the responsiveness of development teams in keeping their dependencies up to date and mitigated [25]. Our designed metrics rely on dependency resolution data at release points to handle floating version constraints correctly (e.g., automatically incorporating upstream releases) in our measurement. The state of dependency graphs at release points of packages, e.g., which dependency version would have been installed using floating, is a requirement of our designed metrics. We then continue to our second study, in which we performed survival analysis to analyze the historical data split into time intervals to understand the impact of dependency version constraints (e.g., pinning and floating) on time to become outdated and
time to become vulnerable dependencies [22]. What is new in this release. The internal snapshots used in [25], [22] were not publicly released and covered a narrower package set collected earlier. This paper provides the first complete, publicly available description and release of the dataset: it extends coverage to all three ecosystems, adds the fix available annotation for unfixed vulnerabilities, provides both raw and filtered variants, and releases the full data collection and transformation pipeline for reproducibility. Researchers wishing to replicate or extend prior studies [25], [22] should use the CHRONO - RESOLUTION release. III. DATASET C ONSTRUCTION M ETHODOLOGY In this section, we present our methodology for constructing the dataset of dependency resolution at release points. We illustrate the high-level workflow for the dataset construction process in Figure 1. Our dataset contains two tables: (1) RELATIONS, which contains the packages in the three ecosystems and their <package, dependency> relationships at release points, and (2) OSV- EXTENDED, which contains vulnerabilities gathered from OSV website [4] in the three ecosystems. We then used the vulnerability data from OSVEXTENDED to add the remediated column in RELATIONS . A. R ELATIONS: Packages and Dependencies at Release Points In this section, we discuss how we constructed the RELA TIONS table. The columns (and the step in which they are added) are shown in Table I. 1) Package Metadata Collection: We collected npm, PyPI, and crates.io package metadata (version release information and <package, dependency> relationships with version constraints for each version) on August 20, 2024. Our required metadata are present in package.json file for npm, setup.py or pyproject.toml for PyPI, and Cargo.toml for crates.io packages. The JSON formatted package metadata are available at https://registry.npmjs.org/ <package-name>, https://pypi.org/pypi/<packagename>/json, and https://crates.io/api/v1/crates/<crate-name>. We selected these three ecosystems for their diversity: npm is the largest (with 3.67 million packages compared to Maven’s 715k), PyPI is the oldest (introduced in 2003, whereas Maven Central came in 2005), and Cargo is the newest among the
TABLE II. An example of our dataset: hexo package with one of its dependency moment collected from Rahman et al. [22]. row
package
122 123 124 125 126 ...
... hexo hexo hexo hexo hexo ...
package version ... 3.1.1 3.1.1 3.1.1 3.1.1 3.2.0 ...
dependency ... moment moment moment moment moment ...
dependency constraint ... ∼ 2.10.3 ∼ 2.10.3 ∼ 2.10.3 ∼ 2.10.3 ∼ 2.11.2 ...
constraint type ... floating-patch floating-patch floating-patch floating-patch floating-patch ...
dependency version ... 2.10.6 2.10.6 2.10.6 2.10.6 2.11.2 ...
major software ecosystems. We used deps.dev [2] to collect the data for this phase, as also used in similar prior studies to collect package metadata in software ecosystems [13], [7]. At the end of this phase, we have 2, 603, 314 npm, 274, 720 PyPI, and 122, 069 crates.io packages. To validate data quality, the first author manually inspected a sample of 50 packages per ecosystem, comparing reported versions and <package, dependency> relationships field-by-field against the live registry APIs and found 100% match. 2) Applying Package Inclusion Criteria: Before applying the inclusion criteria, we have 2, 603, 314 npm, 274, 720 PyPI, and 122, 069 crates.io packages. Our package inclusion criteria are: (i) The package must be at least two years old, operationalized by checking the time difference between the first and latest available version release of the package. (ii) The package must have at least one version release in the last two years. (iii) The package must have at least one dependency. Our selection criteria are based on the work of Miller et al. [19], who defined abandoned packages as those with two years of regular maintenance followed by two years of inactivity; we use this definition to exclude abandoned packages. Additionally, the criterion of “two years” is commonly used to determine whether a package is still actively maintained or not [16], [25]. After applying our inclusion criteria, our resulting dataset contains 163, 207 (146, 651 npm, 48, 608 PyPI, and 15, 690 crates.io) packages. The filtering removed 2, 456, 663 npm (≈94%), 226, 112 PyPI (≈82%), and 106, 379 crates.io (≈87%) packages. We provide both the raw (unfiltered) and filtered versions of the dataset in the Zenodo repository [23], so that researchers with different inclusion criteria can work from the complete collection. Packages excluded by the two-year age cutoff are of interest to researchers studying newer or feature-complete packages [8]. 3) Dependency Resolution At Release Points: After collecting the data and applying the inclusion criteria, we divide each <package, dependency> relationship into multiple time intervals, based on release points. Release points refer to the points in time when a major, minor, or patch release was made by the package or the dependency. Time intervals refer to the time between two release points for a <package, dependency>. According to our definition of time intervals, no new versions of either the package or its dependencies are released during each interval. Table II shows an example of time intervals: ‘interval start’ and ‘interval end’. As noted by previous research [20], [21], [12], npm offers a “time-travel” feature (the --before argument), which allows resolving dependencies at specified points in time. However,
dependency highest version ... 2.10.6 2.11.0 2.11.1 2.11.2 2.11.2 ...
Interval start
Interval end
updated
remediated
... 2015-07-28 2016-01-02 2016-01-09 2016-02-03 2016-02-28 ...
... 2016-01-02 2016-01-09 2016-02-03 2016-02-28 2016-03-07 ...
... true false false false true ...
... true true true false true ...
PyPI and crates.io do not provide this feature. Thus, we contacted the Google deps.dev team, who provided us with the dependency resolution at release times for the packages in our dataset (snapshot date: August 20, 2024). Note that the dataset cannot be rebuilt via public deps.dev API, and it will require special access from Google. To verify deps.dev’s resolution validity, the first author manually performed dependency resolution for the same 50 packages per ecosystem and found that deps.dev matched exactly (see Section VI for caveats on PyPI pre-2020 data). We exclude SemVer pre-release and build-metadata qualifiers from our dependency resolution, as package managers ignore them unless explicitly pinned. B. OSV- EXTENDED: Vulnerability Data We gathered security advisories (CVE data) from the Google Open Source Vulnerabilities (OSV) database, available at osv.dev [4], for npm, PyPI, and crates.io packages on September 12, 2024 (OSV data cutoff). We selected OSV because it aggregates data from various vulnerability feeds [11], such as GitHub Security Advisories [1], PyPA, and GoVulDB, across multiple ecosystems, and presents the data in a standardized OSV format. After collecting all security advisories for the relevant ecosystems, we filtered out advisories for which the affected package is not in our dataset. Unlike prior work, we retain advisories for which no fixed version was available at the time of data collection and annotate them with a Boolean fix available column (Table III). Retaining unfixed vulnerabilities allows security researchers to study long-lived and unpatched vulnerabilities; the fix available flag enables downstream analyses to distinguish fixable from unfixable exposures. The resulting dataset after filtering for relevance to our package set consisted of 2, 192 npm, 3, 767 PyPI, and 989 crates.io vulnerabilities with a fixed version, plus additional advisories without a known fix annotated as fix available = false. Next, we converted the data to an SQL table with vul id (advisory identifier), ecosystem, package (vulnerable package name), vul introduced (version where the vulnerability was introduced), vul fixed (fixed version, or NULL if no fix exists), and fix available (Boolean), as shown in Table III. If a vulnerability contained multiple vulnerable version ranges, we separated it into multiple SQL rows, each corresponding to one SemVer vulnerable version range, to facilitate analysis. Since vulnerability data is often inconsistent [10], we postprocessed versions to ensure SemVer [5] compliance (major.minor.patch): implied components were filled in (e.g., 0 → 0. 0. 0), and rows with non-conforming versions (e.g., extra components, non-numeric identifiers) were removed.
TABLE III. Description of the OSV- EXTENDED table columns of CHRONO - RESOLUTION. Column name vul id ecosystem package vul introduced vul fixed fix available
Type String String String SemVer SemVer (nullable) Boolean
Description The unique identifier for the CVE. The ecosystem of the affected package for the CVE. The name of the vulnerable package for the ecosystem for the CVE. Version of the ‘package name’ where the vulnerability was introduced. Fixed version of the ‘package name’ for the CVE; NULL if no fix was available at data collection. Whether a fixed version existed at the OSV data collection date (September 12, 2024).
TABLE IV. Statistics of CHRONO - RESOLUTION. Ecosystem
Number of unique packages
Number of <package dependency> relationships
crates.io npm PyPI
15, 690 146, 651 48, 608
8, 070, 357 245, 307, 373 20, 859, 740
Number of unique <package dependency> relationships 158, 849 2, 221, 947 360, 969
C. Final Dataset Processing 1) Data Cleaning: Deps.dev resolves the full dependency tree, creating duplicates. We keep only direct dependencies to eliminate duplicates; the full transitive graph can be reconstructed by iteratively self-joining RELATIONS on overlapping intervals. A reference reconstruction script is provided in the replication package. Then, we used the semver [26] extension, an implementation of SemVer, to convert the data types of our tables that contain versions of packages or dependencies, removing any rows where the version could not be converted. For example, semver extension can handle 31bit integer for each of the major, minor, or patch values. Some packages’ version (e.g., 1. 0. 20230603010803) resulted in errors (e.g., bad SemVer value) because of overflowing the patch with 20230603010803. 2) Data Processing: We next populated the Boolean columns ‘updated’ and ‘remediated’ in Table II to indicate whether the package uses an outdated or vulnerable dependency. A resolved dependency version was marked as outdated (updated = false) if it is not the highest SemVer version of the dependency available at the start of the interval. Similarly, a resolved dependency version was marked as vulnerable (remediated = false) if it falls within the range of vulnerable versions for a given vulnerability (Table III) and a fixed version was available at the start of the interval (fix available = true in Table III). If a package used a vulnerable dependency version at a time interval but no fixed version had been released at that time, we consider that the package is not at fault and mark the row as remediated = true. Researchers studying long-lived unpatched exposures can identify relevant rows by joining RELATIONS with OSV- EXTENDED on fix available = false. IV. A PPLICABILITY Researchers studying evolution of ecosystems through dependencies and analyzing dynamic metrics (e.g., dependency freshness, update rhythm, Mean-Time-To-Updatedep , MeanTime-To-Remediatedep ) can use our dataset. However, our dataset is unsuitable for research on new, abandoned, taken-
down, short-lived, or typosquatted packages since our dataset represents older, active packages with at least one dependency. Final Dataset: Our final dataset, CHRONO - RESOLUTION, contains two schemas and data dump of RELATIONS (Table I) and OSV- EXTENDED (Table III). The statistics of CHRONO RESOLUTION are presented in Table IV. We share the schema, data dump (filtered and raw), all data collection and transformation scripts, and example SQL queries in a Zenodo repository [23]. The replication package documents the exact API endpoints, query structures, and snapshot dates used for deps.dev and OSV, and includes instructions for re-running or adapting the pipeline as external APIs evolve. V. F UTURE R ESEARCH I DEAS The research directions below require release-point dependency resolution specifically—not just ecosystem-level metadata—which is the unique feature of CHRONO - RESOLUTION. Ecosystem evolution. Longitudinal analysis of how the active dependency graph changes version by version—tracking which packages entered or left common use over time—requires release-point resolution that static snapshots cannot provide. Software measurement. Clustering packages by dependency graph structure and tracking developers’ centrality trends across ecosystems over time would give researchers a better understanding of the project and the developers’ centrality trends across ecosystems. Version constraint and dependency update. How the failure of certain projects (e.g., a log4j-style event) cascades through the ecosystem, whether projects systematically avoid major updates, and what version constraints projects prefer for specific dependencies are three potential research questions for future researchers. Vulnerability. The proportion of vulnerabilities present in the dependency network at a specified time, risk of n-day exposure, and study of long-lived unpatched vulnerabilities using the fix available = false rows in OSV- EXTENDED are three potential research directions. VI. T HREATS TO VALIDITY AND L IMITATIONS Construct Validity: Retroactive SemVer Resolution for PyPI. Deps.dev applies a modern, backtracking SemVer resolver retroactively; for PyPI packages released before pip 20.3 (November 2020), resolved versions represent what the modern resolver would have installed, which may differ from what developers actually experienced. So we recommend limiting PyPI analyses to post-2020 data or interpreting earlier
data only as reconstructions. Future work may quantify this discrepancy using period-accurate pip binaries. Construct Validity: Validation Sample Size. Our manual validation covered 50 packages per ecosystem via field-by-field API comparisons, not end-to-end reproduction with historical package manager binaries. Our validation is a smoke test of the pipeline and dependency resolution rather than statistical evidence of the correctness across all 163k packages. Future efforts should expand to a statistically defensible sample and reproduce resolutions using containerized, period-accurate package manager versions. In addition, our validation used live registry API and modern resolver behavior from deps.dev, so it cannot detect retroactive resolution errors. A stratified sampling based validation with period-accurate tooling (e.g., npm --before and use of historical pip binaries) is a promising direction for future work. Package Inclusion. The two-year age cutoff [19] may exclude younger or feature-complete packages [8]. This threshold is a design choice and can be overridden via our released pipeline. Vulnerability Data Coverage. OSV data was collected on September 12, 2024; later disclosures are not reflected. OSV aggregates multiple feeds [11], but vulnerabilities absent from those feeds do not appear in our dataset. ACKNOWLEDGMENT This work was supported and funded by the National Science Foundation Grant No. 2207008 and Google. Any opinions expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation or Google. R EFERENCES [1] GitHub Advisory Database. https://github.com/advisories. Last accessed: July-2026. [2] Open Source Insights: Understand your dependencies. https://deps.dev/. Last accessed: July-2026. [3] Open source intelligence for your project. https://ecosyste.ms/. Last accessed: July-2026. [4] OSV.dev : A distributed vulnerability database for open source. https: //osv.dev. Last accessed: July-2026. [5] Semantic Versioning 2.0. https://semver.org/. Last accessed: July-2026. [6] A BDALKAREEM , R., N OURRY, O., W EHAIBI , S., M UJAHID , S., AND S HIHAB , E. Why do developers use trivial packages? an empirical case study on npm. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (New York, NY, USA, Aug. 2017), ESEC/FSE 2017, Association for Computing Machinery, pp. 385–395. [7] A KHOUNDALI , J., N OURI , S. R., R IETVELD , K., AND G ADYATSKAYA , O. MoreFixes: A Large-Scale Dataset of CVE Fix Commits Mined through Enhanced Repository Discovery. In Proceedings of the 20th International Conference on Predictive Models and Data Analytics in Software Engineering (New York, NY, USA, July 2024), PROMISE 2024, Association for Computing Machinery, pp. 42–51. [8] C OELHO , J., AND VALENTE , M. T. Why modern open source projects fail. In Proceedings of the 2017 11th Joint meeting on foundations of software engineering (2017), pp. 186–196. [9] C OX , J., B OUWERS , E., VAN E EKELEN , M., AND V ISSER , J. Measuring Dependency Freshness in Software Systems. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (May 2015), vol. 2, pp. 109–118. ISSN: 1558-1225. [10] C ROFT, R., BABAR , M. A., AND K HOLOOSI , M. M. Data quality for software vulnerability datasets. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) (2023), pp. 121–133. [11] G OOGLE. OSV: Current data sources. https://google.github.io/osv.dev /data/#current-data-sources. Last accessed: July-2026.
[12] H E , H., VASILESCU , B., AND K ÄSTNER , C. Pinning Is Futile: You Need More Than Local Dependency Versioning to Defend against Supply Chain Attacks. In Proceedings of the ACM on Software Engineering, Volume 2, Number FSE, Article FSE013 (July 2025) (Feb. 2025). arXiv:2502.06662 [cs]. [13] H U , J., Z HANG , L., L IU , C., YANG , S., H UANG , S., AND L IU , Y. Empirical Analysis of Vulnerabilities Life Cycle in Golang Ecosystem. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (New York, NY, USA, Apr. 2024), ICSE ’24, Association for Computing Machinery, pp. 1–13. [14] JAIME , D., E L H ADDAD , J., AND P OIZAT, P. A Preliminary Study of Rhythm and Speed in the Maven Ecosystem. In 21st BelgiumNetherlands Software Evolution Workshop (Mons, Belgium, Sept. 2022). [15] JAIME , D., H ADDAD , J. E., AND P OIZAT, P. Goblin: A Framework for Enriching and Querying the Maven Central Dependency Graph. In Proceedings of the 21st International Conference on Mining Software Repositories (New York, NY, USA, July 2024), MSR ’24, Association for Computing Machinery, pp. 37–41. [16] L I , K., C HEN , S., FAN , L., F ENG , R., L IU , H., L IU , C., L IU , Y., AND C HEN , Y. Comparison and Evaluation on Static Application Security Testing (SAST) Tools for Java. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (New York, NY, USA, Nov. 2023), ESEC/FSE 2023, Association for Computing Machinery, pp. 921–933. [17] L IU , C., C HEN , S., FAN , L., C HEN , B., L IU , Y., AND P ENG , X. Demystifying the Vulnerability Propagation and Its Evolution via Dependency Trees in the NPM Ecosystem. In Proceedings of the 44th International Conference on Software Engineering (May 2022), pp. 672– 684. arXiv:2201.03981 [cs]. [18] M A , Y., D EY, T., B OGART, C., A MREEN , S., VALIEV, M., T UTKO , A., K ENNARD , D., Z ARETZKI , R., AND M OCKUS , A. World of code: Enabling a research workflow for mining and analyzing the universe of open source vcs data. Empirical Software Engineering 26, 2 (2021), 1–42. [19] M ILLER , C., JAHANSHAHI , M., M OCKUS , A., VASILESCU , B., AND K ASTNER , C. Understanding the Response to Open-Source Dependency Abandonment in the npm Ecosystem. In International Conference on Software Engineering (2025). [20] P INCKNEY, D., C ASSANO , F., G UHA , A., AND B ELL , J. A Large Scale Analysis of Semantic Versioning in NPM. In Proceedings of the 20th International Conference on Mining Software Repositories (2023). [21] P INCKNEY, D., C ASSANO , F., G UHA , A., AND B ELL , J. npm-follower: A Complete Dataset Tracking the NPM Ecosystem. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (San Francisco CA USA, Nov. 2023), ACM, pp. 2132–2136. [22] R AHMAN , I., M ARLEY, J., E NCK , W., AND W ILLIAMS , L. Which is better for reducing outdated and vulnerable dependencies: Pinning or floating? In 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE) (2025), pp. 2795–2807. [23] R AHMAN , I., M ARLEY, J., PARAMITHA , R., AND W ILLIAMS , L. CHRONO-RESOLUTION: A dependency resolution dataset at release points for npm, pypi, and crates.io packages. https://doi.org/10.5281/zenodo.17576373. [24] R AHMAN , I., PARAMITHA , R., P LATE , H., W ERMKE , D., AND W ILLIAMS , L. What’s in a package? getting visibility into dependencies using security-sensitive api calls, 2025. [25] R AHMAN , I., PARAMITHA , R., Z AHAN , N., E NCK , W., AND W ILLIAMS , L. How quickly do development teams update their vulnerable dependencies?, 2026. [26] THEORY. A postgres data type for the semantic version format with support for btree and hash indexing. https://pgxn.org/dist/semver/. Last accessed: July-2026. [27] T IDELIFT, I. Libraries.io – The Open Source Discovery Service. https: //libraries.io/. Last accessed: July-2026. [28] W ILLIAMS , L., B ENEDETTI , G., H AMER , S., PARAMITHA , R., R AH MAN , I., TAMANNA , M., T YSTAHL , G., Z AHAN , N., M ORRISON , P., ACAR , Y., C UKIER , M., K ÄSTNER , C., K APRAVELOS , A., W ERMKE , D., AND E NCK , W. Research directions in software supply chain security. ACM Trans. Softw. Eng. Methodol. 34, 5 (May 2025).