GitHub hat am 8. September 2026 den Zugriff von Dependabot auf private GitHub-Packages-Registries geändert. Für Pakete auf *.pkg.github.com und Container-Images auf ghcr.io kann Dependabot nun den eigenen GITHUB_TOKEN mit packages: read verwenden. Ein zusätzlich gepflegter Personal Access Token ist dafür nicht mehr nötig, wenn das Paket dem Repository bereits über „Manage Actions access“ Leserechte gibt.
Bisher brauchte Dependabot für interne Pakete häufig andere Credentials als normale GitHub-Actions-Workflows. Der neue Ablauf verwendet stattdessen eine bereits vorhandene Repository-zu-Package-Berechtigung.
Dependabot übernimmt die Package-Freigabe des Repositorys
Der neue Mechanismus gibt Dependabot keinen pauschalen Zugriff auf private Pakete einer Organisation. Das Paket muss dem Repository weiterhin Zugriff gewähren.
GitHub verwendet dafür dieselbe Berechtigung, die unter „Manage Actions access“ in den Package-Einstellungen gesetzt wird. Hat Repository A dort Read-Zugriff auf ein privates Paket, kann ein Dependabot-Job aus Repository A diese Berechtigung ebenfalls nutzen.
Beim Abruf aus GitHub Packages sendet Dependabot seinen GITHUB_TOKEN mit packages: read. GitHub beschreibt das Verhalten als dieselbe Repository-Freigabe, die auch ein normaler Actions-Workflow verwendet.
Damit hängt die Autorisierung am Repository und am Paket. Ein separat angelegter Benutzer-Token ist für diesen GitHub-internen Zugriff nicht mehr erforderlich.
Der PAT war ein eigener Credential-Lebenszyklus
GitHubs Dokumentation zu privaten Registries zeigt den bisherigen Sonderfall: Für GitHub-Packages-Registries wurde bei tokenbasierter Konfiguration ein GitHub Personal Access Token verwendet. Dieser Token musste als Secret hinterlegt und in der Dependabot-Konfiguration referenziert werden.
Ein solcher Token hat einen Besitzer, Scopes und einen eigenen Lebenszyklus. Wird die verantwortliche Identität gelöscht oder der Token widerrufen, kann ein Dependency-Update-Workflow ausfallen, obwohl das Repository selbst weiterhin Zugriff auf das Paket haben soll.
Der neue Weg entfernt diesen zusätzlichen Credential-Typ, wenn Quelle und Ziel bereits innerhalb von GitHub Packages und GitHub-Repositories verwaltet werden.
Das gilt nicht für alle privaten Registries. Externe Registries können weiterhin Token, Benutzername und Passwort oder je nach Anbieter OIDC benötigen. Registries in internen Netzen können außerdem selbst gehostete Runner erfordern.
dependabot.yml muss dafür nicht umgebaut werden
Wenn die Package-Berechtigung bereits über „Manage Actions access“ gesetzt ist, verlangt GitHub keine Änderung an dependabot.yml. PAT-basierte Registry-Einträge, die nur diesen GitHub-Packages-Zugriff abbilden, können entfernt werden.
Für Projekte mit mehreren internen Libraries kann das Konfiguration reduzieren. Liegen Frontend, Backend und gemeinsame Pakete in getrennten Repositories, musste bisher zusätzlich geklärt werden, welche Registry-Credentials Dependabot für jedes konsumierende Repository erhält. Jetzt kann dieselbe Repository-zu-Package-Freigabe verwendet werden, die GitHub Actions bereits versteht.
Die Dependency-Regeln bleiben davon getrennt. dependabot.yml definiert weiterhin, welche Ecosystems, Verzeichnisse und Update-Intervalle Dependabot bearbeiten soll.
Der erste Rollout wurde wegen falscher Registry-Auflösung zurückgenommen
GitHub hatte diese Funktion bereits am 23. Juni 2026 veröffentlicht und kurz danach wieder zurückgerollt.
Laut Changelog führte ein Konflikt dazu, dass manche npm-Update-Jobs öffentliche Pakete über GitHub Packages auflösten. Das Problem lag damit nicht nur bei Credentials. Die neue Authentifizierung beeinflusste in bestimmten Fällen auch, welche Registry für eine Dependency gewählt wurde.
Beim erneuten Rollout verwendet GitHub die automatische GitHub-Packages-Authentifizierung deshalb als Fallback. Explizit konfigurierte Registry-Credentials und die normale Registry-Routing-Logik haben Vorrang.
Diese Änderung ist technisch wichtiger als die reine Entfernung des PAT. Ein Authentifizierungsmechanismus sollte nicht stillschweigend die Paketquelle verändern.
Weniger Secrets ändert nicht die Zugriffskontrolle
Ein Repository mit Read-Zugriff auf ein Paket kann dieses Paket weiterhin lesen. Der Unterschied ist, dass Dependabot dafür keinen zusätzlichen persönlichen Token besitzen muss.
Bei einer Umstellung sollte deshalb zuerst geprüft werden, welche Repositories unter „Manage Actions access“ tatsächlich Zugriff haben. Danach können nicht mehr benötigte Dependabot-Secrets und PAT-Konfigurationen entfernt werden.
Der neue Mechanismus reduziert langlebige Credentials in einem konkreten Teil der Software-Supply-Chain. GitHub unterstützt bei anderen privaten Registry-Szenarien bereits OIDC, aber nicht jeder Automationspfad lässt sich damit ersetzen. Solange Bots und Build-Systeme eigene langlebige Tokens benötigen, bleiben Rotation und Ownership Teil des Dependency-Betriebs.
Quellen
GitHub Changelog, 8. September 2026: Automatic Dependabot access to GitHub-hosted registries https://github.blog/changelog/2026-09-08-automatic-dependabot-access-to-github-hosted-registries/
GitHub Docs: Configuring access to private registries for Dependabot https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries
GitHub Docs: About permissions for GitHub Packages https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages