GitHub anunció el 10 de noviembre de 2026 que, a partir del 8 de diciembre, desactivará las alertas de Dependabot en la mayoría de los repositorios que hayan pasado el último año sin actividad. Las alertas existentes se archivan, no se eliminan, y pueden restaurarse. La razón que da GitHub es el rápido crecimiento de las vulnerabilidades descubiertas y del volumen de alertas, que quiere mantener ágil para los repositorios en desarrollo activo.
Un repositorio sin commits puede seguir sosteniendo un sistema en producción. Un sitio institucional, una API interna o un plugin entregado a un cliente pueden pasar un año sin commit y seguir en línea, con las mismas dependencias. Una vulnerabilidad publicada después en esas dependencias deja de aparecer como alerta.
Qué cuenta como actividad
Según el changelog, solo tres eventos reinician el plazo de un año:
- un push a cualquier rama o tag;
- la creación del repositorio;
- la activación de las alertas de Dependabot.
Abrir un issue, comentar o ejecutar un workflow no aparece en la lista. Cualquier push vuelve a activar las alertas automáticamente, y también se pueden reactivar en la configuración del repositorio. En ambos casos, GitHub restaura las alertas archivadas y el plazo vuelve a empezar.
El cambio aplica a todos los planes de github.com y a GitHub Enterprise Cloud con residencia de datos. GitHub Enterprise Server queda fuera.
Quién pierde alertas sin darse cuenta
Los casos más expuestos son los de código que ya terminó de desarrollarse y sigue funcionando: proyectos de agencia entregados y mantenidos bajo demanda, bibliotecas internas estables, sitios en WordPress o Laravel que solo cambian cuando alguien lo pide. Es la etapa en que la responsabilidad por el sistema suele estar ya difusa, tema de quién cuida el sistema cuando termina el proyecto, y ahora el sistema pierde también un aviso automático.
Las organizaciones que ya aplican una configuración de seguridad obligatoria con las alertas de Dependabot activadas no se ven afectadas. Tampoco las enterprises cuya política impide a los administradores de repositorio activar o desactivar las alertas.
Qué hacer antes del 8 de diciembre
Primero, listar los repositorios sin push en doce meses y separar los que corresponden a algo en producción. Ese cruce depende de un inventario propio, porque GitHub no sabe qué está en línea.
Para los que deben seguir monitoreados, el camino que indica el propio GitHub es la excepción formal: una configuración de seguridad de la organización, aplicada como obligatoria, con las alertas de Dependabot activadas, o la política equivalente en la enterprise. Hacer un push vacío o reactivar las alertas a mano también funciona, pero solo por otro año, y depende de que alguien lo recuerde. En mi opinión, eso solo sirve como paliativo mientras la configuración de la organización no esté lista.
Para lo que realmente fue abandonado, el cambio puede ser aceptable. En ese caso, conviene archivar el repositorio y dejar registrado que nadie sigue las dependencias de ese código.
Lo que el anuncio no dice
El texto solo habla de alertas. No dice si las actualizaciones de seguridad de Dependabot, que abren pull requests de corrección a partir de las alertas, también se detienen, ni si habrá aviso por correo o en la interfaz antes de pausar cada repositorio. Tampoco menciona un filtro en la API o en el panel para listar los repositorios afectados. El "la mayoría de los repositorios" del anuncio sugiere que puede haber otras excepciones además de las dos descritas. Hasta que GitHub dé más detalles, la premisa segura es que un repositorio inactivo y sin excepción configurada deja de recibir alertas el día 8.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
