GitHub implementa un periodo de espera de tres días en Dependabot para frenar los ataques a la cadena de suministro
Dependabot, la herramienta automatizada de actualización de dependencias de GitHub, aplica desde ahora por defecto un periodo de espera de tres días antes de proponer actualizaciones de versión de las librerías que utiliza un proyecto. Así lo ha anunciado la propia compañía a través de su blog oficial, en una medida orientada a reducir el impacto de los ataques contra la cadena de suministro de software, una de las amenazas más extendidas y dañinas en el ecosistema del código abierto.
La mecánica es sencilla: cuando un paquete publica una nueva versión en su registro, Dependabot ya no abre de inmediato una pull request para sugerir su adopción. En su lugar, esperará un mínimo de 72 horas para dar tiempo a que la comunidad de desarrolladores y los propios mantenedores detecten posibles problemas antes de que la actualización llegue a los repositorios.
Esta nueva capa de protección responde a un patrón de ataque cada vez más frecuente. Tal como explica GitHub, las nuevas versiones son un punto de entrada habitual para los atacantes que logran comprometer las credenciales, la cuenta o el proceso de publicación de un paquete legítimo y muy utilizado, distribuyendo así código malicioso camuflado como una actualización rutinaria. El portal especializado MuyComputer recuerda el incidente ocurrido en septiembre de 2025 con paquetes tan populares de npm como chalk y debug, cuyas versiones maliciosas permanecieron disponibles durante aproximadamente dos horas antes de ser retiradas, un margen suficiente para que múltiples sistemas automatizados las incorporaran masivamente. Estas dependencias, según la misma fuente, se utilizan conjuntamente miles de millones de veces cada semana, lo que ilustra la magnitud potencial del problema.
Un aspecto clave de la medida es que las actualizaciones de seguridad quedan al margen del periodo de espera. Si Dependabot detecta una vulnerabilidad conocida y existe una versión que la corrige, seguirá generando de forma inmediata la alerta y la pull request correspondiente. GitHub ha sido rotunda al respecto: las actualizaciones críticas nunca se verán retrasadas por esta nueva política, ya que en esos casos la velocidad sigue siendo un factor esencial.
El periodo de tres días es únicamente el valor predeterminado. Los responsables de cada repositorio conservan el control total sobre su configuración y pueden modificar el comportamiento desde el archivo dependabot.yml, ya sea para ampliar la espera, reducirla o incluso desactivarla por completo. Según detalla MuyComputer, GitHub permite configurar ventanas de entre uno y 90 días, lo que ofrece margen suficiente para adaptar la política a las necesidades específicas de cada proyecto, tipo de actualización o dependencia.
La medida se aplica a las actualizaciones de versión en todos los ecosistemas compatibles con Dependabot en github.com y llegará también a GitHub Enterprise Server en su versión 3.23, según precisa el blog oficial de la compañía. Los desarrolladores no necesitan realizar ninguna acción para beneficiarse del nuevo comportamiento: basta con no modificar la configuración para que el cooldown entre en vigor automáticamente.
GitHub ha sido prudente al presentar esta función. No la plantea como una solución universal contra el malware en dependencias, sino como una pieza más dentro de una estrategia de defensa en profundidad. El periodo de espera resulta eficaz frente a versiones maliciosas que aparecen, empiezan a propagarse y son detectadas en cuestión de horas o días, pero ofrece una protección muy limitada ante amenazas más sofisticadas, como puertas traseras diseñadas para permanecer ocultas durante meses, sabotajes por parte de los propios mantenedores o sistemas de compilación comprometidos. La compañía recomienda por ello combinar el cooldown con otras prácticas habituales de seguridad: fijar las versiones de las dependencias mediante lockfiles, restringir el alcance de los tokens utilizados en los pipelines de integración continua, desactivar los scripts de instalación cuando sea posible y revisar manualmente las actualizaciones antes de fusionarlas.
El movimiento de GitHub se inscribe en una tendencia más amplia dentro del ecosistema de gestores de paquetes. PyPI, por ejemplo, anunció recientemente que impedirá añadir nuevos archivos a una versión transcurridos 14 días desde su publicación, con el objetivo de evitar que un atacante con acceso a credenciales o sistemas de publicación pueda envenenar posteriormente una release antigua que la comunidad ya considera fiable. Iniciativas de este tipo comparten una misma filosofía: no pretenden detectar todo el malware existente, sino reducir las oportunidades que tienen los atacantes para aprovechar la automatización masiva en su beneficio.
En definitiva, esperar tres días puede parecer un cambio menor, pero supone un replanteamiento significativo de cómo se gestiona la actualización automática de dependencias. Frente a la cultura imperante de aplicar parches lo más rápido posible, GitHub introduce una pausa deliberada que, en muchos casos, puede marcar la diferencia entre incorporar una versión legítima o una versión recién comprometida.