Dependabot espera tres días: convierte la velocidad de actualización en una política de suministro

Dev

GitHub ahora retrasa por defecto los PR rutinarios de Dependabot hasta que la versión lleve al menos tres días en el registro. Las actualizaciones de seguridad siguen siendo inmediatas.

Diagrama desde la publicación de un paquete hasta observación, PR, revisión de dependencias, instalación congelada y despliegue
Tres días crean una ventana de observación; no certifican que una versión sea segura.

Qué cambió

El cambio cubre los ecosistemas compatibles en github.com y llegará a GHES 3.23. cooldown permite entre 1 y 90 días, ventanas por SemVer y listas include/exclude.

Observar no es validar

La espera permite que aparezcan retiradas, issues o avisos, pero el silencio no demuestra seguridad. El calendario del bot, la revisión y el despliegue crean otros relojes.

Separar PR e instalación

La regla solo decide cuándo Dependabot abre un PR. No bloquea instalaciones manuales ni otros bots. En npm, min-release-age actúa en la resolución; el lockfile y npm ci reproducen el árbol aprobado.

Operación práctica

Dependency Review debe inspeccionar cambios directos y transitivos. Conviene separar reglas para runtime, herramientas, GitHub Actions, contenedores e IaC según su alcance.

Riesgos

El cooldown puede retrasar PR sin reducir su volumen y no detecta por sí solo una versión maliciosa. Hacen falta agrupación, excepciones con caducidad, canary y rollback.

Lista práctica

Inventariar dependabot.yml

Separar SLA de versión y seguridad

Exigir Dependency Review

Usar lockfile e instalación congelada

Asignar dueño y caducidad a excepciones

GitHub: GitHub Changelog: Dependabot version updates introduce default package cooldown

Fuentes