arXiv CSopen access

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

Empirical Software Engineering manuscript No. (will be inserted by the editor)

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

arXiv:2609.16605v1 [cs.SE] 15 Sep 2026

Hidetake Tanaka · Rikuto Tsuchida · Kazumasa Shimari · Raula Gaikovina Kula · Kenichi Matsumoto

Received: date / Accepted: date

Abstract Automated dependency updates can rapidly propagate malicious package releases before maintainers and the broader community have enough time to detect them. In July 2025, GitHub made Dependabot cooldown generally available as a defense against software supply chain attacks. However, the effects of its early adoption remain unknown. In this exploratory study, we empirically examine how popular open-source GitHub repositories adopt and configure the feature and investigate their motivations. We find that security concerns motivated 83 of 92 adoption events with known motivations. Security linter warnings triggered 43 of 75 security-only adoptions. Among 251 ecosystems within repositories that retained cooldown, 97.2% set a general delay. Of these, 64.3% used seven days, while use of each update type setting was below 10%. Early adopters therefore favor simple default delays over fine-grained controls. These findings suggest that tools could provide robust defaults reflecting ecosystem support and reserve fine-grained controls for dependencies with clear update priorities. Keywords software supply chain · dependency management · open-source security Corresponding author - Kazumasa Shimari Hidetake Tanaka Nara Institute of Science and Technology, Japan E-mail: [email protected] Rikuto Tsuchida Nara Institute of Science and Technology, Japan E-mail: [email protected] Kazumasa Shimari Wakayama University, Japan E-mail: [email protected] Raula Gaikovina Kula The University of Osaka, Japan E-mail: [email protected] Kenichi Matsumoto Nara Institute of Science and Technology, Japan E-mail: [email protected]

2

Hidetake Tanaka et al.

1 Introduction Software supply chain attacks have emerged as an important threat to open-source ecosystems (Ladisa et al, 2023; Ohm et al, 2020). Attackers can publish malicious packages to registries or compromise existing ones, affecting numerous downstream projects through dependency chains (Zimmermann et al, 2019; Duan et al, 2021). These attacks exploit the trust that developers place in package ecosystems and their automated dependency management workflows (Zahan et al, 2022; Williams et al, 2025). Recent incidents such as the XZ Utils backdoor and the protestware cases in npm show that even updates published by legitimate maintainers can carry malicious payloads (Przymus and Durieux, 2025; Kula and Treude, 2022). The time window between the publication of a new package version and its adoption by developers represents an important attack vector (He et al, 2025; Ohm et al, 2020). Dependency management bots such as Dependabot and Renovate automate the update process (Erlenhov et al, 2022; Alfadel et al, 2021), but they can also automate the rapid adoption of malicious packages if no safeguard is in place. He et al (2023) report that 56.2% of update-check frequencies declared in Dependabot configurations are set to daily, and that 8.17% of Dependabot pull requests are merged by third-party auto-merge implementations such as continuous integration workflows or GitHub Apps. Such practices may shorten the time between release and adoption, reducing the time available for the community to detect malicious packages before they are adopted. To address this risk, several dependency management bots and package managers have introduced cooldown features, which are configurable delay periods before a newly published package version is automatically adopted. Among these, GitHub’s Dependabot released its cooldown configuration in July 2025, positioning it as a supply chain security feature and describing four intended benefits: reduced update noise, responsiveness to critical security patches, granular control through separate delays for each Semantic Versioning (SemVer) level, and flexible scheduling that integrates with existing update intervals.1 Unlike cooldown options built into package managers (available in npm, pnpm, Yarn, Bun, and uv), Dependabot’s implementation supports a wide range of package ecosystems (npm, pip, Maven, Gradle, Bundler, Cargo, Composer, NuGet, Go modules, Docker, GitHub Actions, Terraform, and more) under a single configuration schema. Despite the availability of Dependabot’s cooldown feature and these stated benefits, empirical evidence remains limited on how widely it is adopted or how it is configured in practice. Understanding who adopts the feature, and how they configure and evolve it, provides the empirical basis needed for future effectiveness studies and for tool-design decisions. In this study, we conduct an exploratory empirical analysis of early Dependabot cooldown adoption among top-starred open-source GitHub repositories and provide a focused characterization of early adopters’ configurations. By focusing on a single tool that supports multiple package ecosystems under a unified schema, we avoid 1 https://github.blog/changelog/2025-07-01-dependabot-supports-configurationof-a-minimum-package-age/

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

3

cross-tool heterogeneity while enabling cross-ecosystem comparison. Specifically, we address the following three research questions: – RQ1 (Adoption): How do projects adopt and abandon Dependabot cooldown? – RQ2 (Adopters): What distinguishes Dependabot cooldown adopters? – RQ3 (Configuration): How do adopters configure and adjust Dependabot cooldown? The main contributions of this study are as follows: – Empirical evidence on Dependabot’s cooldown feature, characterizing early adoption among popular open-source GitHub repositories across the diverse package ecosystems it supports under a single configuration schema. – A combined quantitative and qualitative investigation of who adopts the feature, including project characteristics and adoption motivations through analysis of related Issues and Pull Requests. – Evidence from the 135 observed early adopters on how they use the configuration mechanisms associated with Dependabot’s stated benefits (e.g., SemVerlevel granular control, flexible scheduling), with implications for tool designers and open-source maintainers. 2 Related Work 2.1 Software Supply Chain Security Software supply chain attacks have attracted increasing attention from both researchers and practitioners. Ladisa et al (2023) presented a comprehensive taxonomy of attacks on open-source software supply chains, categorizing attack vectors across the entire software development lifecycle. Their taxonomy identifies the publication of malicious packages as a prevalent attack strategy, where attackers exploit the trust inherent in package registries. Ohm et al (2020) collected and analyzed real-world instances of open-source supply chain attacks, providing a systematic overview of attack types and techniques. Their work highlighted that attackers frequently target package registries by publishing packages with names similar to popular ones. Zimmermann et al (2019) studied security threats in the npm ecosystem and demonstrated that the heavy reliance on a small number of highly influential packages creates widespread risks. Their findings showed that compromising a single popular package could affect thousands of downstream projects. Duan et al (2021) measured supply chain attacks on package managers for interpreted languages, quantitatively assessing the scale and impact of such attacks. Vu et al (2020) investigated typosquatting and combosquatting attacks on the Python ecosystem, revealing that these attacks exploit common typographical errors in package names to distribute malicious code. Recent high-profile incidents further show that legitimate maintainers and the update path itself can become the attack surface. The 2024 XZ Utils backdoor was planted after a long social-engineering campaign that gained the trust of the project’s maintainer (Przymus and Durieux, 2025; Lins et al, 2026). Protestware cases such

4

Hidetake Tanaka et al.

as colors, faker, and node-ipc demonstrated that even legitimate maintainers can ship destructive updates in protest of world events (Kula and Treude, 2022; Cheong et al, 2024). Industry reports likewise document a sustained rise in malicious packages published to open-source registries (Sonatype, 2026), and Williams et al (2025) synthesize these developments into a research roadmap for software supply chain security. These cases share a common pattern: the malicious payload enters as an ordinary version release and reaches the downstream projects that adopt it quickly. Beyond characterizing attacks, researchers have also proposed techniques to detect malicious packages automatically. Sejfia and Schäfer (2022) developed an automated approach that identifies malicious npm packages based on package metadata and code features, and Guo et al (2023) conducted an empirical study of malicious code in the PyPI ecosystem. Gonzalez et al (2021) detect anomalous and potentially malicious commits from commit logs and repository metadata, and Vu et al (2021) identify discrepancies between the source repository of a package and the artifact distributed through the registry. Complementing these detection approaches, Zahan et al (2022) identified weak-link signals in the npm supply chain, such as expired maintainer domains and install scripts, that indicate a heightened risk of compromise. These detection techniques are complementary to cooldown mechanisms: cooldown provides the time window during which detection tools and community reports can identify malicious packages before downstream adoption. While these studies have advanced our understanding of attack characteristics, their impact, and detection techniques, they leave the adoption of defense mechanisms such as cooldown features insufficiently understood. Our study addresses this gap by empirically investigating how cooldown features are configured and adopted across ecosystems.

2.2 Dependency Management Bots Dependency management bots automate the process of keeping library dependencies up to date and have become increasingly popular in open-source software development (He et al, 2023). Alfadel et al (2021) investigated the use of Dependabot security pull requests, analyzing how developers respond to automated security updates. Their study revealed that while Dependabot helps developers address known vulnerabilities, a significant portion of security pull requests remain unmerged. Mirhosseini and Parnin (2017) found that projects using automated pull request notifications updated dependencies 1.6 times as often as projects that did not use notification tools, although only about one third of the automated pull requests were merged. Their survey identified breaking changes, difficulty understanding the implications of updates, and migration effort as developers’ principal concerns. The benefits of dependency bots come with a notification cost. Wessel et al (2018) characterized the widespread use of bots in open-source projects, and Wessel et al (2021) identified the interruptions and noise that bot interactions impose on maintainers as a central challenge. Rombaut et al (2023) quantified this overhead for the

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

5

Greenkeeper dependency bot in npm, showing that a large share of its notifications demand maintainer attention without delivering a corresponding benefit. These studies have examined the prevalence, effectiveness, and overhead of dependency management bots, but evidence remains limited on the usage of cooldown configurations offered by these bots. Because cooldown delays and batches updates, it also bears on this overhead by reducing the pull requests that maintainers must triage, yet how projects configure such delay-based safeguards remains unclear. Our work complements this line of research by specifically examining how projects configure them across ecosystems.

2.3 Dependency Update Lags Dependency update lag refers to the delay between the release of a new library version and its adoption by downstream projects. Kula et al (2018) conducted an empirical study on whether developers update their library dependencies in response to security advisories. Their findings indicated that many developers are unaware of or reluctant to update their dependencies, even when security advisories are available. Chinthanet et al (2021) investigated the lags in the release, adoption, and propagation of npm vulnerability fixes. Their study revealed that significant delays exist at each stage of the vulnerability fix pipeline, from the release of a patch to its propagation through the dependency network. The notion of technical lag, how far a deployment is behind the latest available releases, was introduced by Gonzalez-Barahona et al (2017) and formalized and applied to npm by Zerouali et al (2019). Cox et al (2015) showed that low dependency freshness is associated with security risk, which highlights the cost side of delaying updates. Release and update dynamics also differ substantially across ecosystems: Decan et al (2019) compared the evolution of dependency networks in seven package ecosystems, and Wittern et al (2016) documented the high release frequency and dense dependency structure of the npm ecosystem. Côgo et al (2021) further showed that developers respond to problematic releases by downgrading dependencies, which suggests that adopting a release immediately carries a rollback cost that a waiting period can avoid. Dependabot’s separate cooldown delays for each SemVer level presuppose the compatibility conventions of semantic versioning. Empirical studies temper this assumption: Raemaekers et al (2017) and Ochoa et al (2022) showed that breaking changes also appear in minor and patch releases in the Maven ecosystem, and Bogart et al (2016) found that ecosystems differ in their practices and values around breaking changes. Decan and Mens (2021) showed that most dependency constraints follow semver-compatible ranges that accept new releases automatically, which is precisely the mechanism that lets a malicious release propagate quickly. The way developers declare version constraints also shapes their exposure: Dietrich et al (2019) documented the diversity of versioning practices across ecosystems, and Jafari et al (2022) identified constraint choices such as restrictive pinning and wildcards as dependency smells with maintenance and security consequences.

6

Hidetake Tanaka et al.

It is important to distinguish between cooldown features and unintentional update lags. Cooldown introduces a controlled, intentional delay designed to protect against supply chain attacks, whereas update lags arise from developer inattention or reluctance to update dependencies. Our study focuses on the former, that is, on the deliberate adoption and configuration of cooldown mechanisms as a proactive defense strategy. Cooldown as a concept predates Dependabot’s 2025 release. Renovate introduced its stabilityDays option in 2019 to address a stability concern: npm allows packages to be unpublished within 72 hours of release2 , and immediately adopting new versions could break builds when packages were retracted. In contrast, the wave of cooldown features introduced in 2025 and 2026 by Dependabot and by package managers such as pnpm, Yarn, Bun, npm, and uv was explicitly motivated by supply chain security, aiming to prevent the rapid adoption of malicious packages amid a rising threat of malicious package updates (Sonatype, 2026; Williams et al, 2025). Our study focuses on Dependabot as one instance of this newer, security-driven wave.

3 Study Design 3.1 Overview We conduct an exploratory empirical study of the early adoption of Dependabot’s cooldown feature across the package ecosystems that Dependabot supports, using top-starred open-source repositories hosted on GitHub. The study consists of three phases. First, identification of the target tool, second, data collection from GitHub repositories, and third, quantitative and qualitative analysis to answer our three research questions. We limit the study to Dependabot, GitHub’s official dependency management bot, which made its cooldown configuration generally available in July 2025 and accounts for more than 65% of dependency management activity on GitHub (Rebatchi et al, 2024). We select it because it provides a unified configuration schema across its supported package ecosystems and offers fine-grained settings, including separate delays for each SemVer level and scoping at the package level, that allow us to compare configuration choices across ecosystems and repositories.

3.2 Data Collection Figure 1 summarizes how we narrow the candidate repositories down to the analysis population. We first retrieve candidate repositories. We then filter them by repository status, Dependabot configuration existence, recent activity, and configuration validity. During candidate retrieval, we build the initial set from the 10,000 GitHub repositories with the most stars listed in Gitstar Ranking,3 a publicly available ranking 2 3

https://docs.npmjs.com/policies/unpublish https://gitstar-ranking.com/repositories

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

7

GitHub

Gitstar Ranking

10,000

Repository status

Config existence

Recent activity

Config validity

repositories repos_raw.csv

• Fork: −57 • Archived: −758 • HTTP error: −20

•No dependabot:−7,636

• No push since 2025-07-01: −57

• Parse error: −5 • No ecosystem: −4 • No cooldown: −1

1,462 repositories

Fig. 1 Filtering stages from the candidate repositories to the analysis population, with the number of repositories excluded at each stage

service that aggregates GitHub’s public data. By restricting the candidates to repositories with the most stars, we focus the analysis population on popular and visible projects where user bases, dependency management activity, and security practices are more likely to be observable, making early adoption of a new feature more likely to appear in the data. We retrieved the list on 2026-05-01 12:09 UTC, roughly 12 hours after the study cutoff of 2026-04-30 24:00 UTC. Gitstar Ranking refreshes its data on a fixed schedule, so the ranking we observed may reflect star counts that lag by up to 7 days. When checking repository status, we use GitHub REST API metadata to exclude 57 forked and 758 archived repositories. This avoids known pitfalls in GitHub mining studies (Kalliamvakou et al, 2014). We also exclude 20 repositories whose metadata we could not retrieve. This stage leaves 9,165 repositories. When checking for configuration files, we query the GitHub REST API for both paths that Dependabot officially recognizes, .github/dependabot.yml and .github/ dependabot.yaml, and we refer to both variants as the Dependabot configuration file. In these YAML files, each entry directly under the updates field identifies a target ecosystem and directory, and cooldown is configured within such an entry. We exclude 7,636 repositories that contain neither file and retain the 1,529 repositories that contain at least one variant. When filtering for recent activity, we retain a repository if its pushed_at, the time of its last change, is on or after 2025-07-01, the date when Dependabot announced the general availability (GA) of the cooldown feature. Every repository in our observation therefore had the opportunity to adopt cooldown. This filter removes 57 repositories and leaves 1,472. We set the observation cutoff at 2026-04-30 to capture one month of activity after the 2026-03-31 axios incident, in which malicious axios versions were published from a compromised npm account and injected a dependency that installed a remote access trojan (Saayman, 2026). The observation window therefore spans roughly ten months from 2025-07-01 to 2026-04-30. When validating configurations, we enumerate every commit within the observation window that touches the Dependabot configuration file, take a full YAML snapshot at each such commit, and parse the snapshot. We exclude five repositories whose configuration at the cutoff fails to parse due to YAML syntax errors such as incorrect indentation or missing required headers. We further exclude four repositories whose package-ecosystem field is empty across every updates entry at the cutoff. An empty package-ecosystem field indicates the default GitHub-generated template used without customization. Because such a file configures no ecosystem, we do not treat it as a valid Dependabot configuration.

8

Hidetake Tanaka et al.

During our observation window, Dependabot took the delay from default-days and the three semver-*-days keys and treated an absent key as zero days4 . One repository uses the unrecognized default: 4 instead of default-days: 4 in its cooldown. Because none of the recognized day keys is present, its cooldown delays no update even though it appears in the file. We therefore exclude the repository from the analysis population before classifying adoption status. After these steps, the final analysis population consists of 1,462 repositories. To characterize both the uptake and persistence of cooldown, we classify each repository into one of four mutually exclusive adoption states based on its configuration history during the observation window and its status at the cutoff. 1. Non-adopter. The repository never held a cooldown during the observation window. 2. Continuous adopter. The repository adopted cooldown and still holds it at the cutoff without its cooldown count having dropped to zero after adoption. 3. Re-adopted adopter. The repository’s cooldown count dropped to zero, later rose above zero again, and remains above zero at the cutoff. 4. Abandoned adopter. The repository adopted cooldown during the observation window but no longer holds it at the cutoff. We apply the same four states to individual ecosystems within repositories. If an ecosystem’s updates entry is removed entirely, we treat it as a discontinuation of management for that ecosystem rather than abandonment of cooldown and exclude it from this classification. For the repository-level analysis in RQ2, we combine adoption status derived from configuration histories with repository metadata, dependency counts, Dependabot pull request activity, and the history of configuration edits before GA. Table 1 defines the measures and their observation periods. The replication package documents the schema of each file, the joins, the API calls behind each measure, and how we handle the repositories for which a retrieval fails. For the repositories whose dependency graph is unavailable, we count dependencies with Bibliothecary5 , a Ruby library that parses manifest and lock files. We use a pre-GA annual edit rate to examine whether active maintenance of a repository’s Dependabot configuration is related to cooldown adoption. We restrict the measure to edits before GA because an edit count during the observation window would include the cooldown-introduction commit for adopters, thereby confounding maintenance activity with adoption itself. Among repositories that already held the configuration file at GA, we count the commits that edited the file from its first addition through GA and divide this count by the years in that span to obtain the annual edit rate. Of the 1,462 repositories, 1,289 had the file at GA with an identifiable first commit and enter this analysis. We exclude 154 that had no Dependabot configuration before GA, 18 with no commit before GA because they were created later or their history was rewritten, and 1 for which we could not retrieve the GA snapshot. 4 https://github.com/dependabot/dependabot-core/blob/2eaf27b6c3882b791f6feab1ddcd933c8d63c4a7/ common/lib/dependabot/package/release_cooldown_options.rb#L22-L25 5 https://github.com/librariesio/bibliothecary

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

9

Table 1 Repository-level measures collected for the analyses, their operational definitions, data sources, and measurement periods. GA denotes general availability. Measure

Operational definition

Adoption status

Whether a repository held at least one cooldown at any point Dependabot configuration file in the observation window. history over the observation window. Number of users who starred the repository. GitHub repository metadata at the cutoff. Years from the repository creation date to the observation GitHub repository metadata at the cutoff. cutoff. Number of contributors returned for the repository. GitHub contributors endpoint with data collected for the cutoff. Whether the repository owner is a User or an Organization. GitHub repository metadata at the cutoff. Number of distinct pairs of ecosystem and package name, GitHub dependency graph at the with different versions of one package counted once. cutoff, supplemented with Bibliothecary when unavailable. Number of pull requests opened by dependabot[bot] for Dependabot pull requests over the the repository. observation window. Per-repository median hours from creation to merge among Dependabot pull requests over the merged Dependabot pull requests. observation window for repositories with at least one merged bot pull request. Whether GitHub’s native auto-merge was enabled on at least Dependabot pull requests over the one Dependabot pull request. observation window. Whether the repository published a SECURITY.md file. Repository files at the cutoff. Dominant programming language reported for the GitHub repository metadata in repository. repos at the cutoff. Commits editing the Dependabot configuration from its first Dependabot configuration file addition through GA, divided by the elapsed years. history before GA for repositories that held the file at GA.

Stars Repository age Contributors Owner type Dependencies

Bot pull request count Merge time

Auto-merge SECURITY.md Primary language Pre-GA edit rate

Source and period

3.3 Analysis Methods We describe the analysis methods for each research question below. Following the conventional 0.05 level for statistical testing (Fisher, 1925), we use p < 0.05 as the threshold for statistical significance in standalone tests. 3.3.1 RQ1: Adoption and Abandonment To answer RQ1, we use the Dependabot configuration histories and related development artifacts constructed in Section 3.2. We organize the analysis into four complementary steps. 1. Cutoff snapshot. We examine the distribution of adoption and abandonment at the cutoff. 2. Repository-level timeline. We examine the cumulative adoption timeline at the repository level. 3. Ecosystem-level analysis. We examine adoption rates across ecosystems. 4. Motivation analysis. We conduct a qualitative content analysis of the motivations behind adoption and abandonment. The first three steps are quantitative analyses based on the commit histories of Dependabot configuration files. The fourth uses manual coding of related commits, pull requests, and issues.

10

Hidetake Tanaka et al.

Step 1: Cutoff Snapshot. To gauge how widely cooldown has spread, we examine the overall breakdown of adoption and abandonment. For the cutoff distribution, we count both repositories and ecosystems within repositories under the four adoption states defined in Section 3.2. Step 2: Repository-Level Timeline. We also examine the repository-level adoption timeline. A repository’s adoption timestamp is the commit at which a cooldown first appears anywhere in the repository. We plot the cumulative count of adopter repositories. Step 3: Ecosystem-Level Analysis. Because adoption may differ across ecosystems, we also examine ecosystem-level adoption rates at the cutoff. The unit for the adoption rate is also an ecosystem within a repository. For each ecosystem, we divide the number of repositories that hold a cooldown in it by the number of repositories that still declare it at the cutoff. One repository can declare several ecosystems, and cooldown adoption may follow a policy that covers the whole repository rather than the traits of an individual ecosystem, so observations that share a repository are correlated. We therefore test differences in the adoption rate across ecosystems with a mixed-effects logistic regression (Breslow and Clayton, 1993) that places a random intercept at the repository level. We compare a model with ecosystem as a fixed effect against a model with only the random intercept in a likelihood-ratio test and base our inference on the overall contribution of the ecosystem fixed effect. This test evaluates whether cooldown adoption propensity differs across ecosystems overall after accounting for repository-level variation. Including ecosystems declared by very few repositories can make the estimates unstable. Our primary analysis covers all 28 ecosystems, and we also run a sensitivity check restricted to the ecosystems declared by at least 30 repositories. Quasicomplete separation for ecosystems with no observed adopters and limited withinrepository contrasts from repositories that declare only one ecosystem can destabilize the individual fixed-effect estimates. The mixed-effects model restricted to ecosystems declared by at least 30 repositories did not converge. For this sensitivity analysis, we therefore fit a population-averaged logistic regression using generalized estimating equations (GEE) (Liang and Zeger, 1986), clustered by repository. The model assumes an exchangeable working correlation within repositories and uses robust sandwich standard errors. Step 4: Motivation Analysis. For the fourth analysis, we manually classify the motivation behind each repository’s first-time cooldown adoption event (n = 135), following established guidance on qualitative content analysis and thematic synthesis (Krippendorff, 2019; Cruzes and Dybå, 2011). For each event, we inspect the commit message, the pull request title and body, and the title and body of any issue referenced by the commit or pull request. Two authors independently assign one of the following labels to each of these 135 repository-level first-time adoption events.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

11

1. Security (Linter). The cooldown was introduced in response to a warning from a linter that detects vulnerabilities, such as zizmor6 , a static analysis tool for GitHub Actions workflows that flags security-related configuration issues. 2. Security (No-Linter). The introduction was motivated by supply chain security and was unrelated to any linter. 3. Maintenance. The goal was to reduce the volume of Dependabot update pull requests and to improve code maintainability, as in wording that calls Dependabot pull requests noisy or expresses a wish to receive fewer of them. 4. Security and maintenance. The motivation spans both aspects. This includes wording that explicitly mentions both maintenance and security, as well as broader wording about stability or about adopting upstream bug and regression fixes that fits either side. 5. Template tracking. The cooldown adoption pull request was created automatically by following a repository that manages shared configuration, without an explicit adoption decision in the adopting repository. 6. Unknown. No clear motivation is stated. We treat wording about stability or about upstream bugs and regressions as Security and maintenance, because such wording carries both a maintenance aspect and a security aspect. When a pull request body or commit message links to an external article, we also read the article and include it in this judgment. We measure inter-rater reliability using Cohen’s kappa (Cohen, 1960) and interpret the agreement level following the guidelines of Landis and Koch (1977). We resolve disagreements through discussion and assign a single label. We report the distribution of the motivation categories together with representative examples for each. We also study the motivations behind abandoning cooldown. At the repository level, we examine commits at which a repository’s cooldown count drops to zero. Abandonment at the level of an ecosystem within a repository is also possible. For such an ecosystem, we examine the commits that remove cooldown from one ecosystem while the updates entry stays in place and the repository keeps cooldown on its other ecosystems. We exclude removals that delete the updates entry itself, which discontinue management of that ecosystem rather than reject cooldown, and we likewise exclude removals that delete the Dependabot configuration file entirely. We read the pull request body and the commit message that removed cooldown, and we analyze the stated motivations. 3.3.2 RQ2: Adopter Characteristics Adoption prevalence alone does not show whether cooldown has diffused broadly or remains concentrated among projects with greater maintenance capacity, heavier dependency-update workloads, or more visible security practices. RQ2 therefore compares adopter and non-adopter repositories to identify characteristics associated with early adoption. This characterization clarifies which project populations are rep6

https://github.com/zizmorcore/zizmor

12

Hidetake Tanaka et al.

resented among early adopters and provides a basis for future tool design and adoption studies. The unit of analysis for RQ2 is a repository. We define the 135 repositories that held at least one cooldown during the observation window as adopters and the 1,327 that never held one as non-adopters. Adoption status is the binary outcome, and the repository measures defined in Table 1 serve as the explanatory variables. We select attributes that capture six dimensions that may relate to early adoption: project visibility and maturity, maintenance capacity and governance, the burden of dependency updates, update workflow, visible security practices, and technical context. Stars and repository age represent visibility and maturity. Contributors and owner type represent maintenance capacity and governance. Dependencies and bot pull request count represent update burden. Merge time, auto-merge, and the pre-GA edit rate represent update workflow. The presence of SECURITY.md represents visible security practice. Primary language represents technical context. Prior work reports that daily schedules and auto-merge are widespread in Dependabot use (He et al, 2023), giving further reason to examine whether these operational characteristics differ between adopters and non-adopters. The analysis proceeds in two stages. In the first stage, we conduct univariable comparisons between adopters and non-adopters using six continuous variables: stars, repository age, contributors, dependencies, bot pull request count, and merge time. We also compare three binary variables: owner type, SECURITY.md presence, and auto-merge use. Primary language is compared separately, and the pre-GA edit rate serves as a supplementary analysis. In the second stage, to adjust for correlation among attributes, we fit a multivariable logistic regression over the 1,461 repositories with a dependency count. The main model includes the five continuous variables other than merge time, the three binary variables, and primary language. Because merge time and the pre-GA edit rate are defined only for subsets, we add each separately to the main model in a sensitivity analysis. In the main model, primary language is categorical, with Python, the most common individual language among adopters, as the reference. To stabilize its coefficients, we keep only languages with at least 10 adopter repositories as individual categories and fold the rest into Other. We apply a log1p transform to the continuous variables and standardize them to zero mean and unit standard deviation, so an odds ratio expresses the change in adoption odds per one standard deviation increase on the transformed scale. For continuous variables, we use the Mann-Whitney U test (Mann and Whitney, 1947) and report Cliff’s delta (Cliff, 1993). For binary variables, we use the chi-squared test (Pearson, 1900) and report Cramér’s V (Cramér, 1946). Primary language has many cells with small expected counts, so we use Fisher’s exact test on the full ungrouped distribution and report Cramér’s V. Because exact enumeration is impractical, we approximate the p-value with 10,000 Monte Carlo resamples using a fixed seed of 0. In the paper and the multivariable model, we show languages with at least 10 adopter repositories individually and fold the rest into Other. The full distribution is included in the replication package. To interpret the magnitude of Cliff’s delta, we adopt the thresholds documented for the cliff.delta function in the R package effsize (Torchiano, n.d.), clas-

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

13

sifying the absolute effect size as negligible for |δ | < 0.147, small for 0.147 ≤ |δ | < 0.33, medium for 0.33 ≤ |δ | < 0.474, and large for |δ | ≥ 0.474. Following Cohen (1988), we use small, medium, and large thresholds of 0.10, 0.30, and 0.50 for Cramér’s V. Every contingency table in this comparison has two columns, adopters and non-adopters, so these thresholds for one degree of freedom apply throughout. For the univariable comparisons used to identify adopter characteristics, we treat the six continuous-variable and three binary-variable comparisons as one family of nine tests. We control its false discovery rate at q = 0.05 with the Benjamini–Hochberg (BH) procedure (Benjamini and Hochberg, 1995), base statistical significance on the BH-adjusted p-values, and report only these adjusted values. For the multivariable model, we use Spearman rank correlations to describe pairwise associations among the five continuous and three binary repository attributes and calculate variance inflation factors (VIFs) for all explanatory variables in the main model, including primary language (Dormann et al, 2013). We use a VIF of 5 as an empirical screening criterion for further investigation (James et al, 2021), while treating it as a guide rather than a definitive cutoff (O’Brien, 2007). We estimate the model by maximum likelihood and report an odds ratio (OR) adjusted for the other variables in the model, a 95% confidence interval (CI), and a two-sided p-value for each explanatory variable. We treat coefficient-level inference as exploratory and interpret the estimates primarily using the odds ratios and confidence intervals. We report McFadden’s pseudo R2 (McFadden, 1974) as a summary of model fit and the apparent area under the receiver operating characteristic curve (AUC) (Hanley and McNeil, 1982) as a measure of in-sample discrimination. Because the pull request metrics span the full observation window, adopter measurements may include post-adoption observations and should not be interpreted purely as pre-adoption characteristics. We discuss this limitation in Section 5. 3.3.3 RQ3: Configuration Choices It is not yet known how adopters configure cooldown, how far they use fine-grained controls such as SemVer granularity and the include and exclude lists, and how they change it after adoption. To clarify this, in RQ3 we analyze the cooldown configuration values. We organize the analysis into three parts: the set rate and value distribution of each key, value changes after adoption, and the comparison of these values within the same repository. The keys available within a cooldown field are listed in Table 2. The default-days key defines the baseline delay for the target ecosystem. For ecosystems that follow SemVer (Decan and Mens, 2021), semver-major-days, semver-minor-days, and semver-patch-days override default-days for their respective update types. The include and exclude lists use wildcard patterns to scope the dependencies to which cooldown applies, and exclude takes precedence when a dependency matches both lists. For each cooldown field, we extract the configured delay values and the include and exclude lists shown in the table. All measurements come from the observation cutoff of 2026-04-30.

14

Hidetake Tanaka et al.

Table 2 Keys of the Dependabot cooldown configuration (GitHub, n.d.). SemVer denotes Semantic Versioning. Key

Description

Baseline delay for dependencies without a more specific rule. Delay for major SemVer updates. Takes precedence over default-days. semver-minor-days Delay for minor SemVer updates. Takes precedence over default-days. semver-patch-days Delay for patch SemVer updates. Takes precedence over default-days. include Dependencies the cooldown applies to (wildcards allowed). exclude Dependencies omitted from the cooldown (wildcards allowed). Takes precedence over include. default-days semver-major-days

To clarify whether adopters rely on default-days alone or also use the SemVerlevel delays and the include and exclude lists, we examine how each key is set. For default-days and each of the three SemVer keys semver-major-days, semver-minor-days, and semver-patch-days, we report the percentage of the ecosystems within repositories that set it, and for the numeric values the median, the most common value, and the maximum over those that set it. To remove the influence of repositories that set several cooldowns in the same ecosystem, up to 22 in our data, the unit of analysis is an ecosystem within a repository, and its value is the minimum across the cooldowns of that ecosystem. We examine differences in values across the cooldowns within the same repository in a later sub-analysis. We also describe default-days by ecosystem. The unit is an ecosystem within a repository, represented by its minimum default-days. To avoid unstable summaries based on very few cases, we report the median for ecosystems in which at least five repositories set the value. For the exclude entries, we also read the pull requests and commits that introduced them and analyze the stated motivations. An adopter may also adjust its configuration while keeping the cooldown feature enabled. We analyze these subsequent changes at the level of an ecosystem within a repository. For each field whose value is in days, namely default-days, semver-major-days, semver-minor-days, and semver-patch-days, we count additions and removals based on whether any cooldown in that ecosystem of the repository sets it. An addition is a commit at which the number of cooldowns setting the field in that ecosystem rises from zero to one or more, and a removal is the reverse. The settings at adoption and reintroduction serve as baselines, so keys already present at those points are not counted as additions. We count additions and removals only between consecutive snapshots in which the ecosystem retains cooldown, so a key that disappears with the cooldown or its parent updates entry is not counted as a removal. We count increases and decreases from the value itself. Because one ecosystem may hold several cooldowns, we use the minimum across the cooldowns that set a field as the representative value. For example, if the same ecosystem has two cooldowns that both set default-days, we use the smaller of the two values.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

15

Table 3 Repository counts and counts of ecosystems within repositories by adoption category. Category

Repository

Ecosystem within repo.

Adopter Continuous adopter Re-adopted Abandoned Non-adopter

135 132 3 0 1,327

252 243 8 1 2,298

Total

1,462

2,550

For include and exclude, which have no numeric value, we count only additions and removals. We report the frequency of each kind of change. In addition to the aggregation by ecosystem within a repository, we examine repositories that hold multiple cooldowns with different values. We count adopter repositories with at least two cooldowns that differ in default-days or any of the SemVer values. 4 Results 4.1 Dataset Overview At the cutoff, the population covers 28 distinct package ecosystems, and a repository declares a median of 2 ecosystems and up to 17. Over the window, 1,455 commits edited a Dependabot configuration file and the Dependabot bot opened 95,516 version-bump pull requests. 4.2 RQ1: Adoption and Abandonment For the cutoff distribution, the final analysis population consists of 1,462 repositories, and 2,550 ecosystems within repositories have an updates entry present at the cutoff. Table 3 gives the four-category breakdown of Section 3 for repositories and for these ecosystems. The repositories split into 135 adopters and 1,327 non-adopters. The ecosystems split into 252 adopters and 2,298 non-adopters, and the 252 adopters comprise 243 continuous adopters, 8 re-adopted adopters, and 1 abandoned adopter. A re-adopted adopter dropped its cooldown to zero and restored it at a later commit, and an abandoned adopter removed cooldown and did not restore it by the cutoff. The 243 continuous and 8 re-adopted ecosystems, 251 in total, hold a cooldown at the cutoff, while the 1 abandoned ecosystem does not. At the repository level no adopter counts as abandoned, and every adopter keeps a cooldown in at least one ecosystem at the cutoff. No adopter withdrew cooldown entirely within the observation window, and when an adopter removed it the removal was confined to some of its ecosystems, which suggests that adopters do not reject the feature itself but keep it while narrowing the scope in which they use it. For the repository-level adoption timeline, Figure 2 shows the monthly cumulative count of adopter repositories. The count rises monotonically throughout the

Hidetake Tanaka et al.

150 100 50 0

20

25 -0 20 7 25 -0 20 8 25 -0 20 9 25 -1 20 0 25 -1 20 1 25 -1 20 2 26 -0 20 1 26 -0 20 2 26 -0 20 3 26 -04

Cumulative adopter repositories

16

Month Fig. 2 Cumulative repository-level adoption over the observation window

observation window, and the largest monthly increases were in 2026-03 and 2026-04 near the cutoff. This increase is consistent with a feature still early in its diffusion rather than one that has reached saturation, but the 2026-03-31 axios incident may also have prompted some adoptions. Because this study does not causally separate responses to individual incidents, we treat the acceleration near the cutoff as an observed pattern that may include such incident-driven adoption. Table 4 reports adoption rates by ecosystem. Among the five ecosystems declared by at least 100 repositories, pip has the highest rate at 13.6%. The mixedeffects model for all 28 ecosystems, which accounts for observations clustered within repositories, completed without a convergence warning or a singular fit. Its omnibus likelihood-ratio test found no significant ecosystem effect (χ 2 = 17.99, d f = 27, p = 0.904). However, quasi-complete separation caused by ecosystems with no observed adopters made more than half of the individual coefficients diverge, so the omnibus result should be interpreted with this estimation limitation in mind. In the GEE sensitivity analysis of the 11 ecosystems declared by at least 30 repositories, none of the estimable individual terms was significant (minimum p = 0.057). The term for composer could not be estimated because it had no observed adopters. This does not establish that ecosystems never differ, but we found no robust evidence of ecosystem-level differences in cooldown adoption. We label the 135 repository-level first-time adoption events with the motivation categories defined in Section 3. Cohen’s kappa between the two raters was 0.90, which is almost perfect under the guidelines of Landis and Koch. Table 5 reports the distribution with a representative example per category. Security (Linter) is tied with Unknown as the largest category, which shows that many cooldown additions were made in response to warnings from security linters such as zizmor. By contrast, repositories under the Maintenance label adopted cooldown to reduce pull request noise rather than for security. For the 43 Unknown

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

17

Table 4 Cooldown adoption rate per package ecosystem at the observation cutoff, over the repositories declaring each ecosystem. The 17 ecosystems declared by fewer than 30 repositories form the Others row. Ecosystem

Adopter

Total

Rate

github-actions npm gomod pip docker cargo maven bundler gradle composer nuget Others

116 38 15 22 10 6 7 12 7 0 2 16

1,200 361 210 162 116 81 71 67 64 47 47 124

9.7% 10.5% 7.1% 13.6% 8.6% 7.4% 9.9% 17.9% 10.9% 0.0% 4.3% 12.9%

Total

251

2,550

9.8%

Table 5 Distribution of adoption motivations over the 135 first-time adoption events, with a representative quote per category. PR denotes pull request. Motivation

n

%

Security (Linter) Security (No-Linter) Security and maintenance Maintenance Template tracking Unknown

43 31.9% 32 23.7% 8 5.9% 6 4.4% 3 2.2% 43 31.9%

Total

135

Representative quote ci: fix issues flagged by Zizmor Prevent some supply-chain attack vectors improve dependabot configuration: more stability deps(dependabot): less noisy PRs Synchronize shared configuration Add cooldown to dependabot

-

events, the repositories likely had some intent behind the introduction, but it did not appear on GitHub. Among the 92 events with an identified motivation, 75 are security-only: 43 Security (Linter) and 32 Security (No-Linter). Another 8 events combine security with maintenance concerns. Thus, security is present in 83 identified events, but most of this signal comes from security-only adoption rather than from ambiguous mixed cases. Within the 75 security-only events, 43 (57.3%) are triggered by a security linter warning such as zizmor. This suggests that security linter warnings can act as an adoption trigger or compliance pressure, making cooldown adoption partly tool-mediated rather than purely a maintainer-initiated security decision. We identified three repository-level removal events, all in Homebrew repositories. Across these events, cooldown was removed from six ecosystem configurations. The maintainers were investigating why Dependabot pull requests were not opening, and later configuration updates restored cooldown in all three repositories. We also found three ecosystem-level removals in repositories that retained cooldown elsewhere. The nodejs/node github-actions entry is the only one that remained without cooldown at the cutoff. Its maintainer removed the setting after documentation and a continuous integration failure indicated that github-actions did not support it. The other two cases

18

Hidetake Tanaka et al.

involved docker in future-architect/vuls and Homebrew/brew. In both, cooldown was removed when the unsupported setting prevented Dependabot from running and was restored after docker support became available. The observed removals therefore reflect operational or compatibility problems rather than lasting rejection of cooldown. RQ1 Summary Answering RQ1, 135 of the 1,462 repositories adopted cooldown, with adoption continuing to grow and known motivations centered on security, often through linter warnings. No adopter abandoned cooldown at the repository level, and the few observed removals were generally temporary responses to operational or compatibility problems.

4.3 RQ2: Adopter Characteristics We first use univariable comparisons to describe how adopters and non-adopters differ in each observed attribute. We then estimate a multivariable model to assess whether each attribute is associated with adoption after adjusting for the other attributes. After BH adjustment, Tables 6 and 7 show that adopters have significantly more stars, contributors, dependencies, and bot pull requests, as well as significantly higher rates of organization ownership and SECURITY.md presence. Among repositories with at least one merged Dependabot pull request, the 124 adopters also have significantly shorter merge times than the 1,034 non-adopters. The bot pull request count has a medium effect, while the other significant differences are small or negligible. Repository age and auto-merge usage show no statistically significant differences after BH adjustment. These univariable relationships may change when correlated attributes are considered together. Table 8 shows relatively high adoption rates for Python, JavaScript, and Ruby, and lower rates for Go, TypeScript, and Java. Fisher’s exact test on the full ungrouped language distribution is significant (p = 0.009), with a small Cramér’s V of 0.268. The pre-GA configuration edit rate is also higher among adopters. Across 115 adopters and 1,174 non-adopters, the medians are 1.45 and 0.84 edits per year, reTable 6 Adopter and non-adopter comparison for the six continuous variables at the observation cutoff. The sample includes 135 adopters and 1,327 non-adopters, except for dependencies (135 and 1,326) and merge time (124 and 1,034). Cells are group medians, with repository age in years and merge time in hours. Bold indicates a p-value that is significant at q = 0.05 after Benjamini–Hochberg (BH) adjustment. Variable Stars Repository age Contributors Bot pull request count Merge time Dependencies

Adopter Non-ad. BH-adj. p 11,464 11.06 360 54 10.87 187

9,051 10.87 179 19 19.17 91.5

δ Mag.

0.024 +0.12 negligible 0.054 +0.10 negligible <0.001 +0.32 small <0.001 +0.36 medium 0.009 −0.15 small 0.002 +0.17 small

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

19

Table 7 Adopter and non-adopter comparison for the three binary variables at the observation cutoff. Bold indicates a p-value that is significant at q = 0.05 after Benjamini–Hochberg (BH) adjustment. Variable Organization owner Auto-merge SECURITY.md

Adopter Non-ad. BH-adj. p 88.1% 20.0% 54.8%

V Mag.

<0.001 0.12 small 0.054 0.05 negligible <0.001 0.12 small

68.7% 13.4% 34.4%

Table 8 Primary language of each repository for adopters and non-adopters. Languages with fewer than 10 adopter repositories are grouped as Other. Category

Adopter

Non-adopter

37 17 13 18 10 11 29

204 208 140 117 101 50 507

Python Go TypeScript JavaScript Java Ruby Other (< 10 adopter repositories)

Total

Rate

241 15.4% 225 7.6% 153 8.5% 135 13.3% 111 9.0% 61 18.0% 536 5.4%

Table 9 Multivariable logistic regression of cooldown adoption on repository attributes and the primary language, reporting odds ratios (ORs) and 95% confidence intervals (CIs). Continuous variables are logtransformed and standardized, so an OR is per one standard deviation increase. Language ORs are relative to Python. The p-values are unadjusted. The model covers 1,461 repositories with 135 adopters and 1,326 non-adopters, with a McFadden pseudo R2 of 0.13 and an apparent area under the receiver operating characteristic curve (AUC) of 0.77. Variable

OR

Contributors Bot pull request count Organization owner SECURITY.md presence Stars Repository age Dependencies Auto-merge

1.45 1.85 1.79 1.68 0.93 1.03 0.90 0.91

95% CI

p

[1.12, 1.87] 0.005 [1.44, 2.37] <0.001 [1.00, 3.23] 0.051 [1.14, 2.47] 0.008 [0.76, 1.14] 0.511 [0.82, 1.29] 0.817 [0.69, 1.17] 0.431 [0.55, 1.49] 0.702

Primary language, reference Python Go 0.36 [0.19, 0.69] 0.002 Java 0.33 [0.15, 0.74] 0.007 JavaScript 0.78 [0.39, 1.54] 0.471 Ruby 1.16 [0.51, 2.61] 0.725 TypeScript 0.45 [0.21, 0.96] 0.038 Other 0.30 [0.18, 0.52] <0.001

spectively (p = 4.7 × 10−7 , Cliff’s δ = +0.28, 95% CI [+0.18, +0.39]). This small difference predates cooldown adoption. The largest absolute Spearman correlation observed among the repository attributes was 0.47. The maximum VIF in the main model was 2.1, below the screening criterion of 5. These diagnostics provided no indication that collinearity substantially destabilized the coefficient estimates. The exploratory multivariable model estimates

20

Hidetake Tanaka et al.

in Table 9 suggest positive associations of adoption with the number of contributors, bot pull request count, and the presence of a SECURITY.md file, with adjusted odds ratios of 1.45, 1.85, and 1.68. The estimate for organization ownership is borderline (OR 1.79, p = 0.051), while stars, repository age, dependencies, and auto-merge show no clear evidence of adjusted associations. Relative to Python, the estimates also suggest lower adoption odds for Go (OR 0.36), Java (OR 0.33), and TypeScript (OR 0.45), but no clear differences for JavaScript or Ruby. These exploratory observational associations do not establish causality. Two sensitivity models add merge time and the pre-GA edit rate separately because each is defined only for a subset. The merge-time model covers 1,158 repositories and finds no clear association for the added variable (OR 0.81, 95% CI [0.65, 1.02]). The pre-GA edit-rate model covers 1,289 repositories, including 115 adopters, and likewise finds no adjusted association (OR 1.15, 95% CI [0.94, 1.40]). In both models, the main associations and language results remain stable. Thus, merge time differs significantly in the univariable comparison after BH adjustment but has no clear association after accounting for the other explanatory variables. RQ2 Summary Answering RQ2, the exploratory adjusted estimates suggest associations of adoption with the number of contributors, bot pull request count, and SECURITY.md presence, as well as lower adoption odds for Go, Java, and TypeScript repositories than for Python repositories.

4.4 RQ3: Configuration Choices In RQ3, we analyze cooldown configuration values observed at the cutoff among the 135 early adopter repositories, rather than treating the main snapshot as the initial configuration at the adoption event. The configuration distribution is based on 251 ecosystems within those repositories that still hold cooldown at the cutoff. We examine post-adoption changes separately only where the git history lets us observe transitions from the initial setting to later settings. We organize the results into three parts: the set rate and value distribution of each key, value changes after adoption, and the comparison across the cooldowns within the same repository. Table 10 reports the set rate, median, most common value, and maximum of each cooldown key observed at the cutoff over the 251 ecosystems within repositories that hold cooldown. default-days is set in 97.2% of them, while each of the three SemVer-level keys stays below 10%. The include and exclude lists appear in only 1.2% and 2.0%. Most thus rely on default-days alone at the cutoff. They maintain minimal customization, keeping a single default-days value rather than tuning the delay at each SemVer level or for individual packages. The remaining 7 that do not set default-days each carry a delay in a SemVer-level key, so all 251 of them set a delay in at least one key. None of them is an ecosystem that carries no delay and resolves to zero days.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

21

Table 10 Set rate, median, most common value, and maximum of each cooldown key over the 251 ecosystems within repositories with a cooldown at the observation cutoff. Key default-days semver-major-days semver-minor-days semver-patch-days include exclude

Set rate

Median

Mode

Max

97.2% (244) 9.2% (23) 8.0% (20) 7.6% (19) 1.2% (3) 2.0% (5)

7 21 7 3 -

7 30 7 3 -

42 90 30 90 -

We first look at the distribution of the default-days value. Among the 244 ecosystems within repositories that set it, the most common value is 7 days, which occurs in 157 of them, or 64.3%. The values range from 2 to 42 days but concentrate strongly on 7 days. Broken down by ecosystem, all 10 ecosystems in which at least five repositories set the value have a median of 7 days. The include list is set in 3 ecosystems across 2 repositories, all specifying the wildcard *. All 3 were present when cooldown was adopted. The exclude list is set in 5 ecosystems across 5 repositories. One was present at adoption, and the other 4 were added later. In these few cases, the pull requests and commits that introduced each exclude entry suggest three motivations. The first is the exclusion of packages maintained by the same organization, which carry lower supply chain risk than thirdparty dependencies. The second is the exclusion of security-critical libraries, such as cryptographic packages, for which rapid patch adoption is needed. The third is the exclusion of an action that was blocking continuous integration at the time the exclude entry was introduced. Changes to the settings after adoption are few. Table 11 is the history-based part of RQ3 and reports the counts by direction. default-days is raised 6 times and newly added 4 times, with no decrease or removal, and the 6 increases all move it from 3 or 4 days to 7. The three SemVer-level keys change only by removal, 6, 5, and 5 times. Each of these keys was set in the commit that adopted cooldown and was removed only at a later commit. The observed post-adoption changes fold the separate delays for each update type, all set at adoption, into a single default-days, or raise that default-days toward 7 days. The include and exclude lists are each added 4 times, with no removal while cooldown remains present. The 4 include additions all set the wildcard * in 4 ecosystems across 3 repositories owned by the Homebrew organization. The corresponding updates entries were later deleted and reintroduced without include, so these are not the 3 include settings observed at the cutoff. At the cutoff, 90 of the adopter repositories hold two or more cooldowns. Comparing the values across the cooldowns of each repository, the values set in both settings differ in only 3 repositories. default-days differs in 2 of them, and the semver-major-days, semver-minor-days, and semver-patch-days keys differ in 1. The 3 repositories with differing values illustrate context-specific policies. Two vary default-days across ecosystems. One gives Go dependencies used for vulnerability data a shorter delay than docker and github-actions, while the other gives its

22

Hidetake Tanaka et al.

Table 11 Direction of configuration changes per ecosystem within a repository while the cooldown feature stays enabled. Key default-days semver-major-days semver-minor-days semver-patch-days include exclude

Increased Decreased Added Removed 6 0 0 0 -

0 0 0 0 -

4 0 0 0 4 4

0 6 5 5 0 0

large npm dependencies a longer delay than Go and github-actions. The remaining repository differentiates two settings within npm, using shorter SemVer delays for production and test dependencies and longer delays for the remaining development dependencies. These cases show that the rare departures from a common repositorywide value reflect update priorities rather than arbitrary variation. RQ3 Summary Answering RQ3, most observed cooldown configurations use only a simple default-days setting, commonly 7 days. Post-adoption changes were rare and generally simplified separate delays into a single delay or moved default-days to 7 days.

5 Discussion 5.1 Interpretation of Results Early adopters use cooldown more as a simple repository-level delay than as a highly customized scheduling mechanism, and security linters mediate many adoption decisions. This interpretation requires caution because 43 Unknown events account for 31.9% of the 135 first-time adoptions. The claim that security motivations dominate therefore applies most directly to the 92 events with identified motivations. Even if every Unknown event were non-security motivated, however, security would still be present in 83 events, or 61.5% of all adoptions, so it remains a major adoption driver. The rising adoption curve and absence of repository-level abandonment are consistent with an early diffusion phase in which some adopters continue to find value in the feature. The acceleration near the cutoff may partly reflect reactions to the axios incident, whose contribution this study does not isolate. The observed removals suggest that maintainers may temporarily disable cooldown when it is unsupported or prevents Dependabot from running, rather than because they reject the feature itself.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

23

5.2 Implications for Tool Designers The preference for a simple default-days value suggests that low configuration burden matters. The common 7-day value offers an empirical reference point among early adopters, not evidence of an optimal delay. Linters and configuration tools can support adoption by checking ecosystem support, suggesting simple candidate settings, and reserving fine-grained controls for dependencies with clear priorities. Unsupported settings should also fail clearly without stopping Dependabot as a whole, so maintainers can distinguish an invalid cooldown from a general service failure. After our observation window, GitHub made a three-day cooldown the default for Dependabot version updates without requiring explicit configuration, while leaving security updates immediate and allowing repositories to customize or opt out of the default (GitHub, 2026). This change is consistent with our implication that a useful baseline should impose little configuration burden. However, the three-day platform default differs from the seven-day value most common among early adopters in our data, and our study does not establish either period as optimal. Future studies should distinguish acceptance of the default, explicit customization, and opt-out behavior when evaluating cooldown use.

5.3 Implications for Open-Source Software Maintainers RQ1 identified three adoption events introduced through shared-configuration tracking (Table 5). It also identified removal cases in which unsupported cooldown settings prevented Dependabot from running (Section 4.2). These findings suggest that projects inheriting cooldown through a shared configuration should verify ecosystem support and ensure that the inherited policy fits their update workflow. The RQ2 multivariable model shows a positive association between the number of Dependabot pull requests and cooldown adoption (OR 1.85, Table 9). Repositories that receive many dependency update pull requests are therefore plausible candidates for evaluating cooldown. In RQ3, exclude appeared in only five ecosystems across five repositories (Table 10). The cases examined in Section 4.4 involved packages maintained by the same organization, dependencies requiring rapid security updates, and dependencies needed to keep continuous integration working. These observations suggest that maintainers should identify dependencies that must not wait behind the general delay, while ordinary third-party dependencies can retain a detection window (Chinthanet et al, 2021; Côgo et al, 2021).

5.4 Threats to Validity 5.4.1 Construct Validity Our abandonment measure (RQ1) counts only cases in which the cooldown setting is removed while the Dependabot configuration file remains in place. This is

24

Hidetake Tanaka et al.

a clear signal of cooldown rejection while Dependabot itself continues to be used. Cases in which the Dependabot configuration file is deleted entirely are excluded, because such deletions indicate discontinuation of Dependabot rather than rejection of cooldown specifically, even though cooldown dissatisfaction may be one of several reasons behind them. The abandonment rate should therefore be interpreted as a lower bound on cooldown loss. The presence of a cooldown setting in the Dependabot configuration file does not necessarily mean that the feature is actively used in practice. A configuration may have been added by a template or a project generator without an explicit decision by the maintainer to enable the cooldown. To partially mitigate this threat, we examine the git history of configuration files and inspect adoption motivations for all 135 first-time adoption events using available commit messages and related Issues and Pull Requests. The exclude list within cooldown removes specified dependencies from the cooldown so that they are updated immediately. A repository counted as an “adopter” may therefore apply little real delay to some of its dependencies. We report the usage of exclude lists separately to characterize this nuance. Our auto-merge measurement for RQ2 captures only pull requests on which auto-merge was enabled at the pull-request level through GitHub’s native auto-merge feature. It does not detect Dependabot pull requests that are merged automatically by third-party mechanisms such as GitHub Actions workflows or GitHub Apps (e.g., Mergify). He et al (2023) report that 8.17% of Dependabot pull requests are merged by third-party auto-merge implementations. Pull requests merged solely through these third-party paths are recorded as having auto-merge disabled in our data, so our auto-merge enablement rate should be interpreted as a lower bound on the prevalence of automated Dependabot pull request merging. For multiplicity, we treat the nine RQ2 univariable comparisons as one family because they are parallel tests of adopter and non-adopter differences, and we control the false discovery rate within this family using the Benjamini–Hochberg procedure. We do not adjust the multivariable regression coefficients for multiplicity because the model is intended to estimate mutually adjusted associations exploratorily rather than to conduct simultaneous confirmatory tests of individual coefficients. Its p-values and 95% confidence intervals therefore provide no simultaneous error-rate control, so we interpret coefficient-level patterns cautiously and do not base conclusions on borderline results alone. The RQ2 multivariable logistic regression reports associations from cross-sectional observational data and does not establish causality. The Dependabot pull request count and merge time are measured over the full observation window, so adopter measurements may be affected by cooldown adoption itself. These metrics therefore do not purely represent pre-adoption repository characteristics, and the observed group differences should not be interpreted causally. The sensitivity analyses have a further limitation. The analyses that add merge time and the pre-GA edit rate are restricted to repositories with a merged bot pull request and to repositories that had the configuration file at GA, so they narrow the population rather than drawing a random subset. When we compare these sensitivity results with the main model, we therefore account for the difference in the covered set of repositories.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

25

Our dependency count for RQ2 has several limitations. The dependency graph does not separate direct from transitive dependencies, and we count them together. The graph also expands to different depths across ecosystems. For npm and Go it reaches transitive dependencies, whereas for many ecosystems it returns a list close to the direct dependencies, so the count depends on the ecosystem. For some ecosystems the graph returns no packages at all, reporting none for Docker and capturing few dependencies for Gradle and Maven, so the counts for these ecosystems are near zero. The count therefore approximates the dependency update burden rather than giving an exact dependency count. Because the count is ecosystem-dependent in this way, comparing the repository total between adopters and non-adopters could be confounded by an imbalance in ecosystem composition. However, the comparison of adoption rates across ecosystems shows no evidence of a difference even after accounting for within-repository correlation, so any large distortion from ecosystem composition appears unlikely. 5.4.2 Internal Validity Our repository list is obtained from Gitstar Ranking at a single point in time, and repositories whose star counts or rankings change between the scrape of Gitstar and the calls to the GitHub REST API may be captured inconsistently. We record the collection timestamp to make the snapshot reproducible. For RQ1’s qualitative analysis, not all adopter repositories have Issues or Pull Requests that document the rationale for enabling the cooldown, which may bias the sample toward projects with more transparent development processes. 5.4.3 External Validity Our study is limited to public repositories hosted on GitHub. Dependabot is a GitHubnative service and does not operate on other platforms such as GitLab or Bitbucket, so our findings describe the Dependabot user population but cannot be generalized to dependency management practices on other platforms. We also restrict scope to Dependabot. Renovate and cooldown options built into package managers (npm, pnpm, Yarn, Bun, uv) are not analyzed here, and adoption patterns observed for Dependabot may not transfer to those alternatives. Because Dependabot’s cooldown feature was introduced in July 2025, our observation window spans approximately ten months (2025-07-01 to 2026-04-30), which limits the temporal scope of RQ3 and means that abandonments occurring after the window are not captured in our RQ1 analysis of observed cooldown removals and abandonment. Finally, we draw our population from the 10,000 repositories with the most stars listed in Gitstar Ranking, so our results may not generalize to smaller or less popular projects, private repositories, or enterprise repositories, whose security practices and tooling choices may differ from those in the community of popular open-source projects (Kalliamvakou et al, 2014). Our findings should therefore be interpreted as early adoption patterns for Dependabot cooldown in popular and visible open-source

26

Hidetake Tanaka et al.

GitHub repositories, rather than as representative evidence for open-source projects in general.

6 Conclusion This paper provides a systematic characterization of early Dependabot cooldown adoption. Through an exploratory study of popular public open-source repositories on GitHub, we examine adoption and abandonment, adopter characteristics, and configuration choices. Together, these analyses establish an empirical baseline for understanding how cooldown is used before its effectiveness is evaluated. Adoption remains limited but is growing, with 135 adopters among 1,462 repositories and no repository-level abandonment during the observation window. Security concerns dominate among events with identified motivations, while linter warnings also trigger adoption. After adjustment, adoption remains associated with more contributors, more bot pull requests, and a SECURITY.md file. Most configurations apply one general delay, commonly 7 days. Early adopters therefore use cooldown primarily as a low-configuration safeguard rather than a highly customized scheduling policy. These findings suggest that tool designers should favor simple defaults, validate ecosystem support, and report invalid configurations clearly. Repositories receiving many dependency update pull requests are plausible candidates for evaluating cooldown, but the common 7-day setting should not be interpreted as optimal. Our study provides foundational evidence about early adoption and use, not evidence that cooldown prevents supply chain incidents. Our evidence is limited to popular public GitHub repositories and an observation window of approximately ten months. Future work should compare configured delays with attack and detection timelines, track explicit customization and opt-out behavior after Dependabot’s three-day default, and extend the analysis to Renovate and package-manager cooldowns. These studies should ultimately determine which delay periods balance security benefits against the cost of postponing legitimate updates.

Declarations Funding This work was supported by JST BOOST, Japan Grant Number JPMJBS2423, JSPS KAKENHI Nos. JP24K14895 and JP26K21197.

Competing interests The authors have no relevant financial or non-financial interests to disclose.

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

27

Ethics approval Not applicable. This study analyzes publicly available data from open-source software repositories and does not involve direct interaction with human participants.

Informed consent Not applicable.

Data availability The replication package is available at https://doi.org/10.5281/zenodo.21331117.

References Alfadel M, Costa DE, Shihab E, Mkhallalati M (2021) On the use of dependabot security pull requests. In: 18th IEEE/ACM International Conference on Mining Software Repositories, MSR 2021, Madrid, Spain, May 17-19, 2021, IEEE, pp 254–265, DOI 10.1109/MSR52588.2021.00037 Benjamini Y, Hochberg Y (1995) Controlling the false discovery rate: A practical and powerful approach to multiple testing. Journal of the Royal Statistical Society: Series B (Methodological) 57(1):289–300, DOI 10.1111/j.2517-6161. 1995.tb02031.x, https://academic.oup.com/jrsssb/article-pdf/57/1/ 289/49173396/jrsssb_57_1_289.pdf Bogart C, Kästner C, Herbsleb JD, Thung F (2016) How to break an API: cost negotiation and community values in three software ecosystems. In: Proceedings of the 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, FSE 2016, Seattle, WA, USA, November 13-18, 2016, ACM, pp 109–120, DOI 10.1145/2950290.2950325 Breslow NE, Clayton DG (1993) Approximate inference in generalized linear mixed models. Journal of the American Statistical Association 88(421):9–25, DOI 10. 1080/01621459.1993.10594284 Cheong M, Kula RG, Treude C (2024) Ethical considerations toward protestware. IEEE Software 41:67–75, DOI 10.1109/MS.2023.3344778 Chinthanet B, Kula RG, McIntosh S, Ishio T, Ihara A, Matsumoto K (2021) Lags in the release, adoption, and propagation of npm vulnerability fixes. Empir Softw Eng 26(3):47, DOI 10.1007/s10664-021-09951-x Cliff N (1993) Dominance statistics: Ordinal analyses to answer ordinal questions. Psychological Bulletin 114:494–509, DOI 10.1037/0033-2909.114.3.494 Côgo FR, Oliva GA, Hassan AE (2021) An empirical study of dependency downgrades in the npm ecosystem. IEEE Transactions on Software Engineering 47(11):2457–2470, DOI 10.1109/TSE.2019.2952130

28

Hidetake Tanaka et al.

Cohen J (1960) A coefficient of agreement for nominal scales. Educational and Psychological Measurement 20(1):37–46, DOI 10.1177/001316446002000104, https://doi.org/10.1177/001316446002000104 Cohen J (1988) Statistical Power Analysis for the Behavioral Sciences, 2nd edn. Lawrence Erlbaum Associates Cox J, Bouwers E, van Eekelen M, Visser J (2015) Measuring dependency freshness in software systems. In: Proceedings of the 37th International Conference on Software Engineering - Volume 2, IEEE Press, ICSE ’15, p 109âĂŞ118 Cramér H (1946) Mathematical Methods of Statistics, Princeton Mathematical Series, vol 9. Princeton University Press Cruzes DS, Dybå T (2011) Recommended steps for thematic synthesis in software engineering. In: 2011 International Symposium on Empirical Software Engineering and Measurement, ESEM 2011, Banff, AB, Canada, September 22-23, 2011, IEEE, pp 275–284, DOI 10.1109/ESEM.2011.36 Decan A, Mens T (2021) What do package dependencies tell us about semantic versioning? IEEE Transactions on Software Engineering 47:1226–1240, DOI 10.1109/TSE.2019.2918315 Decan A, Mens T, Grosjean P (2019) An empirical comparison of dependency network evolution in seven software packaging ecosystems. Empirical Software Engineering 24:381–416, DOI 10.1007/s10664-017-9589-y Dietrich J, Pearce DJ, Stringer J, Tahir A, Blincoe K (2019) Dependency versioning in the wild. In: Proceedings of the 16th International Conference on Mining Software Repositories, MSR 2019, Montreal, QC, Canada, May 26-27, 2019, IEEE, pp 349– 359, DOI 10.1109/MSR.2019.00061 Dormann CF, Elith J, Bacher S, Buchmann C, Carl G, Carré G, García Márquez JR, Gruber B, Lafourcade B, Leitão PJ, Münkemüller T, McClean C, Osborne PE, Reineking B, Schröder B, Skidmore AK, Zurell D, Lautenbach S (2013) Collinearity: A review of methods to deal with it and a simulation study evaluating their performance. Ecography 36(1):27–46, DOI 10.1111/j.1600-0587.2012.07348.x Duan R, Alrawi O, Kasturi RP, Elder R, Saltaformaggio B, Lee W (2021) Towards measuring supply chain attacks on package managers for interpreted languages. In: 28th Annual Network and Distributed System Security Symposium, NDSS 2021, virtually, February 21-25, 2021, The Internet Society, URL https: //www.ndss-symposium.org/ndss-paper/towards-measuring-supplychain-attacks-on-package-managers-for-interpreted-languages/ Erlenhov L, de Oliveira Neto FG, Leitner P (2022) Dependency management bots in open-source systems - prevalence and adoption. PeerJ Comput Sci 8:e849, DOI 10.7717/peerj-cs.849 Fisher RA (1925) Statistical Methods for Research Workers. Oliver and Boyd GitHub (2026) Dependabot version updates introduce default package cooldown. https://github.blog/changelog/2026-07-14-dependabot-versionupdates-introduce-default-package-cooldown/, accessed: 2026-08-20 GitHub (n.d.) Dependabot options reference. https://docs.github.com/ en/code-security/reference/supply-chain-security/dependabotoptions-reference, accessed: 2026-05-27

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

29

Gonzalez D, Zimmermann T, Godefroid P, Schäfer M (2021) Anomalicious: Automated detection of anomalous and potentially malicious commits on github. In: 43rd IEEE/ACM International Conference on Software Engineering: Software Engineering in Practice, ICSE (SEIP) 2021, Madrid, Spain, May 25-28, 2021, IEEE, pp 258–267, DOI 10.1109/ICSE-SEIP52600.2021.00035 Gonzalez-Barahona JM, Sherwood P, Robles G, Izquierdo D (2017) Technical lag in software compilations: Measuring how outdated a software deployment is. In: Balaguer F, Di Cosmo R, Garrido A, Kon F, Robles G, Zacchiroli S (eds) Open Source Systems: Towards Robust Practices, Springer International Publishing, Cham, pp 182–192 Guo W, Xu Z, Liu C, Huang C, Fang Y, Liu Y (2023) An empirical study of malicious code in pypi ecosystem. In: 38th IEEE/ACM International Conference on Automated Software Engineering, ASE 2023, Luxembourg, September 11-15, 2023, IEEE, pp 166–177, DOI 10.1109/ASE56229.2023.00135 Hanley JA, McNeil BJ (1982) The meaning and use of the area under a receiver operating characteristic (ROC) curve. Radiology 143(1):29–36, DOI 10.1148/ radiology.143.1.7063747 He H, Vasilescu B, Kästner C (2025) Pinning is futile: You need more than local dependency versioning to defend against supply chain attacks. Proc ACM Softw Eng 2(FSE):266–289, DOI 10.1145/3715728 He R, He H, Zhang Y, Zhou M (2023) Automating dependency updates in practice: An exploratory study on github dependabot. IEEE Transactions on Software Engineering 49(8):4004–4022, DOI 10.1109/TSE.2023.3278129 Jafari AJ, Costa DE, Abdalkareem R, Shihab E, Tsantalis N (2022) Dependency smells in javascript projects. IEEE Transactions on Software Engineering 48(10):3790–3807, DOI 10.1109/TSE.2021.3106247 James G, Witten D, Hastie T, Tibshirani R (2021) An Introduction to Statistical Learning: With Applications in R, 2nd edn. Springer, New York, DOI 10.1007/ 978-1-0716-1418-1 Kalliamvakou E, Gousios G, Blincoe K, Singer L, Germán DM, Damian DE (2014) The promises and perils of mining github. In: 11th Working Conference on Mining Software Repositories, MSR 2014, Hyderabad, India, May 31 - June 1, 2014, ACM, pp 92–101, DOI 10.1145/2597073.2597074 Krippendorff K (2019) Content Analysis: An Introduction to Its Methodology, 4th edn. SAGE Publications, DOI 10.4135/9781071878781 Kula RG, Treude C (2022) In war and peace: the impact of world politics on software ecosystems. In: Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2022, Singapore, November 14-18, 2022, ACM, pp 1600–1604, DOI 10.1145/3540250.3560882 Kula RG, Germán DM, Ouni A, Ishio T, Inoue K (2018) Do developers update their library dependencies? - an empirical study on the impact of security advisories on library migration. Empir Softw Eng 23(1):384–417, DOI 10.1007/s10664-0179521-5 Ladisa P, Plate H, Martinez M, Barais O (2023) Sok: Taxonomy of attacks on opensource software supply chains. In: 44th IEEE Symposium on Security and Privacy,

30

Hidetake Tanaka et al.

SP 2023, San Francisco, CA, USA, May 21-25, 2023, IEEE, pp 1509–1526, DOI 10.1109/SP46215.2023.10179304 Landis JR, Koch GG (1977) The measurement of observer agreement for categorical data. Biometrics 33(1):159–174, URL http://www.jstor.org/stable/ 2529310 Liang KY, Zeger SL (1986) Longitudinal data analysis using generalized linear models. Biometrika 73(1):13–22, DOI 10.1093/biomet/73.1.13 Lins M, Rass S, Mayrhofer R (2026) Software supply chain security: Can we beat the kill-chain? A case study on the XZ backdoor. In: Secure IT Systems - 30th Nordic Conference, NordSec 2025, Proceedings, Springer, pp 204–223, DOI 10. 1007/978-3-032-14782-0\_12 Mann HB, Whitney DR (1947) On a Test of Whether one of Two Random Variables is Stochastically Larger than the Other. The Annals of Mathematical Statistics 18(1):50 – 60, DOI 10.1214/aoms/1177730491 McFadden D (1974) Conditional logit analysis of qualitative choice behavior. In: Zarembka P (ed) Frontiers in Econometrics, Academic Press, New York, pp 105– 142 Mirhosseini S, Parnin C (2017) Can automated pull requests encourage software developers to upgrade out-of-date dependencies? In: Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering, ASE 2017, Urbana, IL, USA, October 30 - November 03, 2017, IEEE Computer Society, pp 84–94, DOI 10.1109/ASE.2017.8115621 O’Brien RM (2007) A caution regarding rules of thumb for variance inflation factors. Quality & Quantity 41(5):673–690, DOI 10.1007/s11135-006-9018-6 Ochoa L, Degueule T, Falleri JR, Vinju J (2022) Breaking bad? semantic versioning and impact of breaking changes in maven central: An external and differentiated replication study. Empirical Softw Engg 27(3), DOI 10.1007/s10664-021-10052y, URL https://doi.org/10.1007/s10664-021-10052-y Ohm M, Plate H, Sykosch A, Meier M (2020) Backstabber’s knife collection: A review of open source software supply chain attacks. In: Detection of Intrusions and Malware, and Vulnerability Assessment - 17th International Conference, DIMVA 2020, Lisbon, Portugal, June 24-26, 2020, Proceedings, Springer, Lecture Notes in Computer Science, pp 23–43, DOI 10.1007/978-3-030-52683-2\_2 Pearson K (1900) X. on the criterion that a given system of deviations from the probable in the case of a correlated system of variables is such that it can be reasonably supposed to have arisen from random sampling. The London, Edinburgh, and Dublin Philosophical Magazine and Journal of Science 50(302):157–175, DOI 10. 1080/14786440009463897, https://doi.org/10.1080/14786440009463897 Przymus P, Durieux T (2025) Wolves in the repository: A software engineering analysis of the XZ utils supply chain attack. In: 22nd IEEE/ACM International Conference on Mining Software Repositories, MSR 2025, Ottawa, ON, Canada, April 28-29, 2025, IEEE, pp 91–102, DOI 10.1109/MSR66628.2025.00026 Raemaekers S, van Deursen A, Visser J (2017) Semantic versioning and impact of breaking changes in the maven repository. Journal of Systems and Software 129:140–158, DOI 10.1016/j.jss.2016.04.008

An Exploratory Study of Dependabot Cooldown Adoption in Open-Source GitHub Projects

31

Rebatchi H, Bissyandé TF, Moha N (2024) Dependabot and security pull requests: large empirical study. Empirical Software Engineering 29(5):128, DOI 10.1007/ s10664-024-10523-y Rombaut B, Côgo FR, Adams B, Hassan AE (2023) There’s no such thing as a free lunch: Lessons learned from exploring the overhead introduced by the greenkeeper dependency bot in npm. ACM Transactions on Software Engineering and Methodology 32(1):1–40, DOI 10.1145/3522587 Saayman J (2026) Post mortem: axios npm supply chain compromise. https:// github.com/axios/axios/issues/10636, accessed: 2026-07-06 Sejfia A, Schäfer M (2022) Practical automated detection of malicious npm packages. In: 44th IEEE/ACM International Conference on Software Engineering, ICSE 2022, Pittsburgh, PA, USA, May 25-27, 2022, ACM, pp 1681–1692, DOI 10.1145/3510003.3510104 Sonatype (2026) 2026 state of the software supply chain report. https://www. sonatype.com/state-of-the-software-supply-chain/introduction, accessed: 2026-07-07 Torchiano M (n.d.) Cliff’s delta effect size for ordinal variables. https://search. r-project.org/CRAN/refmans/effsize/html/cliff.delta.html, documentation for the cliff.delta function in effsize version 0.8.1. Accessed: 2026-09-04 Vu D, Pashchenko I, Massacci F, Plate H, Sabetta A (2020) Typosquatting and combosquatting attacks on the python ecosystem. In: IEEE European Symposium on Security and Privacy Workshops, EuroS&P Workshops 2020, Genoa, Italy, September 7-11, 2020, IEEE, pp 509–514, DOI 10.1109/EUROSPW51379.2020. 00074 Vu D, Massacci F, Pashchenko I, Plate H, Sabetta A (2021) Lastpymile: identifying the discrepancy between sources and packages. In: Proceedings of the 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, Athens, Greece, August 23-28, 2021, ACM, pp 780–792, DOI 10.1145/3468264.3468592 Wessel M, de Souza BM, Steinmacher I, Wiese IS, Polato I, Chaves AP, Gerosa MA (2018) The power of bots: Characterizing and understanding bots in OSS projects. Proceedings of the ACM on Human-Computer Interaction 2(CSCW):182:1– 182:19, DOI 10.1145/3274451 Wessel M, Wiese IS, Steinmacher I, Gerosa MA (2021) Don’t disturb me: Challenges of interacting with software bots on open source software projects. Proceedings of the ACM on Human-Computer Interaction 5(CSCW2):1–21, DOI 10.1145/3476042 Williams L, Benedetti G, Hamer S, Paramitha R, Rahman I, Tamanna M, Tystahl G, Zahan N, Morrison P, Acar Y, Cukier M, Kästner C, Kapravelos A, Wermke D, Enck W (2025) Research directions in software supply chain security. ACM Trans Softw Eng Methodol 34(5), DOI 10.1145/3714464, URL https://doi.org/10. 1145/3714464 Wittern E, Suter P, Rajagopalan S (2016) A look at the dynamics of the javascript package ecosystem. In: Proceedings of the 13th International Conference on Mining Software Repositories, MSR 2016, Austin, TX, USA, May 14-22, 2016, ACM, pp 351–361, DOI 10.1145/2901739.2901743

32

Hidetake Tanaka et al.

Zahan N, Zimmermann T, Godefroid P, Murphy B, Maddila C, Williams L (2022) What are weak links in the npm supply chain? In: Proceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, Association for Computing Machinery, New York, NY, USA, ICSE-SEIP ’22, p 331âĂŞ340, DOI 10.1145/3510457.3513044, URL https://doi.org/ 10.1145/3510457.3513044 Zerouali A, Mens T, Gonzalez-Barahona J, Decan A, Constantinou E, Robles G (2019) A formal framework for measuring technical lag in component repositories âĂŤ and its application to npm. Journal of Software: Evolution and Process 31(8):e2157, DOI https://doi.org/10.1002/smr.2157, URL https:// onlinelibrary.wiley.com/doi/abs/10.1002/smr.2157, e2157 smr.2157, https://onlinelibrary.wiley.com/doi/pdf/10.1002/smr.2157 Zimmermann M, Staicu C, Tenny C, Pradel M (2019) Small world with high risks: A study of security threats in the npm ecosystem. In: 28th USENIX Security Symposium, USENIX Security 2019, Santa Clara, CA, USA, August 1416, 2019, USENIX Association, pp 995–1010, URL https://www.usenix.org/ conference/usenixsecurity19/presentation/zimmerman