Dependências privadas no GitHub Packages criavam um paradoxo: o Dependabot deveria remover trabalho manual de atualização, mas precisava de um personal access token guardado como segredo para enxergar os pacotes. Esse token tinha dono, escopo, expiração e uma rotação que alguém precisava lembrar.
Desde 8 de setembro, o Dependabot pode acessar registries privados hospedados no próprio GitHub sem PAT. Ele usa o GITHUB_TOKEN do job para solicitar packages: read e reutiliza a permissão que o pacote já concedeu ao repositório por “Manage Actions access”.
A autorização fica ligada ao repositório
O modelo novo aproxima Dependabot de um workflow comum do GitHub Actions. Nas configurações do pacote, o mantenedor adiciona o repositório consumidor e concede leitura. Quando o job precisa baixar uma imagem do GHCR ou uma dependência de outro registry em *.pkg.github.com, o token temporário daquela execução apresenta a autorização.
Não é acesso automático a qualquer pacote privado da organização. O grant continua explícito em cada pacote. Esse detalhe preserva o princípio do menor privilégio: o repositório do frontend não recebe leitura sobre toda a biblioteca interna só porque ambos pertencem à mesma empresa.
O que sai do dependabot.yml
Antes, uma configuração para registry privado podia apontar para um segredo contendo PAT. Depois que o acesso do repositório estiver concedido e um update job funcionar, entradas criadas apenas para autenticar no GitHub Packages podem ser removidas. O GitHub afirma que não é necessário alterar o dependabot.yml para habilitar o novo caminho.
registries:
internal-npm:
type: npm-registry
url: https://npm.pkg.github.com
token: ${{ secrets.DEPENDABOT_PACKAGES_PAT }}
Não apague a configuração no escuro. Ela pode conter namespace, substituição de URL ou credencial de outro provedor, e nem toda entrada é um remendo de autenticação. O escopo da novidade são registries do GitHub suportados pelo Dependabot, incluindo GHCR. Artifactory, Cloudsmith e registries próprios continuam com suas regras.
Por que o GITHUB_TOKEN é uma troca melhor
Um PAT é uma credencial ligada a uma pessoa ou integração, normalmente reutilizável até expirar ou ser revogada. O GITHUB_TOKEN é emitido para o job, dura pouco e recebe permissões delimitadas pelo contexto da execução. Se aparecer em um log, sua janela útil é muito menor.
A mudança também simplifica desligamentos. A saída de um mantenedor não deveria quebrar atualizações porque um pacote dependia do token pessoal dele. O grant pacote–repositório descreve melhor a relação real e pode ser revisado nas configurações do ativo que está sendo compartilhado.
O primeiro rollout foi revertido
Há uma nota importante no anúncio. O GitHub lançou inicialmente o recurso em 23 de junho e fez rollback ao identificar um conflito: alguns jobs npm passaram a resolver pacotes públicos pelo GitHub Packages. Na versão reativada, a credencial automática funciona apenas como autenticação de fallback. Configurações explícitas de registry e o roteamento normal continuam com precedência.
O episódio explica por que a migração deve observar mais que o sinal verde do job. Confira de qual registry cada pacote veio, especialmente quando a organização usa o mesmo scope em fontes diferentes. Lockfile, logs de resolução e integridade do artefato ajudam a detectar uma rota inesperada.
Uma migração em seis passos
- Liste os pacotes privados usados pelo repositório e os registries que os hospedam.
- Em cada GitHub Package, conceda acesso de leitura ao repositório consumidor em “Manage Actions access”.
- Dispare manualmente um job do Dependabot ou aguarde a próxima execução.
- Confirme atualização, origem dos pacotes e ausência de erro de autenticação.
- Remova do
dependabot.ymlapenas as entradas que existiam para fornecer o PAT ao GitHub Packages. - Apague o secret e revogue o token se ele não tiver outra finalidade.
Revogar fecha o trabalho. Deixar o PAT guardado “caso precise voltar” mantém a porta antiga aberta. Se rollback for necessário, gere uma credencial nova, com prazo e escopo mínimos, em vez de conservar uma chave paralela indefinidamente.
Menos segredo não significa acesso sem governança
A lista de repositórios autorizados em cada pacote vira parte da superfície de segurança. Repositório arquivado, transferido ou comprometido não deveria conservar leitura por inércia. Inclua esses grants na revisão periódica de acesso e remova consumidores que deixaram de existir.
A melhor credencial é a que não precisa ser armazenada. Neste caso, o GitHub conseguiu usar uma relação que já existia para emitir autorização temporária ao Dependabot. O ganho aparece duas vezes: menos chance de vazamento e menos rotina de rotação para manter a automação viva.
