GitHub ha decidido que, a veces, ir despacio protege más que correr. La compañía acaba de introducir un cambio en Dependabot que apunta directamente contra el malware que se cuela en la cadena de suministro de software, y lo hace apoyándose en una idea sencilla pero muy efectiva: esperar un poco antes de adoptar cualquier novedad. Estamos acostumbrados a asociar las actualizaciones con la seguridad, y en la mayoría de los casos es una relación válida. Cuanto antes tapamos un agujero, menos tiempo dejamos la puerta abierta. Pero hay escenarios en los que ir demasiado rápido termina jugando en contra.
A partir de ahora, Dependabot esperará por defecto al menos tres días desde que se publica una nueva versión de una dependencia antes de abrir una pull request para actualizarla. Este periodo de enfriamiento, o cooldown, se aplica solo a las actualizaciones normales de versión y busca evitar que los proyectos adopten al instante paquetes recién publicados que puedan haber sido comprometidos. Quien quiera cambiar este comportamiento puede tocar el archivo dependabot.yml, mientras que el resto se beneficiará de esta espera sin mover un dedo.
Por qué esperar unas horas marca la diferencia
La lógica detrás de la medida 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 usado, para colar una versión modificada con código dañino. Estas versiones suelen ser detectadas y retiradas rápido, pero incluso unas pocas horas bastan para que un montón de sistemas automatizados las incorporen sin darse cuenta. El ejemplo que recuerda la propia GitHub es claro: el ataque que en septiembre de 2025 afectó a paquetes muy populares de npm como chalk y debug. Las versiones maliciosas estuvieron disponibles alrededor de dos horas, pero hablamos de dependencias que se usan miles de millones de veces cada semana.
Conviene dejar algo muy claro. Las actualizaciones de seguridad no tendrán que esperar esos tres días. El cooldown afecta únicamente a las actualizaciones pensadas para mantener las dependencias al día. Si Dependabot detecta una vulnerabilidad conocida y ya existe una versión que la corrige, seguirá generando al momento la alerta y la pull request para instalarla. Así se evita que esta nueva capa de protección acabe frenando justo las actualizaciones donde la velocidad importa de verdad.
Link affiliatoUna protección flexible, no una solución mágica
Los tres días son solo el valor por defecto. Cada proyecto puede ajustar el periodo según sus necesidades, el tipo de actualización o las dependencias afectadas, con esperas que van de uno a 90 días. Esa flexibilidad es un acierto, porque protege a quien no configura nada sin imponer el mismo modelo a proyectos con realidades muy distintas.
GitHub tampoco vende esto como la solución definitiva, y hace bien. El cooldown ayuda frente a versiones maliciosas que aparecen, se propagan y se detectan en poco tiempo, pero no sirve de mucho contra puertas traseras diseñadas para quedarse ocultas durante meses, sabotajes de mantenedores o sistemas de compilación comprometidos. Por eso recomienda combinarlo con otras medidas como fijar dependencias mediante lockfiles, limitar el alcance de los tokens usados en los pipelines, desactivar scripts de instalación cuando se pueda y revisar las actualizaciones antes de incorporarlas.
La compañía no está sola en esto. Otros ecosistemas de paquetes han empezado a introducir mecanismos parecidos para reducir la velocidad de propagación del software comprometido. PyPI, por ejemplo, anunció que impedirá añadir nuevos archivos a una versión pasados 14 días desde su publicación, para que nadie con acceso a credenciales pueda envenenar más tarde una release antigua y considerada fiable. El gran mérito de este tipo de medidas está ahí: no pretenden encontrar todo el malware por arte de magia, sino recortar las oportunidades que tienen los atacantes de aprovecharse de la automatización. Esperar tres días puede parecer poca cosa, pero a veces basta con dejar de correr para evitar ser los primeros en caer.
Fuente
Imagen: muycomputer.com
Link affiliato