Siempre asociamos las actualizaciones con la seguridad y, en general, es una relación perfectamente válida: cuanto antes solucionemos las vulnerabilidades, menos tiempo estará abierta la puerta a posibles ataques. Sin embargo, hay una escena, Correr demasiado puede tener efectos adversos en nosotros. GitHub acaba de realizar cambios en Dependabot basándose en esta idea A pesar de su aparente sencillez, puede resultar muy eficaz para contener determinados ataques contra la cadena de suministro de software.

de aquí en adelante, De forma predeterminada, Dependabot esperará al menos tres días después del lanzamiento de una nueva versión. Antes de abrir una solicitud de extracción para actualizar dependencias. Este período de recuperación o período de recuperación solo se aplica a las actualizaciones de versión normales y a la búsqueda Evite que los proyectos adopten inmediatamente paquetes recién lanzados que puedan estar rotos. El responsable de cada repositorio puede modificar este comportamiento desde el archivo dependabot.yml, pero aquellos que no realicen ningún cambio se beneficiarán automáticamente de esta espera.

Esta razón tiene sentido. Uno de los ataques más peligrosos a la cadena de suministro es comprometer las credenciales, las cuentas o el proceso de publicación de paquetes legítimos. y se usa ampliamente para distribuir versiones modificadas con código malicioso. Aunque estas versiones suelen detectarse y eliminarse con relativa rapidez, para muchos sistemas automatizados incluso unas pocas horas son suficientes para fusionarlas. Por ejemplo, GitHub recuerda un ataque de septiembre de 2025 que afectó a paquetes npm populares como chalk y debug: La versión maliciosa persistió durante aproximadamente dos horas.pero estamos hablando de dependencias que se utilizan juntas miles de millones de veces cada semana.

Aquí hay una diferencia fundamental que debe quedar muy clara: No es necesario esperar estos tres días para recibir actualizaciones de seguridad.. El nuevo cooldown afecta a las actualizaciones cuya finalidad es simplemente mantener actualizadas nuestras dependencias, mientras que si Dependabot detecta una vulnerabilidad conocida y hay una versión que la corrige, podrá inmediatamente seguir generando las alertas adecuadas y los pull request necesarios para instalarlo. Como resultado, GitHub puede evitar que esta nueva capa de protección retrase en última instancia aquellas actualizaciones donde la velocidad es particularmente importante.

Además, tres días es sólo el valor predeterminado. doCada proyecto puede ajustar el ciclo y establecer diferentes tiempos según sus propias necesidades. Depende del tipo de actualización, las dependencias afectadas o su propia política de seguridad. GitHub te permite configurar Espere de 1 a 90 díaspor lo que aquellos que necesiten adoptar determinadas versiones más rápido aún tienen esa posibilidad. Esta flexibilidad me parece especialmente exitosa: la empresa introduce protecciones útiles para quienes no configuran nada, pero no impone el mismo modelo de actualización a proyectos con necesidades muy diferentes.

ciertamente, GitHub tampoco presenta esta medida como una solución universal, pero hace un buen trabajo.. El enfriamiento es útil para las versiones maliciosas que surgen, comienzan a propagarse y se detectan en un corto período de tiempo, pero brinda poca protección contra puertas traseras diseñadas para ocultarse durante meses, sabotaje del mantenedor o sistemas de compilación comprometidos. Por eso las empresas recomiendan combinado con otras medidas Los ejemplos incluyen el uso de archivos de bloqueo para corregir dependencias, limitar el alcance de los tokens utilizados en las canalizaciones, deshabilitar los scripts de instalación cuando sea posible y buscar actualizaciones antes de registrarlas.

GitHub no está solo en este movimiento, ya que Otros ecosistemas y administradores de paquetes han comenzado a introducir mecanismos diseñados para frenar la propagación del software infectado.. Por ejemplo, PyPI anunció recientemente que evitará que se agreguen nuevos archivos a las versiones 14 días después del lanzamiento, para evitar que los atacantes con acceso a credenciales o sistemas de versiones envenenen versiones más antiguas y consideradas confiables. Creo que ese es el gran éxito de medidas como esta: no están diseñadas para encontrar mágicamente todo el malware, pero sí para reducir las oportunidades de que los atacantes aprovechen nuestra automatización. En el caso del Dependabot, esperar tres días puede parecer poca cosa, pero a veces basta con dejar de correr para no ser el primero en caer.

Más información