Dependabot finally drops the PAT for GitHub Packages

Dependabot can now pull from private GitHub Packages registries using its own short-lived token. GitHub shipped the change on September 8: Dependabot's GITHUB_TOKEN can request packages: read, and update jobs send it when they hit *.pkg.github.com or ghcr.io. If a package already grants your repository read access under "Manage Actions access" in its settings, Dependabot reuses that grant. No dependabot.yml changes, and it covers every Packages ecosystem Dependabot supports, from npm and Maven to container images on ghcr.io.

That's a small paragraph of mechanics for what is, in practice, the retirement of one of the most persistent bits of credential toil on the platform. The request has been sitting in dependabot-core#8411 since November 2023, and the underlying complaint is older than that.

The workaround this kills

If your org publishes internal packages to GitHub Packages, you've lived this. Dependabot jobs run in their own isolated environment, so they never saw your Actions token. The documented fix was a classic personal access token with the read:packages scope, stored in Dependabot's separate secrets store and wired into every consuming repo's config:

registries:
  github-npm:
    type: npm-registry
    url: https://npm.pkg.github.com
    token: ${{ secrets.DEPENDABOT_PACKAGES_PAT }}

Every part of that recipe ages badly. The token is long-lived, so it shows up in every security review. It's bound to a human account, so it dies when that person offboards, and internal-dependency PRs stop arriving without an error anyone reads. The standard mitigation was a machine account, which costs a paid seat and exists solely to hold one credential. Teams have been running this contraption for years while GitHub Actions itself got automatic tokens and OIDC federation replaced cloud deploy keys. Dependabot was the straggler.

The new model is the same one Actions uses: the package grants access to the repository, and anything running on behalf of that repository can read it. Authorization lives with the package owner instead of being smeared across N copies of a secret.

The June faceplant, and why the fix is the interesting part

GitHub first shipped this on June 23, then pulled it. With the automatic credential in play, npm update jobs started resolving public packages through GitHub Packages instead of the public registry.

That deserves more attention than a changelog footnote gets. Registry routing precedence is the exact mechanism dependency-confusion attacks abuse: a resolver that consults the wrong registry first can be steered toward a package it should never have installed. The June bug was a correctness failure, not an exploit, but it broke updates and it demonstrated how easy it is to get precedence wrong when you inject credentials into a resolution pipeline that multiple package managers interpret slightly differently.

The re-launched version treats the automatic credential as a fallback only. Anything you've declared explicitly in dependabot.yml keeps its credentials and its routing priority; the built-in token only fills gaps. That's the conservative design, and after June it's the right one. It also means adoption is safe to do incrementally: your existing PAT entries win until you delete them.

Adopting it, and where it stops

The migration is short. For each private package Dependabot needs, open the package's settings and add the consuming repository with Read access under "Manage Actions access." Then delete the PAT-backed registries entries from dependabot.yml, revoke the token, and reclaim the machine-account seat. If your CI already pulls these packages from Actions workflows, the grants exist and step one is done.

The friction is scale. Grants are managed per package, per repository, and GitHub's private registry docs describe no org-wide switch. An org with 150 internal packages consumed across dozens of services is looking at a lot of settings pages. Package-inheriting-repo-permissions defaults help for new packages, but auditing existing grants is on you.

And the boundary is sharp: this is GitHub-hosted registries only. Private packages on Artifactory, Nexus, or npmjs.com still need credentials in Dependabot secrets. Private git dependencies, like a Gemfile pointing at an internal repo, still go through the separate org-level Dependabot access setting. Mixed-registry shops, which is to say most large ones, get a partial cleanup rather than a clean sweep.

Verdict

This is a quality-of-life fix rather than a headline feature, and that's fine. Nobody's architecture changes. What changes is that a category of silent failure (expired PAT, departed employee, forgotten renewal) disappears for teams that standardized on GitHub Packages, along with one more long-lived credential that could leak. The pattern is consistent with where GitHub has been pushing for five years: scoped, ephemeral, automatically-issued tokens everywhere a human once pasted a secret.

If you're all-in on GitHub Packages, do the migration this sprint; it's an hour of clicking and a satisfying git rm of secrets plumbing. If you're on a third-party registry, this changes nothing for you today, but it does signal that "Dependabot needs a bot account" is a pattern GitHub considers a bug. The remaining PATs in your dependabot.yml are now on a clock.