惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
阮一峰的网络日志
阮一峰的网络日志
A
About on SuperTechFans
大猫的无限游戏
大猫的无限游戏
Engineering at Meta
Engineering at Meta
V
Visual Studio Blog
Martin Fowler
Martin Fowler
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 叶小钗
I
InfoQ
B
Blog RSS Feed
aimingoo的专栏
aimingoo的专栏
Y
Y Combinator Blog
Blog — PlanetScale
Blog — PlanetScale
IT之家
IT之家
P
Proofpoint News Feed
WordPress大学
WordPress大学
小众软件
小众软件
B
Blog
MongoDB | Blog
MongoDB | Blog
人人都是产品经理
人人都是产品经理
量子位
Hugging Face - Blog
Hugging Face - Blog
月光博客
月光博客

The latest security news for developers - The GitHub Blog

OpenClaw went viral. Meet the maintainers building and securing it. What 50 open source projects taught us about security in the AI era How we took malware advisories beyond npm Tame Dependabot: Group your updates, slow the cadence, keep security fast Disrupting supply chain attacks on npm and GitHub Actions Next chapter: Restructuring GitHub's bug bounty program How GitHub gave every repository a durable owner How GitHub used secret scanning to reach inbox zero 6 security settings every GitHub maintainer should enable this week Inside the Advisory Database and what happens when vulnerability volume breaks records Making secret scanning more trustworthy: Reducing false positives at scale Investigation update: GitHub Enterprise Server signing key rotation Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program Securing the git push pipeline: Responding to a critical remote code execution vulnerability Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game How exposed is your code? Find out in minutes—for free Securing the open source supply chain across GitHub A year of open source vulnerability trends: CVEs, advisories, and malware GitHub expands application security coverage with AI‑powered detections Investing in the people shaping open source and securing the future together How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework
The case for a cooldown: Why Dependabot now waits before ...
Carlin Cherry · 2026-07-24 · via The latest security news for developers - The GitHub Blog

In September 2025, an attacker phished the credentials of a single npm maintainer and published booby-trapped versions of chalk, debug, and around a dozen other packages that are together downloaded more than 2 billion times a week. The code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The poisoned versions were live for roughly two hours before the community caught them and npm pulled them.

Two hours is a fast response. However, it is also more than enough time for an automated update tool to see the new version, open a pull request, and put it in front of your team, because version update tooling is built to grab the newest release the moment it lands.

That pattern sits behind a growing share of supply chain attacks. The malicious code rides in on a brand-new release, is published to a public registry, and gets pulled into build pipelines within minutes, before a human or a scanner has even looked at it.

A cooldown changes that math. Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests.

For non-security version bumps, Dependabot now waits at least three days after a release is published before opening a pull request. The cooldown configuration option in the dependabot.yml still controls the behavior, though, so you can choose a different cooldown parameter that fits your project.

Case studies and GitHub Advisory Database data

When attackers compromise a popular package, the poisoned version tends to have a short lifespan. It gets published, spreads through whatever installs it, and gets caught, usually within hours. The previous example was live for only two hours. Other widely used packages have followed the same arc, with compromised builds of Solana web3.js, Axios, and ua-parser-js each caught within a few hours of publication.

More generally, GitHub sees this pattern directly through the GitHub Advisory Database, which catalogs open source security advisories across ecosystems. In the year ending May 2026, the database published more than 6,500 npm malware advisories, up from roughly 6,200 the year before, which adds up to approximately 18 newly cataloged malicious npm packages every day. A cooldown keeps you out of that opening window and lets a release accumulate some scrutiny before it reaches you.

Why three days

Published malware targeting popular packages tends to get caught fast. A review of 21 widely reported supply chain incidents between 2018 and 2026 found the same pattern: malicious versions of axios, Solana web3.js, ua-parser-js, and Ledger Connect Kit were each pulled within hours of publication, and a cooldown could have filtered out the majority of these short-lived publishes before anyone installed them.

Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary.

Other community members have also landed on a three-day cooldown (though some go even longer), so this default behavior keeps Dependabot consistent as developers move between tools.

You can always set a longer or shorter window with Dependabot’s cooldown configuration option.

Defense in depth

A cooldown is built for a specific pattern: a malicious version that ships, spreads, and gets caught quickly. It does little against attacks that play a longer game, including backdoors planted in releases and left dormant, maintainer sabotage, or a compromised build system. The point of the default is to remove a common and time-sensitive path, not to stand in for the rest of your defenses.

Because a cooldown only addresses the fast-moving case, it should be one layer among several. Some additional steps to take include pinning dependencies with lockfiles, disabling install scripts in CI where you can, scoping the tokens in your build pipelines, and reviewing updates before they merge.

If you’d like to customize your delay for highly trusted internal packages versus public registries, check out the documentation on configuring Dependabot. Or see the Dependabot configuration options reference for the full set of cooldown parameters.

Where we go from here

This is one step among several we are taking to harden the software supply chain for everyone who builds on GitHub. It’s on by default, so you don’t have to change anything to activate it. You can also tune it to fit your workflow.

Tell us how it performs in the Dependabot community discussions.

Written by

Carlin Cherry

Carlin is a Product Manager at GitHub working in GitHub Advanced Security, with a focus on Dependabot. Her background in software engineering and data science informs her data-driven approach to product management. She lives in Washington with her partner and their dog, Cookie, and spends her free time cycling and playing competitive board games.

Related posts

How GitHub gave every repository a durable owner

GitHub had over 14,000 repositories. Fewer than half had clear ownership. Here’s how we gave every active repository a validated owner in under 45 days, archived the rest, and made ownership the foundation for everything that followed.

Explore more from GitHub

Docs

Docs

Everything you need to master GitHub, all in one place.

Go to Docs

GitHub

GitHub

Build what’s next on GitHub, the place for anyone from anywhere to build anything.

Start building

Customer stories

Customer stories

Meet the companies and engineering teams that build with GitHub.

Learn more

GitHub Universe 2026

GitHub Universe 2026

Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world’s code.

Register now