Product1 publisher2 min readPublished
Dependabot now authenticates to GHCR with the same token Actions already carries
The PAT in dependabot.yml can finally come out, but only after an admin adds the repository to the package's Manage Actions access list, and GitHub keeps the old credential working, leaving half-done migrations indistinguishable from finished ones.
The Product Desk · Product desk
What happened
- Dependabot can now authenticate to GitHub Packages, ghcr.io and other GitHub-hosted registries with the GITHUB_TOKEN mechanism that already powers Actions workflows, with no personal access token involved.
- Access follows the package's Manage Actions access list: a repository granted read there is inherited by Dependabot the same way an Actions workflow inherits it, with no new secret to generate.
- Token authentication is now the default, and PAT-based registry credentials remain supported as a fallback rather than being removed.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision Retiring a registry PAT becomes a scheduling problem across two owners, because whoever edits dependabot.yml cannot finish the job until a package admin adds the repository to the read list.
- exposure Any PAT still sitting in dependabot.yml after the grant lands is a credential with no remaining job, valid and leakable until somebody bothers to revoke it.
- constraint Dependabot's registry access is now bounded by a package permission list, so a repository quietly dropped from that list loses its updates with nothing to fall back on once the PAT is gone.
- precedent With Dependabot on the Actions identity path, a bot keeping its own separate credential is harder to defend the next time an auditor asks who rotates it.
The PAT in dependabot.yml usually leaves by expiring rather than by decision. Updates stop without a page, and the gap surfaces weeks later when the security bump that should have opened a pull request never did. devops.com puts it plainly: the upkeep is tedious rather than hard, and people skip tedious chores [8].
The token path removes the secret and relocates the work. Deleting a credential line is a repo-level edit, while the permission that has to replace it sits on the package, where an admin adds the repository to the Manage Actions access list with read rights [3]. That is two changes owned by two roles, and they only work in that order. Mitch Ashley of The Futurum Group calls it "a small change with an outsized cleanup benefit" [7], and the cleanup is real, but it is cleanup that depends on a permissions list the repo owner may not control.
The failure mode here is quiet. Token authentication is the default while existing PAT entries keep working [4][6]. A repository that never got its package grant keeps updating on its old token, and nothing distinguishes that state from a completed migration until the token expires [9]. The absence of failed Dependabot runs does not mean the switch landed; it only shows that something is still authenticating, and the run log does not say which credential did it.
devops.com scopes the change to GitHub's own registries and describes no equivalent for registries GitHub does not host [11], so the honest expectation is one class of token retired rather than a rotation calendar closed.
The sequence devops.com recommends [10] collapses into a four-cell check per repository, on two axes: package grant present or absent, PAT present or absent.
- Grant and PAT: delete the PAT. This is the only cell where the cleanup is safe today. - Grant, no PAT: finished. - No grant, PAT: updates are running on the token alone, and removing it breaks them. - No grant, no PAT: updates are already failing, or the package is public.
Only one of those four states requires work before anyone touches dependabot.yml [12], which makes the check cheap enough to run across every repo rather than sampling. The rollout history is the argument for running it: GitHub first shipped this in June, hit npm dependency resolution conflicts, and rolled it back [5]. If npm is your heaviest Dependabot surface, the fallback credential is worth leaving in place until a few update PRs have landed on the new path.
What to watch
- A GitHub deadline for dropping the PAT fallback, which turns optional cleanup into a forced migration with a date on it.
- Reports of Dependabot update PRs going silent after PAT removal, which would point at missing Manage Actions access grants rather than the token mechanism.
- An audit view showing which repositories hold read access to which packages, a gap that leaves this half of the cleanup without any tooling today.