Dependabot espera 3 días antes de PRs

Dependabot acaba de meter una pausa que cambia bastante el ritmo de mantenimiento en equipos que usan GitHub a diario: ahora espera 3 días antes de abrir pull requests de actualización para ciertos paquetes. La idea no es frenar por frenar, sino reducir el impacto de paquetes comprometidos o actualizaciones problemáticas que aparecen y desaparecen rápido, justo en ese margen donde muchas veces los bots actúan demasiado pronto.

Si tú mantienes dependencias en una app web, una API o una app móvil con pipeline automatizado, este cambio te toca de cerca. Ya no vas a ver la PR de actualización aparecer apenas sale una nueva versión en el registry; primero habrá una espera obligatoria. Eso modifica el flujo de revisión, el tiempo de exposición a vulnerabilidades y, sobre todo, cómo priorizas qué dependencias sí quieres mover rápido y cuáles conviene dejar madurar un poco.

Qué cambió exactamente en Dependabot

La novedad es simple de explicar, pero tiene varias implicaciones prácticas. Dependabot introduce un período de espera de 3 días antes de abrir PRs para actualizaciones de paquetes. En la práctica, cuando detecta una nueva versión elegible, no dispara la PR de inmediato; espera ese margen para ver si aparece información nueva sobre la publicación, el paquete o posibles problemas asociados.

GitHub enmarca este cambio como una medida para reducir el impacto de paquetes comprometidos. No es raro que un paquete sea publicado, retirado o corregido en cuestión de horas. También pasa que una versión nueva se rompe en producción, se detecta un bug crítico o, peor todavía, se confirma que hubo un problema de supply chain. Ese lapso de 72 horas le da a GitHub más tiempo para observar señales antes de empujarte una actualización automática.

Según la documentación oficial de GitHub sobre Dependabot, este tipo de ajustes forma parte de su estrategia de seguridad para dependencias y automatización de actualizaciones. Si quieres revisar el comportamiento general de Dependabot, la referencia base está en la documentación oficial de GitHub: Dependabot updates.

Por qué 3 días y no menos

Tres días no es un número arbitrario. En seguridad de software, ese margen suele ser suficiente para que aparezcan reportes iniciales, issues en el repositorio upstream o señales de que una publicación fue retirada. No elimina el riesgo, pero sí baja la probabilidad de que tú adoptes una versión problemática apenas sale.

También hay una lectura operativa. En equipos con muchas dependencias, las PRs automáticas pueden saturar la cola de revisión. Si Dependabot abre menos PRs de forma inmediata, el equipo recibe menos ruido y puede enfocarse en cambios más estables. Eso ayuda especialmente cuando tienes monorepos, varias apps o repos con decenas de paquetes directos.

La contracara es clara: si una actualización corrige una vulnerabilidad real, esperar 3 días también retrasa la exposición del fix en tu rama principal. Por eso este cambio no se trata de “dejar todo en automático” y ya, sino de revisar qué dependencias quieres mantener con un flujo estándar y cuáles quizá necesiten una política distinta.

Cómo cambia tu flujo de mantenimiento

Antes, el flujo típico era este: sale una versión nueva, Dependabot detecta el cambio, abre la PR, corre CI y tú decides si la fusionas. Ahora hay una pausa previa. Esa diferencia parece pequeña, pero cambia el momento en que recibes el trabajo y el tipo de urgencia que percibes.

En equipos pequeños, esto puede ser incluso útil. Si tú eres quien revisa dependencias después de cerrar tickets de producto, tener 72 horas de margen significa que la PR probablemente llegue cuando ya hay más señales sobre la estabilidad del paquete. En equipos grandes, el beneficio es más claro todavía: baja el volumen de PRs que llegan “recién salidas del horno” y con menos contexto.

Un ejemplo realista de semana de trabajo

Imagina un proyecto Node.js con express, axios, zod y varias dependencias transitorias. El lunes se publica una versión nueva de axios. Dependabot la detecta, pero no abre PR ese mismo día. El miércoles ya hay issues reportados por otros usuarios, o al revés, ya se confirmó que la versión está sana. Recién entonces GitHub abre la PR.

Ese pequeño retraso te puede ahorrar tiempo de revisión si la versión salió con un bug obvio. Pero si el paquete era parte de un parche de seguridad, tú vas a verlo después. Por eso conviene mirar el cambio como una capa de filtrado, no como una solución completa.

Qué deberías revisar en tu proceso

1. La frecuencia con la que Dependabot abre PRs en tus repositorios.
2. Si tienes reglas de auto-merge para minor y patch updates.
3. Si tus pipelines tardan demasiado en validar cambios menores.
4. Qué tan rápido atiendes alertas de seguridad comparado con updates normales.
5. Si tienes paquetes críticos que no deberían esperar 72 horas.

Si tu equipo trabaja con releases semanales, la pausa probablemente no te rompa nada. Si haces hotfixes frecuentes o dependes de updates casi inmediatos por compliance, sí vale la pena ajustar el proceso.

Riesgos que intenta reducir GitHub

El objetivo principal es bajar el impacto de paquetes comprometidos. En supply chain attacks, el tiempo importa. Un paquete puede ser publicado con código malicioso, con una dependencia comprometida o con una cuenta del mantenedor secuestrada. Cuando el bot abre PRs al instante, tú podrías terminar revisando y fusionando un cambio antes de que haya señales externas suficientes.

También hay otro caso común: la publicación accidental. Un maintainer sube una versión con un bug grave, la retira después de una hora y corrige el problema al día siguiente. Si Dependabot se adelanta demasiado, tu repositorio puede quedar con una PR basada en una versión que ya no conviene tocar. La espera de 3 días reduce ese tipo de ruido.

Lo que sí resuelve y lo que no

La tabla deja una cosa clara: esta pausa ayuda, pero no es una barrera mágica. Tu seguridad sigue dependiendo de tu CI, tus políticas de revisión y tu capacidad de reaccionar cuando una alerta es real.

GitHub también documenta cómo funcionan las alertas y actualizaciones de seguridad en su centro de ayuda. Si quieres entender mejor el flujo completo, revisa la documentación oficial de Dependabot security updates: Dependabot security updates.

Qué hacer si tú usas Dependabot hoy

Lo primero es no asumir que todos los repositorios se comportarán igual. Dependabot puede estar configurado con reglas distintas según el proyecto, el directorio o el ecosistema. Si tú mantienes varias apps, conviene revisar dónde te interesa aceptar esa espera y dónde no.

Lo segundo es mirar tu umbral de riesgo. Si tu equipo suele hacer auto-merge de patch updates en cuanto pasan CI, esta pausa puede ser bienvenida porque filtra actualizaciones muy recientes. Si en cambio dependes de fixes urgentes, quizá necesites combinar Dependabot con alertas manuales o con una política de updates críticos más agresiva.

Checklist práctico para tu repositorio

• Revisa si tienes auto-merge activado para dependencias no críticas.
• Define una regla distinta para paquetes de seguridad frente a updates rutinarios.
• Asegúrate de que tu CI corra rápido; si tarda 40 minutos, ya estás sumando latencia.
• Documenta quién aprueba PRs de Dependabot y en qué ventana horaria.
• Si tu equipo trabaja en LatAm con horarios distribuidos, define un dueño claro para los cambios de dependencias.

Si manejas una app con backend en Laravel, frontend en React y workers en Python, el impacto no será igual en todos los paquetes. Un update de lodash no merece el mismo tratamiento que una actualización de openssl o de un framework base. La pausa de 3 días te obliga a pensar más en esa clasificación.

Cómo afecta a equipos de LatAm y Ecuador

En equipos de Latinoamérica, el efecto más visible puede ser operativo. Muchas empresas trabajan con equipos pequeños, guardias limitadas y ventanas de despliegue acotadas. Si Dependabot abre menos PRs urgentes, reduces interrupciones en horarios donde quizá no tienes tanta cobertura.

Para equipos en Ecuador y la región, esto también puede ayudar a ordenar el backlog. No es raro que un equipo tenga que atender producto, soporte y deuda técnica con la misma gente. Tener PRs automáticas que llegan un poco más tarde puede bajar la presión diaria, siempre que no dependas de updates inmediatos para cumplir un SLA de seguridad.

La clave está en no confundir pausa con desatención. Si tú administras software para banca, salud o e-commerce, una espera de 3 días puede ser aceptable para algunos paquetes y demasiado lenta para otros. La decisión no debería ser “activar o desactivar”, sino segmentar por criticidad.

Ejemplo de política por criticidad

1. Paquetes de bajo riesgo: aceptar la espera de 3 días y auto-merge después de CI.
2. Paquetes de riesgo medio: revisar manualmente y fusionar solo en ventana laboral.
3. Paquetes críticos: monitoreo adicional y revisión inmediata de alertas de seguridad.
4. Dependencias con historial sensible: mantenerlas fuera de auto-merge.

Ese enfoque te evita tratar igual a todo el ecosistema de dependencias. En la práctica, eso suele ser más sano que dejar que un bot decida por completo el ritmo de actualización.

Qué mirar en tu configuración y en tus métricas

Si tú lideras un equipo o haces DevOps, este cambio es una oportunidad para revisar métricas que muchas veces se dejan de lado. No basta con saber cuántas PRs abre Dependabot; también conviene medir cuántas se fusionan, cuánto tardan en pasar CI y cuántas terminan revertidas.

Mira, por ejemplo, estos indicadores:

• Tiempo medio desde publicación del paquete hasta PR abierta.
• Tiempo medio desde PR abierta hasta merge.
• Porcentaje de PRs de Dependabot que fallan en CI.
• Número de dependencias críticas con auto-merge activo.
• Cantidad de actualizaciones manuales por mes que reemplazan a Dependabot.

Si el tiempo desde PR hasta merge ya era de 4 o 5 días, la pausa de 3 días suma todavía más retraso total. En ese caso, quizá debas optimizar el pipeline o cambiar la forma en que revisas updates menores.

Cuándo conviene ajustar el proceso

Si tu CI tarda demasiado, la pausa de Dependabot va a amplificar el problema. Si una PR llega 72 horas después de la publicación y luego tarda 2 horas en validar, el update ya viene con una cola larga. En cambio, si tu pipeline corre en menos de 10 minutos y tienes revisión clara, el impacto será mucho menor.

También conviene revisar si tus dependencias están agrupadas por tipo. No es lo mismo actualizar 8 paquetes front-end a la vez que un paquete de seguridad crítica. Una política de grouping bien pensada puede compensar parte del retraso.

Tabla resumen

La lectura práctica es esta: GitHub está empujando a que el mantenimiento de dependencias sea un poco menos reactivo y un poco más selectivo. Para muchos equipos eso será una mejora, porque reduce ruido y baja el riesgo de correr detrás de versiones recién salidas. Para otros, sobre todo los que viven de parches rápidos, será una señal de que toca afinar reglas.

Si tú administras varios repositorios, vale la pena revisar ahora mismo cómo Dependabot encaja con tu política de seguridad. No porque el cambio sea dramático, sino porque toca una parte sensible del flujo: el momento exacto en que decides confiar en una versión nueva.