• Siempre hemos asociado las actualizaciones con la seguridad y, en términos generales, es una relación perfectamente válida: cuanto antes corregimos una vulnerabilidad, menos tiempo dejamos abierta la puerta a posibles ataques. Sin embargo, existe un escenario en el que correr demasiado puede jugar precisamente en nuestra contra. GitHub acaba de introducir un cambio en Dependabot que parte de esta idea y que, pese a su aparente sencillez, puede resultar muy efectivo para contener determinados ataques contra la cadena de suministro de software.

A partir de ahora, Dependabot esperará de manera predeterminada al menos tres días desde la publicación de una nueva versión de una dependencia antes de abrir una pull request para actualizarla. Este periodo de enfriamiento, o cooldown, se aplica únicamente a las actualizaciones normales de versión y busca evitar que los proyectos adopten inmediatamente paquetes recién publicados que puedan haber sido comprometidos. Los responsables de cada repositorio pueden modificar este comportamiento desde el archivo dependabot.yml, pero quienes no hagan ningún cambio se beneficiarán automáticamente de esta espera.

La razón tiene bastante sentido. Uno de los ataques más peligrosos contra la cadena de suministro consiste en comprometer las credenciales, la cuenta o el proceso de publicación de un paquete legítimo y muy utilizado para distribuir una versión modificada con código malicioso. Aunque estas versiones suelen ser detectadas y retiradas relativamente rápido, incluso unas pocas horas pueden bastar para que multitud de sistemas automatizados las incorporen. GitHub recuerda, por ejemplo, el ataque que afectó en septiembre de 2025 a populares paquetes de npm como chalk y debug: las versiones maliciosas permanecieron disponibles durante alrededor de dos horas, pero hablamos de dependencias utilizadas conjuntamente miles de millones de veces cada semana.

Aquí hay una diferencia fundamental que conviene dejar muy clara: las actualizaciones de seguridad no tendrán que esperar esos tres días. El nuevo cooldown afecta a las actualizaciones destinadas simplemente a mantener nuestras dependencias al día, mientras que si Dependabot detecta una vulnerabilidad conocida y existe una versión que la corrige, podrá seguir generando inmediatamente la correspondiente alerta y la pull request necesaria para instalarla. GitHub evita así que esta nueva capa de protección termine retrasando precisamente aquellas actualizaciones en las que la velocidad sí resulta especialmente importante.

Los tres días, además, son solo el valor establecido por defecto. Cada proyecto puede adaptar el periodo a sus necesidades y establecer tiempos diferentes según el tipo de actualización, las dependencias afectadas o sus propias políticas de seguridad. GitHub permite configurar esperas de entre uno y 90 días, de modo que quienes necesiten adoptar determinadas versiones con mayor rapidez seguirán teniendo esa posibilidad. Esta flexibilidad me parece especialmente acertada: la compañía introduce una protección útil para quienes no configuren nada, pero no impone el mismo modelo de actualización a proyectos con necesidades muy diferentes.

Por supuesto, GitHub tampoco presenta esta medida como una solución universal, y hace bien. El cooldown resulta útil frente a versiones maliciosas que aparecen, empiezan a propagarse y son detectadas en poco tiempo, pero apenas aporta protección frente a puertas traseras diseñadas para permanecer ocultas durante meses, sabotajes de mantenedores o sistemas de compilación comprometidos. Por eso la compañía recomienda combinarlo con otras medidas como fijar las dependencias mediante lockfiles, limitar el alcance de los tokens utilizados en los pipelines, desactivar scripts de instalación cuando sea posible y revisar las actualizaciones antes de incorporarlas.

GitHub tampoco está sola en este movimiento, ya que otros gestores y ecosistemas de paquetes han empezado a introducir mecanismos pensados para reducir la velocidad de propagación del software comprometido. PyPI, por ejemplo, anunció recientemente que impedirá añadir nuevos archivos a una versión pasados 14 días desde su publicación, para evitar que atacantes con acceso a credenciales o sistemas de publicación puedan envenenar posteriormente una release antigua y considerada fiable. Y creo que ahí está precisamente el gran acierto de este tipo de medidas: no pretenden encontrar mágicamente todo el malware, sino reducir las oportunidades que tienen los atacantes para aprovecharse de nuestra automatización. En el caso de Dependabot, esperar tres días puede parecer poca cosa, pero a veces basta con dejar de correr para evitar ser los primeros en caer.

Más información