Dependabot puede usar mirrors Composer sin tokens ficticios

El host bloqueado era el problema real

Tener un mirror interno de Composer no garantiza que Dependabot pueda usarlo. Los trabajos de actualización solo pueden conectar con hosts autorizados por su lista de salida, así que dejar la URL en composer.json no basta para que GitHub permita la conexión. El resultado típico es un job fallido porque el host del mirror queda bloqueado antes incluso de resolver dependencias. (docs.github.com)

Hasta ahora, si el mirror permitía lecturas sin autenticación, era fácil acabar creando un token de relleno solo para registrar el host. No aportaba seguridad y añadía otro secreto que almacenar, rotar y explicar meses después. GitHub ya permite declarar esos registros de organización con autenticación anónima, sin token, contraseña ni configuración OIDC. (docs.github.com)

Una configuración común para varios repositorios Laravel

La parte importante se configura una vez en la organización, no en cada repositorio. En Settings → Secrets and variables → Private registries, hay que crear un registro nuevo, indicar la URL del mirror y seleccionar el tipo de registro que corresponda a Composer. Después se eligen los repositorios que podrán utilizarlo y se selecciona el método de autenticación Anonymous. (docs.github.com)

Con eso hecho, cada proyecto Laravel puede mantener una configuración de Dependabot sencilla. No hace falta repetir credenciales del mirror en todos los repositorios si el acceso ya se concede desde la organización. Para las actualizaciones de paquetes Composer, un fichero mínimo puede ser este:

version: 2
 
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot puede usar los registros privados definidos a nivel de organización además de los que se declaren en dependabot.yml. El registro organizativo se aplica a los repositorios a los que se haya dado acceso, por lo que centralizar el mirror evita copiar la misma configuración sensible proyecto a proyecto. (docs.github.com)

Qué mejora en un homelab

Si el mirror de Composer tiene una URL alcanzable desde los runners de GitHub y permite descarga anónima, esta configuración resuelve una clase concreta de errores: el host deja de estar bloqueado para los jobs de Dependabot. Eso permite que varios repositorios Laravel consulten el mismo punto de entrada para sus dependencias sin guardar un secreto que el servidor no necesita. No convierte el mirror en público para el resto de la organización: el acceso se limita a los repositorios seleccionados al crear el registro. (docs.github.com)

También simplifica el mantenimiento cuando el homelab actúa como caché o espejo de Composer. La política de acceso vive en la organización y el repositorio conserva solo las reglas de actualización que realmente le pertenecen: ecosistema, directorio y calendario. Es una separación más limpia entre la conectividad del registro y la política de dependencias de cada aplicación. (docs.github.com)

La letra pequeña

La autenticación anónima no hace que un servicio privado de tu red sea accesible desde GitHub. Si el mirror solo existe en una VLAN, detrás de una VPN o en una IP privada, los runners alojados por GitHub no podrán llegar a él por mucho que el registro esté declarado. Para esos casos, GitHub documenta el uso de runners autohospedados para Dependabot, con acceso a la red interna y con los certificados necesarios instalados si usas una CA propia. (docs.github.com)

Tampoco sirve para un registro que realmente exige autenticación. Si tu mirror requiere usuario, token, cabeceras específicas o control de acceso, debes usar un método de autenticación compatible en lugar de marcarlo como anónimo. Además, el tipo de autenticación no se puede cambiar después de crear el registro: para pasar de token a anónimo, o al revés, hay que eliminarlo y crearlo de nuevo. (docs.github.com)

Por último, conviene tratar un mirror anónimo como parte de la superficie de suministro de software. Que no envíes credenciales es una ventaja operativa, pero sigue siendo necesario proteger el servicio, vigilar qué paquetes replica y mantener su URL disponible para los repositorios autorizados. Dependabot podrá proponer actualizaciones, pero la revisión de los cambios y de la procedencia de las dependencias sigue siendo responsabilidad del equipo. (docs.github.com)

• Fuente: GitHub Changelog
• Documentación oficial: Giving security features access to private registries