GitHub permite elegir a nivel de repositorio dónde se ejecutan las actualizaciones de Dependabot: runner estándar, runner autoalojado con etiqueta o runner alojado de mayor tamaño. El cambio sirve para alcanzar registros privados o usar entornos especializados sin imponer la misma configuración a toda la organización. Solo está disponible para repositorios privados e internos de GitHub.com.
El anuncio del 29 de septiembre sitúa el control en Settings, Advanced Security, Dependency scanning y Dependabot version updates. Puede especificarse una etiqueta y un grupo; si se omite la etiqueta, Dependabot usa dependabot. Los repositorios públicos y GitHub Enterprise Server no muestran esta opción.
Qué resuelve el ajuste por repositorio
La configuración de organización ya permitía definir runners para Dependabot. El nuevo nivel evita que un repositorio con un registro interno o una arquitectura especial dicte el entorno del resto. También permite usar un runner alojado grande cuando una resolución de dependencias exige más recursos.
| Necesidad | Elección razonable | Riesgo |
|---|---|---|
| Paquetes públicos corrientes | Runner estándar de GitHub | Poco control sobre red privada |
| Registro interno | Runner etiquetado con acceso mínimo | Exponer más red de la necesaria |
| Resolución costosa | Runner alojado grande | Mayor coste |
| Segmentación por equipo | Grupo de runners dedicado | Capacidad insuficiente o cola |
El runner hereda el riesgo de ejecutar dependencias
Dar acceso a un registro privado no obliga a abrir toda la red corporativa. El runner debería tener credenciales de solo lectura cuando sea posible, salida limitada, entorno efímero y registros que permitan saber qué actualización accedió a qué servicio. Un grupo específico facilita separar Dependabot de workflows con secretos más amplios.
Las configuraciones de seguridad de GitHub no aplican actualmente estos ajustes. Eso significa que una política central no garantiza por sí sola que cada repositorio use el runner esperado. El administrador necesita inventario y revisión adicional, especialmente si delega el ajuste a responsables de repositorio.
Cómo desplegarlo sin perder actualizaciones
- Identificar repositorios con registros o redes privadas.
- Crear un grupo mínimo y una etiqueta inequívoca.
- Probar una actualización de versión y otra de seguridad.
- Medir tiempo en cola, fallos de red y consumo.
- Documentar la alternativa si el grupo no tiene capacidad.
El cambio no hace mejor a Dependabot ni valida una actualización; decide dónde se resuelve. Las revisiones, pruebas y reglas de fusión siguen siendo necesarias. Tampoco debe confundirse con el mínimo móvil de versión de los runners autoalojados que GitHub empezó a aplicar esta semana.
Texploto no ha configurado runners. La evidencia es documentación y anuncio primario de GitHub, sin prueba independiente. La aportación propia es una matriz de elección y controles de mínimo privilegio para aplicar el nuevo ajuste.
Transparencia: artículo elaborado con asistencia de IA a partir de las fuentes enlazadas. No se han ejecutado los productos o sistemas descritos.
