Dependabot can finally pull from private GitHub Packages without a PAT

The first time I wired Dependabot up to a private package registry, it took three meetings and a calendar reminder set six months ahead. The reminder was for the personal access token I had to mint to do it, the one I would have to rotate by hand before it expired, living in a config that drifted somewhere between repo settings, a .github file, and an internal wiki page nobody had touched in a year. On June 23 GitHub posted a small changelog item that quietly retires that whole ritual: Dependabot can now read your private GitHub Packages and GHCR registries through its own GITHUB_TOKEN, no PAT required.

If you have ever had to explain to a security review why your bot account holds a token your team owns but a person minted, you already know why this lands.

The PAT we all had and nobody loved

Until this week, Dependabot's path to a private GitHub-hosted package was the same path it took years ago. A human minted a personal access token, scoped wide enough to read the registry, stored it as a repo or org secret, and plugged it into Dependabot so the bot could authenticate when it tried to resolve dependencies. That token expired on a human schedule. It belonged to whoever happened to set Dependabot up, which is rarely the person who still owns the repo a year later.

You can feel how that ends. Tokens that quietly expire and break a Dependabot PR the day someone needs the patch. Tokens that follow an offboarded engineer out the door. Tokens with scopes wider than the job actually requires, because nobody wanted to mint a fine-grained one per registry path. None of those failures are catastrophic on their own. All of them are the kind of papercut a platform team ends up owning.

What the GITHUB_TOKEN does here

The new behavior is straightforward. Dependabot's job-scoped GITHUB_TOKEN can now request a packages: read permission. When the bot pulls from a hostname under *.pkg.github.com or ghcr.io, it sends that token instead of asking for a PAT. The same token that already authenticates Dependabot's commits and PRs now does its package reads too.

The authorization side reuses something you may already have configured. GitHub Packages has a feature called Manage Actions access, which lets a package grant repositories permission to pull it inside Actions workflows. If a package has already granted access to the repository where Dependabot is running, that same grant now accepts Dependabot's token, exactly the way it accepts a regular Actions workflow. Per the changelog, this lights up across every GitHub Packages ecosystem Dependabot supports, so npm, Maven, NuGet, Docker images and friends all benefit without a per-ecosystem opt-in.

If you read CI credential changes for a living, the shape will feel familiar. Take a job-scoped ephemeral token that already exists, hand it one more carefully bounded permission, and stop asking humans to broker an auth flow.

How this lands in a real repo

The friction removal is mostly invisible, which is the point. If you currently have a Dependabot setup that leans on a PAT for private GitHub Packages, you can audit the package's Manage Actions access list, confirm the consuming repo is on it, drop the PAT from your Dependabot secrets, and let the bot pick up the next scheduled run with the new flow.

There is no new YAML to learn for the simple case. The interesting work is on the package side: walking through which repos a package grants, deciding whether that grant list is still right, deleting the rows that belong to repos that no longer exist. That used to be invisible plumbing. It is now the plumbing.

Where the friction still lives

A few honest caveats before you rip out every Dependabot PAT in the org.

This only covers GitHub-hosted registries. If Dependabot pulls from a private npm registry on your own infrastructure, an internal Artifactory, or a third-party host, you are still in PAT or service-account territory there. The change narrows the credential surface; it does not erase it.

The grant model also assumes someone is actually curating the Manage Actions access list per package. On a team that ships dozens of internal packages, that list drifts fast. It is worth standing up a quarterly check, the same way you probably already audit deploy keys and webhook secrets.

And a token getting smaller in scope is good news for the day it leaks and a quieter cause of "why did Dependabot stop opening PRs" the next time someone forgets to add a new repo to the grant list. Pick your problem.

What I am watching next

I want to see how this plays with packages that were never meant to be consumed by Actions in the first place. Some of the oldest internal libraries I work with have grant lists that predate the current UI, and I expect the first thing teams find when they look is that the grants are out of date. That is not really a regression, just the cost of moving a control from "personal credential" to "explicit grant".

If your Dependabot config still references a PAT in a secret called something like <DEPENDABOT_PACKAGES_PAT>, this week is a good week to find out whether you still need it. Most teams will not. Most teams will also discover they had three more lying around.