A newly published version waits before the updater proposes it
An attacker who takes a maintainer account publishes within seconds, and the registry serves it just as fast. What ends those incidents is other people looking: the malicious versions in the npm compromises of September 2025 were found and pulled within hours. Renovate waits zero days until somebody sets a delay, so an updater on that side opens its pull request inside the window, and a project that merges its bumps promptly installs the bad version before anybody has looked at it. Dependabot now applies a delay of its own, which moves the question from whether the window is open to who decided it. A written value survives the day the platform changes its default, and it is a decision a reader can audit, where a default is one nobody made. The delay costs the project nothing it wanted, because it holds back a routine version bump and not a fix for a known vulnerability.
Observable check
the repository's dependency updater configuration delays a newly published version before proposing it, through a cooldown block carrying at least default-days in .github/dependabot.yml, or minimumReleaseAge in a Renovate configuration. Read the value as well as the key: a delay shorter than a day does not outlast the window it exists to cover, and on Dependabot a value below the three days the platform already applies protects the repository more slowly than writing nothing. Read what the delay covers as well as how long it runs. Dependabot's cooldown reaches every dependency while include is absent, narrows to what include names once it is present, and drops what exclude names, exclude winning; Renovate's top-level minimumReleaseAge is overridden wherever a packageRules entry sets its own. A configuration whose resolved coverage leaves the repository's dependencies outside the delay fails, whatever number sits beside the key. Name the platform default in the finding, because the two updaters fail differently. Dependabot applies a three-day cooldown to version updates where no cooldown block is configured, so its finding is an unwritten control. Renovate's minimumReleaseAge defaults to no delay at all, so its finding is an open window. Dependabot's cooldown applies to version updates and never to a security update, and Renovate's behaviour on a vulnerability alert is set separately by minimumReleaseAgeBehaviour, so neither setting has to be qualified to keep an advisory-driven fix prompt. A repository with no updater configuration at all falls outside this rule and fails R-SEC-03 instead, which is the same gap counted once.
Where this comes from
- https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
- https://docs.renovatebot.com/configuration-options/
- https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates
- https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/
- https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/
- https://pnpm.io/supply-chain-security
Last read against these sources on 2026-08-04.
The two updaters differ, and the rule says so because a source settles each half. Dependabot applies a three-day cooldown to version updates with no cooldown block configured: the options reference states it, and the changelog post of 2026-07-14 dates it and scopes it to github.com and to GitHub Enterprise Server 3.23. Renovate's minimumReleaseAge defaults to null, which is no delay, so the open window the rule was written for is still open there. That default is also why the rule now asks for the value to be written down rather than inherited, which is the position R-SEC-08 and R-SEC-15 take about a manager default: a number the platform chose can be changed by the platform, and a reader auditing a repository cannot see it. Both halves of the coverage clause are documented rather than inferred. GitHub's tutorial states that omitting include applies the cooldown to all dependencies, so adding one narrows it, and the options reference gives include and exclude wildcards and 150 entries each with exclude winning, which is what lets a block that looks configured cover nothing. Renovate documents minimumReleaseAge inside packageRules with a worked example, so the same hollowing works there through an override rather than a list. The floor clause follows from the default: Dependabot accepts 1 to 90 days, so a repository cannot write a zero, and every value it can write below 3 is slower than the block it replaced. Dependabot documents the cooldown as never applying to a security update, and Renovate settles the same question through minimumReleaseAgeBehaviour, which is what lets the rule ask for a delay without slowing an advisory-driven fix. The day floor is this project position: no source names a number, and the incidents the rule exists for were found and pulled in hours rather than minutes. pnpm shipping minimumReleaseAge on by default at one day in v11, and Yarn defaulting npmMinimalAgeGate to one week, are the closest thing to a published value. What would retire the rule is every updater defaulting a cooldown on, which Dependabot has now half done.