Dependabot ya puede acceder a GitHub Packages privados sin PAT

GitHub ha eliminado una fricción habitual para equipos que mantienen dependencias privadas dentro de GitHub Packages: Dependabot puede leer paquetes privados alojados en registros de GitHub sin configurar un personal access token, siempre que el paquete haya concedido acceso al repositorio mediante Manage Actions access.

El cambio es concreto, pero relevante. Hasta ahora, una configuración frecuente consistía en crear un PAT, guardarlo como secreto y referenciarlo desde dependabot.yml para que Dependabot pudiera consultar versiones privadas. Con el nuevo comportamiento, Dependabot puede usar el GITHUB_TOKEN del propio repositorio para solicitar permiso packages: read y enviarlo al acceder a registros alojados por GitHub, como *.pkg.github.com y ghcr.io.

Esto no convierte los paquetes privados en públicos ni concede a Dependabot acceso global a todos los paquetes de una organización. El acceso sigue dependiendo de una autorización explícita: el paquete debe permitir que ese repositorio lo consuma.

Qué ha cambiado exactamente

La novedad anunciada por GitHub es que Dependabot puede leer desde registros privados de GitHub Packages sin un PAT cuando se cumple esta condición:

• el paquete privado está alojado en GitHub Packages;
• el repositorio donde se ejecuta Dependabot ha sido añadido en la configuración del paquete mediante Manage Actions access;
• el acceso concedido al repositorio incluye lectura.

En ese escenario, los trabajos de Dependabot envían el GITHUB_TOKEN al resolver paquetes desde registros alojados por GitHub. GitHub indica que esta capacidad está disponible para los ecosistemas de GitHub Packages soportados por Dependabot.

La consecuencia práctica es importante: para estos paquetes, no es necesario añadir credenciales basadas en PAT en dependabot.yml. Si ya existían entradas de registro con PAT únicamente para acceder a esos paquetes de GitHub Packages, se pueden retirar tras validar que el acceso mediante Manage Actions access funciona correctamente.

Qué problema resuelve

En muchas organizaciones, GitHub Packages se usa para publicar librerías internas, imágenes de contenedor o artefactos reutilizables entre repositorios. Dependabot forma parte del ciclo de mantenimiento porque revisa manifiestos de dependencias y abre pull requests cuando detecta nuevas versiones.

El problema aparecía cuando esas dependencias no eran públicas. Si una aplicación consumía un paquete privado de GitHub Packages, Dependabot necesitaba autenticarse contra el registro para consultar metadatos y resolver versiones. El patrón habitual era crear un PAT con permisos suficientes, almacenarlo como secreto y referenciarlo desde la configuración de Dependabot.

Ese patrón funciona, pero introduce carga operativa:

• hay que crear y proteger el token;
• hay que decidir su alcance;
• hay que rotarlo;
• hay que revocarlo si cambia la identidad propietaria;
• hay que auditar en qué repositorios se utiliza;
• y hay que evitar que un token demasiado amplio se convierta en un riesgo lateral.

El nuevo modelo reduce esa superficie para los paquetes privados alojados en GitHub Packages. Si el paquete ya permite que el repositorio lo consuma mediante Manage Actions access, Dependabot puede leerlo sin que el equipo cree un PAT adicional.

El modelo de permisos: del PAT al acceso del paquete

La diferencia principal está en dónde se expresa la autorización.

Con un PAT, la capacidad de acceso está asociada a una identidad —humana o de servicio— y a los permisos concedidos a ese token. Aunque se configure con cuidado, el token debe existir, almacenarse, protegerse y mantenerse durante su ciclo de vida.

Con el nuevo comportamiento, la autorización se expresa como una relación entre el paquete y el repositorio consumidor. El paquete declara qué repositorios pueden acceder a él mediante Manage Actions access. Dependabot, al ejecutarse para ese repositorio, puede usar el GITHUB_TOKEN con permiso de lectura de paquetes para resolver las dependencias privadas correspondientes.

Esto encaja mejor con el principio de mínimo privilegio: el acceso se concede al repositorio que realmente necesita consumir el paquete, no a través de un token manual que puede acabar reutilizándose en varios lugares.

Importante: este cambio aplica a registros privados alojados en GitHub Packages. Si el proyecto usa registros externos —por ejemplo, feeds corporativos, registros npm privados ajenos a GitHub, Artifactory, Azure Artifacts u otros repositorios de paquetes— Dependabot seguirá necesitando la configuración y las credenciales compatibles con esos registros.

Ejemplo práctico con un paquete privado

Imaginemos una organización que mantiene un paquete interno @contoso/ui-components publicado en GitHub Packages. Una aplicación web lo consume desde su package.json y tiene Dependabot configurado para revisar dependencias npm semanalmente.

El manifiesto de la aplicación podría incluir algo similar a esto:

{
  "name": "customer-portal",
  "private": true,
  "version": "1.4.0",
  "dependencies": {
    "@contoso/ui-components": "2.8.1",
    "react": "18.3.1"
  },
  "devDependencies": {
    "typescript": "5.5.4"
  }
}

La configuración básica de Dependabot podría centrarse en el ecosistema y la frecuencia de revisión:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

Antes, si @contoso/ui-components era privado y estaba en GitHub Packages, podía ser necesario añadir una entrada registries con credenciales. Con el nuevo comportamiento, si el paquete ha concedido acceso de lectura al repositorio mediante Manage Actions access, Dependabot puede consultar el registro sin un PAT específico para ese paquete.

El punto importante no es solo que el YAML pueda ser más simple. Lo relevante es que el acceso deja de depender de un secreto manual y pasa a gestionarse desde la configuración del paquete.

Advertencia: no conviene eliminar todas las secciones registries sin revisar el caso concreto. Si el proyecto consume paquetes desde varios registros, o si alguno no está alojado en GitHub Packages, puede que siga necesitando credenciales explícitas para esos otros registros.

Por qué importa para DevSecOps

La actualización de dependencias es una pieza básica de la seguridad de la cadena de suministro. Detectar vulnerabilidades no basta: también hay que reducir el tiempo entre la publicación de una versión corregida y su adopción en los proyectos consumidores.

Dependabot ayuda en esa segunda parte abriendo pull requests con cambios concretos, revisables y trazables. Pero si las dependencias privadas no pueden resolverse por problemas de autenticación, la automatización se interrumpe justo antes de aportar valor.

El uso de PAT para este escenario añadía variabilidad entre equipos. Algunos repositorios tenían Dependabot correctamente configurado para paquetes privados; otros lo tenían parcialmente; y otros concedían permisos más amplios de lo deseable para evitar fricción. Reducir la necesidad de tokens manuales hace que el patrón sea más fácil de adoptar y más consistente.

Desde una perspectiva DevSecOps, el cambio tiene tres efectos positivos:

1. Menos secretos persistentes: se reduce el número de PAT almacenados como secretos.
2. Permisos más explícitos: el acceso se declara en el paquete mediante Manage Actions access.
3. Menos fricción operativa: los equipos pueden mantener actualizaciones privadas sin diseñar un ciclo de vida específico para tokens personales.

Qué cambia frente a usar un PAT

La diferencia no es solo de sintaxis en dependabot.yml. Cambia el modelo operativo.

Con un PAT:

• el acceso depende de una identidad y de un token;
• el token debe almacenarse como secreto;
• hay que vigilar su caducidad o revocación;
• hay que evitar reutilizarlo de forma excesiva;
• y hay que auditar dónde está configurado.

Con el acceso mediante GitHub Packages:

• el paquete declara qué repositorios pueden leerlo;
• Dependabot usa el GITHUB_TOKEN del repositorio para solicitar lectura de paquetes;
• el permiso queda vinculado al repositorio consumidor;
• y la gestión se desplaza a la configuración del paquete.

Esto no elimina la necesidad de gobernanza. Si un repositorio deja de necesitar un paquete, hay que retirarle el acceso desde la configuración del paquete. La mejora no consiste en relajar permisos, sino en hacerlos más naturales y menos dependientes de credenciales manuales.

Impacto en los pull requests de Dependabot

El comportamiento posterior de Dependabot no cambia de forma sustancial. Cuando detecta una versión nueva, seguirá abriendo un pull request con los cambios correspondientes en el manifiesto y, cuando aplique, en el lockfile.

Lo que cambia es la fase previa: la resolución de versiones en paquetes privados alojados en GitHub Packages. En vez de fallar por falta de autenticación o depender de un PAT configurado manualmente, Dependabot puede consultar el registro si el paquete ha autorizado al repositorio.

Las políticas del repositorio siguen aplicando igual:

• reglas de protección de rama;
• revisiones obligatorias;
• comprobaciones de CI;
• análisis de seguridad;
• validaciones funcionales;
• y cualquier proceso interno de aprobación.

Dependabot no sustituye la gobernanza del cambio. Solo facilita que las actualizaciones de dependencias privadas lleguen al flujo normal de revisión.

Cómo adoptarlo de forma segura

La adopción debería empezar con un inventario sencillo: qué paquetes privados de GitHub Packages existen y qué repositorios los consumen.

Una secuencia razonable sería:

1. Identificar paquetes privados alojados en GitHub Packages.
2. Revisar qué repositorios consumen cada paquete.
3. Abrir la configuración del paquete en GitHub.
4. En Manage Actions access, añadir únicamente los repositorios que necesitan leerlo.
5. Conceder acceso de lectura.
6. Ejecutar Dependabot o esperar al siguiente ciclo programado.
7. Verificar que Dependabot puede resolver las dependencias privadas.
8. Retirar entradas de registro basadas en PAT que ya no sean necesarias para esos paquetes.
9. Eliminar secretos obsoletos asociados a esos PAT.
10. Documentar el nuevo patrón para que los equipos no creen tokens personales por defecto.

Es importante no tratarlo solo como una limpieza técnica. El acceso a paquetes internos suele reflejar dependencias entre equipos. Si una librería es compartida por varias aplicaciones, la lista de repositorios autorizados debería mantenerse como parte de la gobernanza del paquete.

Limitaciones que conviene tener claras

El anuncio de GitHub se refiere a registros privados alojados en GitHub Packages. Por tanto, hay escenarios que quedan fuera:

• registros privados externos a GitHub;
• feeds corporativos;
• proxies internos;
• registros de paquetes gestionados por terceros;
• configuraciones mixtas en las que un proyecto consume paquetes desde varios orígenes.

En esos casos, Dependabot puede seguir necesitando secciones registries y credenciales específicas.

También hay que validar el ecosistema concreto. GitHub indica que la capacidad está disponible para los ecosistemas de GitHub Packages que Dependabot soporta, pero la configuración real del proyecto sigue importando: directorios correctos, manifiestos válidos, nombres de paquete adecuados y restricciones de versión coherentes.

Otro punto importante: este cambio se refiere a lectura de paquetes privados para resolver dependencias. No implica que Dependabot pueda publicar nuevas versiones en GitHub Packages. La publicación de paquetes sigue dependiendo de los permisos y credenciales del workflow o proceso que haga el release.

Qué revisar si Dependabot sigue fallando

Si Dependabot no puede leer un paquete privado después de adoptar este modelo, conviene empezar por los permisos:

1. Comprueba que el paquete está alojado en GitHub Packages.
2. Verifica que el repositorio consumidor está añadido en Manage Actions access.
3. Confirma que el acceso concedido es de lectura.
4. Revisa que el manifiesto referencia el paquete correcto.
5. Asegúrate de que dependabot.yml apunta al ecosistema y directorio adecuados.
6. Comprueba si el proyecto consume otros registros privados que sí requieren credenciales.
7. Revisa los logs de Dependabot para identificar errores de autenticación, resolución o configuración.

El acceso automático resuelve un caso concreto: autenticación de Dependabot frente a paquetes privados de GitHub Packages cuando el repositorio ya tiene permiso. No corrige errores de nombre de paquete, versiones inexistentes, restricciones incompatibles o manifiestos ubicados en directorios no configurados.

Buenas prácticas para equipos

La mejora permite simplificar configuraciones, pero no debería traducirse en permisos amplios sin control. Algunas recomendaciones prácticas:

• trata cada paquete privado como un artefacto con propietario claro;
• concede acceso solo a los repositorios que realmente lo consumen;
• revisa periódicamente la lista de repositorios autorizados;
• evita mantener PAT antiguos si ya no son necesarios;
• documenta cuándo usar Manage Actions access y cuándo siguen haciendo falta credenciales explícitas;
• mantén dependabot.yml bajo revisión igual que cualquier otra configuración crítica;
• ajusta la frecuencia de actualización al riesgo y madurez del equipo;
• usa límites de pull requests abiertos si el volumen de dependencias es alto.

Dependabot puede abrir el pull request, pero la decisión de fusionarlo debe seguir considerando compatibilidad, pruebas, impacto funcional y ventanas de despliegue.

Una mejora pequeña con impacto real

El acceso automático de Dependabot a paquetes privados de GitHub Packages elimina un patrón incómodo: usar personal access tokens para que una automatización pueda leer paquetes que el repositorio ya estaba autorizado a consumir.

La autorización se mueve al lugar más natural: la configuración del paquete. Dependabot aprovecha esa relación de acceso mediante el GITHUB_TOKEN del repositorio y el permiso de lectura de paquetes.

Para equipos con muchos repositorios y artefactos internos, el valor no está solo en escribir menos YAML. Está en reducir secretos persistentes, aplicar permisos más explícitos y hacer que las actualizaciones de dependencias privadas sean más fiables.

Si usas Dependabot con GitHub Packages privados, la recomendación es clara: revisa qué paquetes pueden gestionarse mediante Manage Actions access, valida el comportamiento y elimina los PAT que ya no sean necesarios.