Changement de propriétaire d’un dépôt : auditez les accès avant le transfert

Un changement de propriétaire de dépôt est un événement de sécurité, même lorsque le transfert ressemble à une simple tâche administrative. Le dépôt peut passer à une nouvelle équipe en une après-midi, mais les permissions qui l’entourent peuvent rester liées à d’anciens responsables, à une automatisation abandonnée, à de vieux comptes cloud et à des identifiants que personne n’a consultés depuis des mois.

J’ai vu des équipes considérer un transfert comme terminé après avoir changé le propriétaire du dépôt et retiré deux personnes de la page des collaborateurs. Puis un ancien job de déploiement continue de publier avec un jeton personnel, une clé SSH oubliée peut toujours lire du code privé ou une ancienne application d’hébergement Git conserve l’autorité de modifier les pull requests. La page du dépôt semblait propre. Le véritable périmètre de contrôle ne l’était pas.

La règle pratique est simple : ne transférez la propriété qu’après avoir identifié chaque identité et chaque service capable de produire un effet important. Par « effet important », il faut notamment entendre la lecture de code non public, l’envoi de commits, l’ouverture ou l’approbation de pull requests, la modification des définitions de compilation, l’accès aux secrets, la publication de paquets, le déploiement de logiciels et la modification des accès eux-mêmes.

Un transfert de dépôt ne transfère pas la responsabilité

Le propriétaire d’un dépôt est une étiquette administrative. La responsabilité signifie qu’une personne actuelle peut expliquer à quoi le dépôt est connecté, pourquoi chaque connexion existe, qui la gère et comment la révoquer en cas d’incident.

Ce sont deux choses différentes. Les permissions de l’hébergement Git décrivent l’accès au sein d’un seul service. Les projets modernes dépendent aussi de runners CI, de registres de paquets, de rôles cloud, d’applications d’analyse du code, de bots de publication, de systèmes de publication de documentation, de notifications de chat, de fournisseurs DNS et de stockages d’artefacts. Chaque système possède ses propres identités et sa propre mémoire du projet.

Cette distinction compte particulièrement lorsqu’un projet change d’équipe à la suite d’une réorganisation, d’une acquisition, d’une migration de plateforme interne ou d’un renouvellement des effectifs. L’équipe qui reçoit le projet se concentre généralement sur le maintien d’une compilation fonctionnelle. L’équipe qui le quitte se concentre plutôt sur la suppression de ses noms. Aucune de ces tâches ne prouve que le contrôle a été transféré en toute sécurité.

Définissez la limite de responsabilité avant que quiconque ne modifie les accès. Elle doit préciser :

• le responsable technique qui accepte la responsabilité opérationnelle
• le responsable métier qui décide qui peut accéder au code et aux publications
• le contact incident qui peut autoriser une révocation urgente
• la source de référence pour les membres du dépôt et les identités de service
• la date à laquelle l’ancienne équipe perd son autorité

N’utilisez pas une boîte aux lettres partagée ou un nom d’équipe vague comme responsable final. Un groupe peut recevoir des messages, mais il ne peut pas prendre une décision à 2 heures du matin. Identifiez des personnes précises et revoyez cette liste lorsque l’équipe change.

Il faut aussi reconnaître un point inconfortable : un projet sans responsable actuel ne doit pas conserver un accès étendu à la production sous prétexte qu’il continue de fonctionner. Si personne ne peut répondre correctement de ses identifiants de déploiement, mettez les publications en pause ou réduisez les permissions jusqu’à ce qu’une personne puisse le faire. La disponibilité ne justifie pas le maintien d’une autorité inconnue.

Construisez l’inventaire à partir des effets, pas de la page du dépôt

Un inventaire utile des accès commence par les actions qui peuvent se produire, puis remonte jusqu’aux identités capables de les provoquer. Partir de la liste des collaborateurs est plus rapide, mais cela laisse trop d’éléments de côté.

Demandez-vous ce qui peut arriver à ce projet sans qu’un développeur soit assis devant le site d’hébergement Git. Un commit peut venir d’un bot. Un workflow CI peut obtenir un jeton cloud. Un paquet peut être publié après l’apparition d’un tag. Un récepteur de webhook peut déclencher un déploiement en production. Une application de revue de code peut écrire des commentaires ou modifier des vérifications. Chaque effet correspond à une permission qui doit avoir un responsable.

Utilisez un tableau de travail à cinq colonnes : capacité, identité, emplacement de l’identifiant, responsable actuel et procédure de révocation. Cette dernière colonne est indispensable, car « supprimer le jeton » n’est souvent pas la véritable procédure. Il peut être nécessaire de désinstaller une application, de supprimer une règle de confiance cloud, d’effacer une clé de déploiement, d’invalider un jeton de registre ou de modifier un secret de webhook aux deux extrémités.

Un premier passage doit couvrir les catégories suivantes :

• Les identités humaines, notamment les collaborateurs directs, les équipes de l’organisation, les collaborateurs externes et les administrateurs de l’organisation.
• Les identités non humaines, notamment les utilisateurs machines, les comptes de service, les identités des runners CI et les installations d’applications.
• Les identifiants, notamment les clés de déploiement SSH, les jetons d’accès personnels, les clés privées d’applications, les secrets de webhook, les jetons de registre et les identifiants cloud.
• Les chemins d’exécution, notamment les fichiers de workflow, les références à des workflows réutilisables, les groupes de runners, les environnements de déploiement, les scripts de publication et les tâches planifiées.
• Les sorties de données, notamment les webhooks, la publication de paquets, la publication de documentation, les sauvegardes, les miroirs, les intégrations d’issues et les services de notification.

L’inventaire doit expliquer en langage simple à quoi sert chaque identifiant. « Jeton CI » ne suffit pas. « Lire le code source et publier le paquet interne en ligne de commande lorsqu’un tag de publication signé est envoyé » indique au prochain responsable ce qu’il doit tester et quel risque découle d’un échec.

Vous trouverez des entrées que personne ne reconnaît. Ne les laissez pas en place simplement parce que leur nom semble plausible. Demandez des preuves : où l’élément est configuré, quel job l’a utilisé récemment, ce qu’il peut faire et qui en sera responsable après le transfert. Si la réponse reste vague, planifiez sa suppression. Les identifiants inconnus ne deviennent généralement connus qu’après un incident.

Les identifiants personnels rendent un transfert fragile

Tout chemin de production ou de publication qui dépend du jeton personnel d’un seul responsable doit déjà être remplacé. Un changement de projet ne fait que révéler cette faiblesse.

Les identifiants personnels créent deux types de panne. Le premier est évident : l’ancien responsable peut conserver son accès après avoir quitté le projet. Le second est plus fréquent : son compte est désactivé ou son jeton expire, et un processus de publication tombe en panne au moment où la nouvelle équipe en a le plus besoin. Les équipes demandent souvent à l’ancien responsable de créer un autre jeton. Cela répare la panne immédiate et renforce la dépendance.

Remplacez les identifiants personnels par une identité de service seulement lorsque le service a réellement besoin d’une identité durable. Donnez-lui l’ensemble minimal de permissions nécessaire à sa tâche documentée. Un service de publication peut avoir besoin de publier un seul paquet. Il n’a pas besoin d’administrer toute l’organisation ni d’accéder à tous les dépôts.

Ne confondez pas un utilisateur machine avec une identité de service bien gérée. Un utilisateur machine est simplement un compte utilisé par une automatisation. Il peut toujours avoir un mot de passe inconnu, une adresse de récupération personnelle, une appartenance étendue et aucun responsable. Traitez-le comme une identité normale avec un cycle de vie : créez-le volontairement, documentez son propriétaire, vérifiez ses appartenances et supprimez-le lorsque sa mission prend fin.

C’est ici que le conseil populaire « utilisez simplement un seul compte d’automatisation partagé » échoue. Il est populaire parce qu’il permet de faire fonctionner l’automatisation rapidement et évite de comprendre chaque intégration. Il concentre aussi des permissions sans rapport dans une seule identité. Lorsqu’un projet change d’équipe, personne ne peut révoquer son accès sans risquer de perturber tous les autres projets qui en dépendent.

Séparez les identités selon leur fonction opérationnelle. Un lecteur de compilation, un éditeur de publications et un responsable des déploiements en production ont souvent besoin de privilèges et de responsables différents. Cette séparation rend la révocation moins risquée et l’analyse des incidents plus claire.

Vérifiez aussi les jetons appartenant aux utilisateurs en dehors de l’hébergement Git. Un script de déploiement peut lire un jeton depuis un secret CI, mais ce jeton peut appartenir au compte cloud d’une personne qui a quitté l’équipe. L’emplacement du secret ne vous renseigne pas sur son autorité. Remontez jusqu’à l’émetteur et examinez les permissions à cet endroit.

Les clés de déploiement et les installations d’applications doivent être examinées séparément

Les clés de déploiement, les applications d’hébergement Git et les intégrations OAuth donnent toutes accès au dépôt, mais elles échouent de manière différente. Les traiter comme une seule liste conduit à des révocations approximatives.

Une clé de déploiement est généralement une clé publique SSH attachée à un dépôt. Elle peut accorder un accès en lecture ou en écriture, selon sa configuration. Son avantage est son rattachement limité. Sa faiblesse tient à son identité peu précise : la clé dit peu de choses sur le système qui détient la partie privée. Si un commentaire indique « serveur de compilation » et que ce serveur a changé de mains deux fois, la fiche du dépôt ne vous aidera pas.

Pour chaque clé de déploiement, vérifiez quatre éléments : où se trouve la clé privée, quel processus l’utilise, si elle a besoin d’un accès en écriture et qui est responsable de l’hôte ou du coffre de secrets qui la conserve. Retirez le droit d’écriture aux clés qui ne servent qu’à récupérer le code source. Supprimez toute clé que vous ne pouvez pas relier à un système actif et à un responsable identifié.

Une installation d’application présente le problème inverse. Elle possède généralement une meilleure identité, des permissions et un historique des événements, mais elle peut être installée sur de nombreux dépôts. La supprimer d’un projet peut ne pas arrêter un service associé ailleurs. Examinez les permissions demandées par l’application, l’étendue de l’installation, le processus de rotation de sa clé privée, ses URL de rappel et le compte d’organisation qui peut modifier l’installation.

La documentation de GitHub sépare les clés de déploiement des GitHub Apps pour une bonne raison. Les clés de déploiement sont attachées aux dépôts, tandis qu’une application reçoit ses permissions par l’intermédiaire d’une installation et utilise ses propres identifiants. Ne supposez pas que la suppression d’une clé de déploiement affecte l’accès d’une application, ni que la désinstallation d’une application invalide une clé SSH. Ce sont deux chemins d’autorité indépendants.

Les intégrations OAuth doivent susciter la même prudence. Elles peuvent agir au nom d’un utilisateur plutôt qu’au nom d’une identité d’application dédiée. Lors d’un transfert, déterminez si l’autorisation de l’intégration dépend d’un ancien responsable. Si c’est le cas, transférez-la vers une identité de service prise en charge ou supprimez-la. Attendre le départ d’une personne de l’entreprise n’est pas un plan de révocation.

Les fichiers de workflow peuvent accorder plus d’autorité que leur nom ne le laisse penser

Un workflow qui semble exécuter des tests peut tout de même obtenir des identifiants, appeler des workflows réutilisables, écrire dans le dépôt ou déclencher des systèmes de déploiement. Lisez le fichier avant de décider que son accès est inoffensif.

Examinez toute la configuration exécutable du dépôt, pas seulement le workflow qui réalise les publications. Cela inclut les définitions CI, les scripts appelés par ces définitions, la configuration des mises à jour de dépendances, les manifestes de déploiement, le code d’infrastructure, les paramètres de publication des paquets et les scripts déclenchés par des commentaires ou des pull requests.

Soyez attentif aux endroits où un job franchit une limite de confiance. Exemples courants : un workflow qui échange un jeton d’identité contre un rôle cloud, un job qui exécute du code provenant d’une pull request avec une permission d’écriture sur le dépôt ou un workflow réutilisable provenant d’un autre dépôt. Le nom du workflow peut indiquer « analyse ». Ses permissions disent ce qu’il fait réellement.

La documentation GitHub Actions avertit que pull_request_target s’exécute dans le contexte du dépôt de base et peut accéder à des privilèges qu’un workflow de pull request ordinaire ne possède pas. Cet événement n’est pas automatiquement incorrect. Le problème apparaît lorsqu’il est associé à du code de pull request non fiable ou à des scripts qu’une personne externe peut influencer. Lors d’un transfert, repérez ces workflows et demandez à la nouvelle équipe de les accepter explicitement.

Une recherche simple dans le dépôt permet de trouver de nombreuses références évidentes. Exécutez-la localement après avoir récupéré tout l’historique nécessaire à l’examen :

git grep -nE '(AWS_|AZURE_|GCP_|TOKEN|SECRET|DEPLOY|PUBLISH|ssh |curl |webhook)' -- \\
  '.github' '.gitlab-ci.yml' 'scripts' 'infra' 'package.json' 2\u003e/dev/null

Vous pouvez obtenir un résultat de ce type :

.github/workflows/release.yml:42:  id-token: write
scripts/publish.sh:18: curl -H "Authorization: Bearer $REGISTRY_TOKEN"
infra/deploy.sh:9: ssh -i "$DEPLOY_KEY" "$DEPLOY_HOST"

La commande ne prouve pas qu’un secret existe ni qu’un job est dangereux. Elle vous fournit une liste à examiner. Reliez chaque résultat à l’émetteur de l’identifiant, à l’étendue de ses permissions et au chemin d’échec. Recherchez aussi les références à des workflows situés en dehors du dépôt, car le code peut hériter d’une autorité par l’intermédiaire d’un workflow réutilisable que ce dépôt ne contrôle pas.

N’accordez pas de permissions étendues par défaut pour faire fonctionner un workflow hérité. Corrigez les permissions déclarées du job et testez uniquement l’action qu’il doit réaliser. Un transfert est l’occasion de supprimer les permissions qui ont survécu uniquement parce que personne ne voulait perturber un ancien pipeline.

Révoquez dans un ordre qui préserve les preuves et évite les interruptions

La révocation doit suivre un ordre précis. Si vous supprimez tout d’abord, vous risquez de perdre les éléments nécessaires pour identifier une dépendance active. Si vous attendez une documentation parfaite, d’anciens accès peuvent rester en place indéfiniment.

Gelez les changements non indispensables pendant l’examen. Le responsable entrant doit savoir si une nouvelle installation d’application, une nouvelle clé de déploiement ou un nouvel administrateur de l’organisation apparaît avant la fin de la référence initiale. Cela n’exige pas d’arrêter le développement courant, mais il faut rendre les changements visibles.

Exportez ou capturez les appartenances, les listes de collaborateurs externes, les clés de déploiement, les installations d’applications, les webhooks, les métadonnées des secrets CI, les relations de confiance cloud et les événements d’audit récents. Ne stockez pas les valeurs secrètes dans ce document. Conservez les identifiants, les portées, les responsables, le contexte de création s’il est disponible et l’heure de l’examen.

Appliquez ensuite cet ordre :

1. Retirez l’accès direct des anciens responsables et réduisez les droits des anciens administrateurs de l’organisation lorsque le transfert l’exige.
2. Désactivez ou désinstallez les intégrations inconnues et révoquez les clés de déploiement sans responsable actif.
3. Remplacez les identifiants personnels connus par des identités de service, puis testez le chemin exact de compilation, de publication ou de déploiement.
4. Faites tourner les secrets partagés, comme les secrets de webhook, les clés privées d’applications et les identifiants de registre, une fois le remplacement fonctionnel.
5. Examinez les événements d’audit et les jobs en échec pendant une période adaptée au rythme de publication du projet, puis supprimez les exceptions temporaires.

Cet ordre sépare l’autorité inconnue des dépendances connues. Une clé de déploiement inconnue ne fournit aucune fonction prise en charge, elle peut donc être supprimée tôt. Un identifiant de publication connu doit d’abord être remplacé, sinon vous transformez une correction de sécurité en interruption évitable.

Prévoyez une procédure de secours délibérée en cas d’échec du remplacement. Elle doit préciser qui peut rétablir le service, combien de temps l’exception reste valide et comment l’équipe la consigne. Ne réactivez pas le jeton étendu d’un ancien responsable parce qu’une publication est en retard. Créez un identifiant temporaire aux permissions limitées sous la responsabilité de l’équipe actuelle, consignez l’exception et supprimez-la après la réparation.

L’accès des agents doit suivre la même limite de responsabilité

Les agents de programmation autonomes peuvent modifier du code, appeler des API, utiliser SSH, publier des artefacts et agir sur l’infrastructure grâce aux outils qui leur sont associés. Un transfert de dépôt qui ignore l’accès des agents laisse une importante faille dans l’examen.

Ne demandez pas seulement quelles personnes peuvent lancer un agent. Demandez quels processus d’agent peuvent agir pour le dépôt, quels outils ils peuvent appeler, quels identifiants ces outils utilisent et si un responsable peut reconstituer une action précise par la suite. Un agent exécuté depuis le terminal d’un développeur, un job CI ou un runner distant peut avoir une autorité différente même s’il utilise le même modèle.

Gardez les identifiants persistants hors des invites et des fichiers de travail de l’agent. Transmettre un secret par des variables d’environnement ou la sortie d’un outil le rend accessible aux journaux, aux sous-processus, aux commits accidentels et au contexte propre de l’agent. Masquer une valeur dans un seul lecteur de journaux ne sécurise pas la frontière du processus.

Pour les équipes qui utilisent Sallyport, l’application Mac peut conserver les identifiants HTTP et SSH dans son coffre chiffré, tandis qu’un agent compatible avec MCP demande une action par l’intermédiaire de son shim local, sans recevoir lui-même l’identifiant. Ses journaux de session et d’activité donnent au responsable entrant des enregistrements distincts des sessions d’agent et des appels individuels, ce qui est plus utile qu’une transcription lorsqu’un transfert doit être examiné.

Pendant la transition, révoquez les sessions d’agent liées aux anciens postes ou processus et demandez au nouveau responsable d’approuver les nouvelles sessions. Examinez ensuite l’utilisation de chaque identifiant : une récupération du code source en lecture seule et un déploiement en production ne doivent pas être soumis au même niveau d’approbation. Le but n’est pas de rendre chaque commande pénible. Il est de rendre les appels puissants visibles pour la personne qui assume leurs conséquences.

L’inventaire écrit des agents doit préciser l’étendue du dépôt, le lieu d’exécution, les canaux d’outils, le propriétaire de l’identifiant, le responsable de l’action et l’action de révocation d’urgence. Si vous ne pouvez pas remplir ces champs, l’agent possède un accès que le projet ne peut pas transférer de manière responsable.

Les journaux d’audit doivent indiquer qui a modifié le contrôle

Un journal qui indique seulement « jeton utilisé » ne suffit pas après un changement de propriétaire. Vous devez savoir à qui appartenait le jeton, quel processus l’a utilisé, ce qu’il a fait, quel dépôt il a ciblé et si l’action était autorisée dans le cadre de la nouvelle responsabilité.

Conservez ensemble les événements d’audit du dépôt, les enregistrements d’exécution CI, les journaux d’audit cloud, les événements du registre de paquets et les enregistrements des actions des agents dans le dossier de transfert ou le système d’incident. Ils n’auront pas le même format, ce qui n’est pas un problème. L’essentiel est d’utiliser une référence temporelle commune et suffisamment d’identifiants pour suivre un événement d’un système à l’autre.

Testez les enregistrements avant de déclarer le transfert terminé. Effectuez une modification sans risque par chaque chemin pris en charge : un push normal d’un développeur, un événement d’automatisation de pull request, une tâche planifiée si elle existe, une publication de paquet vers une destination hors production si possible et une action d’agent nécessitant une approbation. Vérifiez que la nouvelle équipe peut retrouver les preuves sans appeler les anciens responsables.

Les preuves d’altération sont utiles, mais elles ne remplacent ni la conservation ni le contrôle des accès. Un journal en ajout seulement vous indique si quelqu’un a modifié un enregistrement. Il ne vous aide pas si la source de l’événement n’a jamais enregistré l’appel, si la durée de conservation du journal a expiré ou si aucune personne actuelle ne peut le consulter pendant un incident.

Fixez une date de revue après le transfert. La première revue détecte l’automatisation qui ne s’exécute que chaque semaine ou chaque mois, et la seconde révèle les personnes qui demandent une exception parce qu’un élément a cessé de fonctionner. Ces exceptions sont des informations utiles. Chacune révèle une dépendance que l’inventaire initial n’avait pas repérée.

La nouvelle équipe doit pouvoir supprimer chaque chemin d’accès

Un transfert est terminé lorsque la nouvelle équipe peut révoquer chaque chemin d’accès important sans avoir besoin que l’ancienne équipe explique un secret, localise une machine ou approuve une modification. Cette exigence est plus stricte qu’une fenêtre de transfert de dépôt et évite l’échec qui se répète : la propriété du code change sur le papier, tandis que le contrôle reste dispersé ailleurs.

Commencez par l’élément le moins prestigieux, l’inventaire des accès. Placez un responsable et une procédure de révocation à côté de chaque service connecté. Supprimez ensuite les entrées qui n’ont ni l’un ni l’autre. Le travail paraît fastidieux jusqu’à la première rotation urgente d’un identifiant. À ce moment-là, l’inventaire fait la différence entre une réparation maîtrisée et une semaine passée à deviner.