Dependabot lit GitHub Packages privés sans jeton personnel
Depuis le 8 septembre 2026, Dependabot peut lire des paquets privés GitHub Packages sans personal access token (PAT). La mise à jour officielle de GitHub indique que le GITHUB_TOKEN de la tâche peut demander l’autorisation packages: read lors des téléchargements depuis *.pkg.github.com et ghcr.io.
Cette possibilité ne rend pas les paquets accessibles par défaut : le paquet doit déjà avoir accordé un accès Read au dépôt consommateur dans « Manage Actions access ». Le compte rendu de Kaleido Field relève aussi que l’identifiant automatique intervient en dernier recours, après les identifiants explicites et le routage normal du registre.
Le GITHUB_TOKEN sert d’authentification de secours
Le nouveau mécanisme couvre les écosystèmes GitHub Packages pris en charge par Dependabot. Quand une tâche doit récupérer un paquet sur un registre GitHub concerné, elle peut présenter son GITHUB_TOKEN et réutiliser l’autorisation de lecture que le paquet a accordée au dépôt.
Il ne s’agit donc ni d’un accès anonyme ni d’un contournement des permissions. Le jeton est limité à la lecture du paquet autorisé : il ne rend pas celui-ci public, ne permet pas d’en publier une nouvelle version et n’étend pas automatiquement l’accès aux autres paquets privés d’une organisation.
Le caractère « de secours » protège également les configurations existantes. Si des identifiants ont été déclarés explicitement ou si une règle indique une route précise, ces paramètres conservent la priorité ; le GITHUB_TOKEN automatique ne les remplace pas au début de la résolution.
La configuration minimale se trouve dans les paramètres du paquet
Dans le cas simple couvert par cette évolution, aucune nouvelle entrée de registre n’est nécessaire dans dependabot.yml. L’administrateur du paquet ouvre ses paramètres, ajoute dans « Manage Actions access » le dépôt où s’exécute Dependabot, puis lui attribue le niveau Read.
L’accès sans PAT dépend ainsi de trois conditions cumulatives :
- la dépendance est hébergée dans un registre GitHub Packages pris en charge par Dependabot ;
- le paquet accorde au dépôt consommateur un accès Read ;
- la configuration du gestionnaire de paquets dirige correctement la dépendance vers le registre GitHub attendu.
L’autorisation s’examine pour chaque paquet dont Dependabot a besoin. L’appartenance du dépôt et du paquet à une même organisation ne doit pas être confondue avec l’autorisation explicite accordée dans « Manage Actions access ».
Une entrée fondée sur un PAT et créée uniquement pour ces paquets peut alors être retirée de dependabot.yml. Elle doit toutefois être conservée si elle fournit aussi les identifiants d’une autre source privée ou si sa déclaration reste nécessaire au routage de certaines dépendances.
Le retrait de juin répondait à un problème de routage npm
La première version, lancée en juin, avait été retirée peu après sa mise en service. Certaines tâches de mise à jour npm tentaient alors de résoudre des paquets publics par l’intermédiaire de GitHub Packages : le défaut concernait donc le choix du registre, pas seulement la validité du jeton présenté.
La version réactivée distingue désormais le routage de l’authentification. La route normale et les identifiants configurés restent prioritaires ; l’identifiant GitHub automatique n’est essayé que comme solution de repli lorsqu’une tâche atteint effectivement un registre GitHub hébergé.
Cette séparation est particulièrement importante pour npm, où un registre public peut coexister avec des portées privées et des règles définies dans .npmrc ou dependabot.yml. Une authentification acceptée ne garantit pas, à elle seule, que la dépendance a été recherchée auprès de la bonne source.
Les registres tiers exigent toujours leur propre authentification
L’exception ne s’applique pas automatiquement à Artifactory, Azure Artifacts, Nexus ou aux autres registres privés externes. La documentation des registres privés Dependabot prévoit toujours une configuration au niveau de l’organisation ou dans la clé registries de dependabot.yml, avec un jeton, un couple nom d’utilisateur et mot de passe, ou OIDC selon le type de registre et le fournisseur.
Lorsqu’un identifiant statique est référencé dans le fichier, sa valeur doit être enregistrée comme secret chiffré pour Dependabot. OIDC peut éviter un secret durable auprès des fournisseurs compatibles en utilisant des identifiants de courte durée, mais il suppose une relation de confiance configurée avec le fournisseur concerné.
L’arbre de décision est donc le suivant :
- GitHub Packages avec accès Read : le GITHUB_TOKEN de secours peut remplacer le PAT consacré à ces paquets.
- GitHub Packages sans accès Read : l’autorisation doit d’abord être accordée au dépôt ; le jeton automatique ne contourne pas ce contrôle.
- Registre privé tiers : une authentification compatible reste nécessaire, au moyen d’un secret ou d’OIDC selon le fournisseur.
- Plusieurs registres ou routage explicite : les déclarations existantes peuvent rester indispensables même si certains paquets GitHub n’exigent plus de PAT.
À ce stade, le jeton personnel devient donc facultatif dans un périmètre précis : un paquet hébergé par GitHub, compatible avec Dependabot et explicitement accessible en lecture depuis le dépôt consommateur. Aucun retrait général des secrets n’est établi pour les registres tiers, et chaque configuration mixte doit conserver les identifiants et les règles nécessaires à ses autres sources privées.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.