Add 14 day cooldown before Renovate proposes updates - #302
Merged
Conversation
Registries serve newly published versions to dependency resolution immediately. The 2026 attack pattern is consistent: a publish token is stolen, a malicious version is published under a genuine package name, the payload runs at install time and harvests credentials from the installing machine, and the registry pulls the version within hours. An automated consumer fetches it before detection happens, so the delay has to be implemented on the consumer side. The exposure here is CI's own secrets - GITHUB_TOKEN, repository secrets, and release.yaml's packages: write - regardless of the fact that the published features are pure shell with no third party implementation. Cost of the delay is close to zero here: no automerge, no deadlines, no SLA, and releases are triggered manually. Security fixes are unaffected - vulnerabilityAlerts defaults to minimumReleaseAge: null and prCreation: "immediate", so they bypass both this and schedule:monthly. Drop the per-package jdx/mise rule: at 1 day it would have been a hole in the global value rather than a delay, and its stated purpose (avoid errors installing a very fresh version) is served better by 14 days. Before this, only @devcontainers/cli was gated at all. prettier and shellcheck resolve through the mise registry to github-releases, not npm, so security:minimumReleaseAgeNpm never covered them.
There was a problem hiding this comment.
Pull request overview
This PR hardens Renovate dependency update proposals by introducing a 14‑day minimum release age, reducing exposure to short-lived malicious releases that may be published and then pulled within hours.
Changes:
- Removes the
security:minimumReleaseAgeNpmpreset and explicitly ignores it (to avoid nested preset rules overriding the intended global setting). - Sets a global
minimumReleaseAge: "14 days"for Renovate update proposals. - Adds package rules to exempt update types and datasources that don’t provide usable release timestamps for aging.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Registries serve newly published versions to dependency resolution immediately. The 2026 attack pattern is consistent: a publish token is stolen, a malicious version is published under a genuine package name, the payload runs at install time and harvests credentials from the installing machine, and the registry pulls the version within hours. An automated consumer fetches it before detection happens, so the delay has to be implemented on the consumer side. The exposure here is CI's own secrets - GITHUB_TOKEN, repository secrets, and release.yaml's packages: write - regardless of the fact that the published features are pure shell with no third party implementation.
Cost of the delay is close to zero here: no automerge, no deadlines, no SLA, and releases are triggered manually. Security fixes are unaffected
Drop the per-package jdx/mise rule: at 1 day it would have been a hole in the global value rather than a delay, and its stated purpose (avoid errors installing a very fresh version) is served better by 14 days.
Before this, only @devcontainers/cli was gated at all. prettier and shellcheck resolve through the mise registry to github-releases, not npm, so security:minimumReleaseAgeNpm never covered them.