Every security team that has run Dependabot against a private registry knows the drill. You need a personal access token, a safe place to store it, a reminder to rotate it, and a way to update it in dependabot.yml before it expires and quietly breaks your dependency updates. None of that is hard. It’s tedious, and people skip tedious security chores.
GitHub has now closed that gap for its own registries. As of this week, Dependabot can authenticate directly to GitHub Packages, the GitHub Container Registry (ghcr.io), and other GitHub-hosted package registries without a PAT. It uses the same GITHUB_TOKEN mechanism that already powers GitHub Actions workflows, requesting packages: Read access and presenting that token automatically when it pulls a dependency. If a repository already has access to a package through the “Manage Actions access” setting, Dependabot inherits that access the same way an Actions workflow would.
That last part is the real change. Dependabot has always been treated as a separate citizen from the rest of a repository’s automation, with its own credentials and its own trust boundary. This update folds it back into the permission model teams already maintain for Actions. Admins add the repository under a package’s “Manage Actions access” list with read permission, and Dependabot just works. No new secret to generate. No token sitting in a settings page waiting to be forgotten.
The rollout itself is worth knowing about, because it wasn’t entirely smooth, and that’s a useful reminder for anyone tempted to flip on a new authentication path without watching it closely. GitHub first shipped this capability in June. It ran into trouble with npm dependency resolution and had to be rolled back while GitHub worked out the conflicts. It’s back now, generally available, with token-based authentication as the default and PAT-based credentials preserved as a fallback rather than removed outright. Teams that already have registry credentials configured in dependabot.yml don’t need to remove them. They can leave them in place while GitHub’s default path takes over, and clean them up later once they’ve confirmed updates are flowing correctly.
That fallback design matters more than it might seem. Supply chain tooling has a bad habit of asking teams to trust a new mechanism completely on day one. Keeping the old credential path alive as a safety net, rather than forcing a hard cutover, is the difference between an update engineering teams adopt calmly and one they approach with a support ticket already drafted.
It’s also a small but telling signal about where GitHub is spending its security engineering effort. Dependency confusion attacks, leaked tokens, and stale credentials sitting in CI configuration are not exotic problems. They’re the boring, everyday failure modes that show up in supply chain security postmortems again and again. Fixing them doesn’t generate the same headlines as a new AI feature, but it closes real exposure. A PAT with read access to a private registry is one more secret that can leak, get committed to a repo by accident, or outlive the person who created it. Removing the need for that token removes all three risks at once.
“Access control for automated tooling should follow the same identity path as everything else in the pipeline, not a separate one,” said Mitch Ashley, Vice President and Practice Lead for CIO & Technology Buyers and for Software Lifecycle Engineering at The Futurum Group. “Every credential that exists outside that path is something a security team has to track, rotate, and eventually explain in an audit. Folding Dependabot into the same token model as Actions is a small change with an outsized cleanup benefit.”
For platform teams, the practical move here is straightforward. Check which repositories are pulling from private GitHub-hosted registries through Dependabot, confirm those repositories are listed under “Manage Actions access” for the relevant packages, and start trimming the PAT entries out of dependabot.yml once the new path is confirmed working. It’s not a large lift, but it’s the kind of cleanup that tends to sit at the bottom of a backlog until an audit forces the issue.
None of this changes what Dependabot actually does. It still opens pull requests for outdated or vulnerable dependencies, and teams still decide what to merge and what not to. What’s changed is how much scaffolding it takes to get there. Every credential a team no longer has to manage is one less thing that can go wrong at 2 a.m., and one less line item in the next supply chain security review. That’s not a flashy win, but in a year where most of the AI headlines are about what agents can build, it’s a reminder that a lot of real security progress still looks like removing a token nobody wanted to manage in the first place.