Les autorisations GitHub des prestataires doivent expirer

Une équipe externe de remédiation doit recevoir le rôle GitHub le plus limité qui lui permet de terminer la tâche en cours, et ce rôle doit avoir une date d'expiration. Pour la plupart des missions, cela signifie Read pendant le diagnostic, Write pendant la réparation, aucune approbation directe de la production et une brève période en Admin uniquement lorsqu'un paramètre précis du dépôt doit changer.

Une demande vague d'« accès GitHub » transforme facilement une réparation de deux jours en autorité permanente sur le code source, les secrets, les workflows, les versions et les paramètres du dépôt. J'ai vu des propriétaires accorder Admin parce qu'ils ne savaient pas quel rôle inférieur suffirait, puis découvrir que personne n'avait consigné les changements ni pensé à retirer le compte. La méthode la plus sûre est simple : découpez la mission en phases, associez chaque autorisation à un livrable, maintenez des branches protégées entre l'équipe de réparation et la production, puis planifiez la révocation avant l'envoi de l'invitation.

Cette discipline compte encore plus avec les applications générées par l'IA. Une équipe peut devoir rechercher une authentification défaillante, des secrets exposés, une injection SQL, des modules enchevêtrés et un déploiement qui ne fonctionne que depuis l'ordinateur d'une seule personne. Ces problèmes justifient un accès étroit au code. Ils ne justifient pas automatiquement le contrôle de la facturation, des collaborateurs, des règles de branche, des webhooks, des environnements ou des identifiants de production.

Attribuez les autorisations aux tâches, pas aux titres

Les rôles GitHub décrivent une autorité, pas un niveau de confiance. Même un ingénieur externe respecté peut commettre une erreur grave avec un rôle trop large, tandis qu'un rôle bien délimité réduit le coût des erreurs honnêtes comme celui d'un compte compromis.

La documentation GitHub Repository roles for an organization classe les rôles standard dans l'ordre Read, Triage, Write, Maintain et Admin. Ses descriptions sont utiles : Read convient aux personnes qui doivent voir ou commenter un projet, Triage ajoute la gestion des tickets et des pull requests sans accès en écriture, Write permet de contribuer activement au code, Maintain couvre la gestion du dépôt sans certaines actions sensibles ou destructrices, et Admin donne un accès complet. L'erreur consiste à prendre cette échelle pour un classement professionnel. Il s'agit d'une carte des capacités.

Transformez la mission en livrables avant d'attribuer un rôle :

• Un rapport de diagnostic, un inventaire des dépendances ou une carte d'architecture nécessite généralement Read.
• Le classement des tickets, le suivi des reproductions et la coordination des pull requests peuvent nécessiter Triage.
• Les commits de réparation et les pull requests nécessitent Write, sauf si l'équipe passe par un fork.
• Les modifications des règles de branche, des collaborateurs, des environnements ou des paramètres de sécurité peuvent nécessiter Admin pendant une courte période.
• L'approbation d'une mise en production doit rester confiée à un responsable interne, même si l'équipe externe prépare la version.

Mettez cette correspondance par écrit. Un petit contrat d'accès est plus utile qu'un paragraphe dans un cahier des charges, car un responsable peut le comparer aux paramètres GitHub :

repository: acme/example-app
team: external-remediation
phase_1:
  role: read
  output: diagnosis-and-repair-plan
phase_2:
  role: write
  branches: repair/*
  output: reviewed-pull-requests
admin_window:
  allowed_changes:
    - branch-protection
    - deployment-environment
  approved_by: internal-repository-owner
  ends_at: 2026-08-15T18:00:00Z
revocation_owner: engineering-director

Ce fichier n'applique aucune règle à lui seul. Il évite le cas fréquent où le périmètre évolue dans une conversation sans que l'accès ne suive. Si l'équipe découvre qu'elle a besoin d'une nouvelle capacité, mettez le document à jour, obtenez l'approbation, puis modifiez le rôle.

Si le dépôt appartient à une organisation, ajoutez des personnes nommément identifiées comme collaborateurs externes ou utilisez une structure d'organisation adaptée, contrôlée par vos propres administrateurs. Ne partagez pas un compte fournisseur unique. Des identités individuelles donnent un sens aux revues, aux événements d'audit et à la révocation. Exigez l'authentification à deux facteurs au niveau de l'organisation lorsque votre configuration le permet, puis vérifiez que chaque personne a accepté avec sa propre identité.

Read suffit pour un audit

Un audit de code sérieux ne demande pas d'accès en écriture. L'accès Read à un dépôt privé permet à l'équipe d'inspecter et de cloner le code, d'étudier l'historique des commits, d'examiner les branches et de participer aux échanges ordinaires. Cela couvre la première passe de la plupart des missions de remédiation.

L'audit doit produire des éléments vérifiables avant toute modification du code : une carte des points d'entrée, une liste des parcours en échec, une évaluation de l'exposition des secrets, une revue des dépendances et de la compilation, ainsi qu'un ordre de réparation proposé. L'équipe peut aussi avoir besoin d'un accès en lecture à des dépôts connexes qui contiennent des paquets partagés ou des définitions d'infrastructure. Accordez explicitement ces dépôts au lieu de donner une appartenance générale à l'organisation.

Read a tout de même des conséquences. Un collaborateur peut créer un clone local, et la révocation de l'accès GitHub ne récupère pas cette copie. La documentation GitHub sur la gestion de l'accès individuel à un dépôt explique que le retrait coupe l'accès au dépôt et supprime les forks privés dans les cas concernés, mais que les clones locaux restent. Le traitement contractuel du code confidentiel, sa suppression au départ et la liste des appareils autorisés se situent donc hors des contrôles de rôles GitHub. Ne prétendez pas qu'un bouton de révocation efface des données déjà copiées.

La phase d'audit est également le bon moment pour maîtriser l'exposition des secrets. Un accès Read au dépôt ne signifie pas que l'équipe a besoin des mots de passe de base de données, des identifiants cloud, des clés de paiement ou des exports clients. Les secrets ne devraient jamais se trouver dans le dépôt. Si l'audit découvre un identifiant commité, supposez que la valeur a pu être copiée, renouvelez-la dans le système qui l'a émise et retirez-la du service actif. Réécrire l'historique Git sans remplacer l'identifiant corrige l'apparence, pas l'exposition.

Read peut devenir insuffisant lorsque le diagnostic dépend de journaux de compilation privés, de détails d'alertes de sécurité ou de systèmes externes. Traitez chacun de ces besoins comme une demande distincte. La matrice des rôles GitHub indique que l'accès à certaines listes d'alertes de sécurité commence avec Write, tandis que les résultats d'analyse de code associés aux pull requests ont une visibilité différente. N'augmentez pas le rôle entier du dépôt sans identifier la vue précise qui manque. Un responsable interne peut souvent exporter l'alerte requise, reproduire l'échec ou partager son écran sur un paramètre.

Un bon audit se termine par un point de contrôle des autorisations. L'équipe de remédiation doit nommer les fichiers qu'elle prévoit de modifier, les branches qu'elle créera, les contrôles qu'elle doit lancer et tous les paramètres du dépôt susceptibles de bloquer le plan. Ce n'est qu'à ce moment que Read doit devenir Write. Si le rapport n'explique pas pourquoi le code doit changer, davantage d'accès n'améliorera pas le rapport.

Triage n'autorise pas les réparations

Triage sert à gérer la file de travail, mais ne remplace pas Write. Il permet à un coordinateur externe de gérer les tickets, les étiquettes, les jalons, les discussions et certaines opérations sur les pull requests sans pouvoir pousser du code.

Triage constitue donc un rôle raisonnable pour un chef de projet qui reproduit les bugs, supprime les doublons, attribue le travail, demande les preuves manquantes et tient le propriétaire informé. Il est aussi utile lorsqu'une équipe de réparation distincte contribue par des forks et qu'un responsable externe doit organiser les pull requests entrantes. Le rôle sépare la coordination de la modification du code source.

Les équipes comprennent souvent mal le mot « Triage » et supposent qu'il comprend les petites corrections. Ce n'est pas le cas. Si une personne doit créer une branche dans le dépôt privé, pousser un commit, mettre à jour un workflow ou fusionner une réparation approuvée, envisagez Write. Demander sans cesse à un ingénieur interne de copier les correctifs du prestataire dans une branche crée une mauvaise traçabilité et gaspille du temps de revue. Maintenez la personne dans un véritable rôle de coordination ou accordez le rôle qui correspond à la tâche de programmation.

Triage n'est pas automatiquement plus sûr que Read pour chaque auditeur. Il ajoute la possibilité de changer la présentation et la priorité du travail. Un coordinateur malveillant ou négligent peut fermer des tickets, modifier des étiquettes ou perturber la file de revue sans toucher au code source. Ne l'accordez que si la gestion des tickets fait partie du livrable, pas parce que ce rôle semble être une option intermédiaire.

N'utilisez pas Triage pour compenser l'absence de processus. Décidez qui peut fermer les constats de sécurité, qui accepte une correction et qui communique les changements de périmètre. Une équipe externe peut marquer un élément comme prêt pour vérification interne sans être autorisée à déclarer son propre travail accepté. Cette distinction préserve l'honnêteté du dossier quand les délais se resserrent.

Pour une mission courte, Read accompagné de commentaires ordinaires sur les pull requests peut suffire pendant le diagnostic. Ajoutez Triage lorsque le volume des constats exige une gestion active de la file. Retirez-le avec le reste de l'accès de l'équipe à la fin, car un ancien compte de coordinateur expose encore les discussions privées et le code.

Write reste sur les branches de réparation

Write est le rôle normal des ingénieurs qui doivent réparer du code dans votre dépôt. Il permet une contribution active, alors associez-le à des branches protégées, à la revue des pull requests, à des contrôles automatisés et à une interdiction explicite des identifiants partagés à longue durée de vie.

Write doit ouvrir une voie pour proposer des changements, pas une voie pour redéfinir leur acceptation. Les ingénieurs externes peuvent créer des branches repair/*, pousser des commits, ouvrir des pull requests, répondre aux revues et mettre à jour la correction proposée. Des responsables internes doivent approuver les changements qui touchent l'authentification, l'autorisation, les migrations de données, les paiements, les workflows de compilation ou l'infrastructure de production.

La politique de branche fonctionnelle la plus simple comporte quatre éléments :

• Exigez des pull requests avant que les modifications n'atteignent la branche par défaut.
• Exigez au moins une approbation interne pour les chemins à fort impact.
• Exigez la réussite des contrôles de compilation, de test, de lint et de sécurité du dépôt.
• Bloquez les pushs forcés et la suppression des branches de version protégées.

Ajoutez des propriétaires de code dans les zones où une modification apparemment petite peut changer l'autorité en production. Un fichier compact peut ressembler à ceci :

/.github/workflows/ @acme/platform-owners
/auth/ @acme/security-owners
/db/migrations/ @acme/data-owners
/infra/ @acme/platform-owners

Un fichier CODEOWNERS désigne des réviseurs, mais il ne devient une barrière que si la protection de branche ou un ensemble de règles exige une revue par les propriétaires du code. Sans cette application, le fichier ne fait qu'orienter les demandes. Les équipes confondent souvent ces deux fonctions, avec pour conséquence une pull request qui semble contrôlée alors que GitHub autorise encore la fusion sans le propriétaire indiqué.

Évitez de donner à l'équipe externe un jeton d'accès personnel partagé. Chaque ingénieur doit utiliser un compte individuel, et l'automatisation doit passer par une GitHub App au périmètre limité ou par un jeton appartenant à votre organisation lorsqu'elle est réellement nécessaire. Le retrait d'un utilisateur devient beaucoup plus propre lorsque les commits, les approbations et l'activité API désignent des acteurs distincts.

Write peut exposer davantage que la modification du code. Les fichiers de workflow méritent une attention particulière, car une personne qui peut modifier un workflow d'automatisation peut influencer les commandes exécutées sur un runner ou l'utilisation des identifiants disponibles. Soumettez les changements de workflow à une revue interne, limitez les autorisations par défaut de GITHUB_TOKEN aux besoins de chaque tâche et ne considérez jamais la réussite d'un workflow comme la preuve que sa modification est sûre.

Ne laissez pas la commodité de la réparation effacer l'historique. Interdisez les pushs forcés sur les branches de réparation partagées, exigez une attribution claire des commits et demandez à l'équipe d'expliquer les changements sensibles pour la sécurité dans le corps de la pull request. Regrouper les commits à la fusion peut convenir, mais la pull request doit conserver la discussion et les contrôles qui justifient le résultat.

Admin est une exception brève et contrôlée

Admin doit rester une exception temporaire pour une tâche de configuration nommée, et non le rôle de départ d'une mission de remédiation. Il couvre des actions sensibles et destructrices, notamment la gestion des accès et des règles du dépôt, dont une réparation de code ordinaire n'a pas besoin.

Des cas légitimes existent. La protection de branche peut être absente ou mal configurée. Un environnement de déploiement peut avoir besoin d'un réviseur ou d'une restriction de branche. Certains paramètres de sécurité doivent peut-être être activés. Un webhook ou une clé de déploiement peut participer à la panne. Selon la fonction et l'offre GitHub utilisée, certains de ces changements nécessitent Admin avec les rôles standard.

La mauvaise réponse consiste à laisser Admin pendant toute la réparation parce que plusieurs paramètres pourraient demander une intervention. Utilisez une fenêtre d'élévation :

1. Le responsable externe présente le paramètre actuel exact, le paramètre proposé, la raison et le retour arrière prévu.
2. Un propriétaire interne du dépôt approuve le changement et consigne les heures de début et de fin.
3. Un ingénieur externe nommé reçoit Admin, tandis que les autres membres conservent leur rôle existant.
4. Le responsable interne observe ou examine le changement de paramètre et en garde la preuve.
5. Le propriétaire ramène l'ingénieur à Write immédiatement après la vérification.

Un administrateur interne peut appliquer le changement à partir de la recommandation écrite de l'équipe lorsque le réglage est simple. C'est souvent plus rapide que de concevoir un accès Admin temporaire. L'Admin externe se justifie davantage lorsque le diagnostic dépend d'une interaction complexe entre règles, environnements, webhooks ou contrôles de sécurité et que le spécialiste doit examiner directement la configuration.

Maintain est parfois proposé comme compromis inoffensif. Il peut gérer certaines parties d'un dépôt sans toutes les actions Admin, mais il reste plus large que la contribution au code et peut ne pas inclure le réglage sensible précis qui a motivé l'élévation. Accorder Maintain sans consulter la matrice des capacités cumule deux défauts : une autorité excessive sans rapport avec la tâche et aucune garantie que l'action nécessaire fonctionnera. Ne le choisissez que si un ensemble documenté d'opérations de maintenance correspond à la mission.

Ne donnez jamais le rôle Owner de l'organisation pour réparer un dépôt. L'Admin d'un dépôt et l'Owner d'une organisation agissent à des niveaux différents. Si l'équipe a besoin d'informations qui couvrent l'organisation, un propriétaire peut les exporter, effectuer le changement ou créer un rôle personnalisé pris en charge sur GitHub Enterprise Cloud. Une seule application défaillante ne justifie pas le contrôle de tous les dépôts et de tous les membres.

L'accès Admin rend aussi le comportement de contournement plus important. Certaines règles de protection permettent aux administrateurs de les contourner sauf configuration contraire. Si vous augmentez temporairement le rôle d'une personne, vérifiez si la règle continue de s'appliquer aux administrateurs. Le mot « protégée » ne répond pas à cette question.

La protection des branches doit survivre à la mission

Les branches protégées et les ensembles de règles doivent contraindre l'équipe externe comme vos propres administrateurs lorsque le risque l'exige. Un processus de réparation échoue si la barrière de branche disparaît chaque fois qu'une personne assez privilégiée la trouve gênante.

La documentation GitHub Managing a branch protection rule indique que les règles de branche protégée peuvent exiger l'approbation d'une pull request et la réussite de contrôles d'état. Elle avertit aussi qu'une seule règle de protection de branche s'applique à la fois, ce qui peut rendre les motifs qui se chevauchent difficiles à comprendre. GitHub propose les ensembles de règles comme solution de remplacement. Ce détail compte pendant une remédiation : l'ajout d'une nouvelle règle générique peut ne pas se combiner avec celle que vous aviez en tête. Testez donc la politique effective sur les véritables branches par défaut et de version.

Commencez par la branche par défaut et chaque branche ou étiquette capable de déployer. Exigez des pull requests, annulez les approbations périmées lorsque le code change de manière substantielle, exigez la résolution des conversations si votre pratique de revue les utilise et nommez les contrôles d'état qui bloquent réellement une mauvaise compilation. Un contrôle obligatoire qui ne s'exécute jamais peut geler les fusions, tandis qu'un contrôle dont le nom de tâche change peut cesser silencieusement de correspondre à la barrière attendue. Vérifiez le comportement avec une pull request jetable.

Gardez les listes de contournement courtes. L'équipe de remédiation ne doit généralement pas y figurer. Si une migration ou une réparation urgente ne peut pas réussir un contrôle existant, consignez la raison pour laquelle le contrôle est incorrect ou celle qui justifie une exception maîtrisée. Corriger un contrôle instable fait partie de la préparation du dépôt à la production. Le contourner pour chaque pull request ne fait que cacher le défaut.

Les règles du dépôt ne remplacent pas le jugement humain. Une compilation réussie peut confirmer la syntaxe, les tests et les scanners configurés. Elle ne peut pas décider si un nouveau parcours d'authentification respecte la politique de récupération de compte du produit ni si une migration de données préserve le sens métier. Désignez des réviseurs internes qui comprennent ces conséquences.

Examinez les règles après chaque fenêtre Admin. Comparez la configuration finale au contrat d'accès approuvé, recherchez de nouveaux acteurs autorisés à contourner les règles, confirmez que les pushs forcés restent bloqués et vérifiez que la revue des propriétaires de code s'applique aux chemins prévus. Conservez des captures d'écran ou une configuration exportée si nécessaire, mais gardez aussi une trace textuelle de la décision pour que les prochains responsables puissent la retrouver.

Lorsque FixMyMess répare une application générée par l'IA, la bonne limite d'autorisation est celle que j'exigerais de n'importe quelle équipe externe : assez d'accès pour diagnostiquer et proposer des changements vérifiés, le propriétaire du dépôt conservant les contrôles finaux. Le diagnostic du code, la réparation de la logique, le renforcement de la sécurité, la refactorisation et la préparation au déploiement proposés par la plateforme ne nécessitent pas la propriété permanente du dépôt client.

L'accès au déploiement est une décision distincte

Le rôle Write sur le dépôt ne doit pas forcément inclure le droit d'approuver un déploiement en production. Traitez la contribution au code, la modification des workflows, l'approbation de l'environnement, l'accès au cloud et la lecture des secrets de production comme des contrôles séparés.

Les environnements de déploiement GitHub peuvent exiger des réviseurs, limiter les branches ou étiquettes de déploiement et retenir les secrets d'environnement jusqu'à la réussite des règles de protection. La documentation Deployments and environments permet aussi d'empêcher l'auto-approbation. La personne qui a lancé un déploiement ne peut alors pas approuver la même tâche protégée lorsque l'option est active. Utilisez cette séparation pour les réparations externes : l'équipe prépare la version, tandis qu'un réviseur interne autorise la production.

Un flux sûr se déroule ainsi :

1. L'ingénieur externe ouvre une pull request de réparation et tous les contrôles de code obligatoires s'exécutent.
2. Les responsables internes examinent les chemins sensibles et fusionnent le commit approuvé.
3. Un workflow de déploiement référence l'environnement de production protégé.
4. Un réviseur interne contrôle le commit, le plan de migration et le retour arrière, puis approuve la tâche.
5. Le workflow reçoit les secrets d'environnement uniquement après la réussite des règles de protection.

L'environnement ne doit accepter que les déploiements issus de la branche protégée prévue ou du motif d'étiquette de version choisi. Ne supposez pas que la protection de main limite automatiquement chaque environnement. Configurez les règles de branche ou d'étiquette de déploiement de l'environnement, puis testez-les.

Soyez prudent avec les modifications de workflow. Un contributeur qui dispose de Write peut proposer un changement qui modifie les déclencheurs, les commandes des runners, les artefacts ou l'utilisation des identifiants. Exigez une revue des propriétaires de code pour .github/workflows/, réduisez les autorisations du jeton de workflow, figez les actions de confiance selon votre politique et examinez toute utilisation de runners autohébergés. GitHub précise que les runners autohébergés ne bénéficient pas d'une isolation par conteneur simplement parce qu'une tâche utilise un environnement. Un workflow peut devenir le chemin qui contourne une politique de dépôt par ailleurs prudente.

Les consoles cloud, les hébergeurs, les bases de données, les bureaux d'enregistrement de domaines et les systèmes d'observabilité possèdent leurs propres modèles d'accès. Ne placez pas ces identifiants dans un ticket GitHub et ne donnez pas un compte de production général à un ingénieur externe sous prétexte que le rôle du dépôt semble maîtrisé. Créez des identités distinctes et temporaires lorsque c'est possible, consignez leurs propriétaires et révoquez-les dans le même processus de départ.

Si l'équipe externe doit exécuter une réparation en production, exigez un approbateur interne et un retour arrière écrit. La personne qui a rédigé le changement doit l'expliquer, mais une autre doit décider s'il s'exécute sur les données réelles. Les petites équipes ne peuvent pas toujours obtenir une séparation parfaite. Elles peuvent tout de même exiger un événement d'approbation explicite et en conserver la raison, au lieu de laisser le déploiement survenir comme un effet secondaire d'une fusion.

Les preuves d'audit ont besoin d'un responsable

Un journal d'audit n'est utile que si une personne sait quels événements examiner et quelle décision le dossier doit étayer. Recueillez les preuves pendant toute la mission, pas après un changement suspect ou une révocation précipitée.

Le journal d'audit de l'organisation GitHub consigne qui a agi, quelle action a eu lieu, quand elle s'est produite et quel dépôt était concerné. La documentation indique que les propriétaires de l'organisation peuvent y effectuer des recherches et que les événements d'audit restent disponibles pendant une durée limitée. Désignez donc un responsable interne chargé d'exporter ou de conserver les preuves requises par votre politique. L'équipe externe ne doit pas être l'unique dépositaire du dossier utilisé pour évaluer son propre accès.

Utilisez une recherche enregistrée liée au dépôt, aux acteurs et aux dates de la mission. Par exemple :

repo:acme/example-app actor:vendor-engineer created:2026-08-01..2026-08-15

Le dossier de revue doit saisir des champs tels que l'action, l'acteur, le dépôt, la source et l'horodatage. Un événement normalisé compact peut ressembler à ceci :

{"action":"protected_branch.update","actor":"vendor-engineer","repo":"acme/example-app","created_at":"2026-08-04T14:22:10Z"}

Les événements disponibles dépendent de l'action et de la configuration du compte, alors testez la recherche avant le début du travail. Effectuez une modification bénigne et approuvée, confirmez que l'événement attendu apparaît et que la personne chargée de la revue peut y accéder. Découvrir après la mission que personne ne pouvait consulter le journal de l'organisation ne constitue pas une stratégie d'audit.

Auditez aussi les modifications du code source avec Git. Les pull requests doivent relier un constat à la réparation, décrire le comportement touché, identifier les tests et conserver les commentaires de revue. Les versions ou déploiements doivent pointer vers le commit fusionné. Les modifications des paramètres du dépôt nécessitent leur propre trace d'approbation, car elles peuvent ne pas apparaître dans un diff de code.

Examinez les événements d'accès à trois moments : après les invitations et l'attribution des rôles, après toute élévation temporaire et lors de la révocation. Recherchez les collaborateurs supplémentaires, les changements de rôle, les clés de déploiement, les nouvelles applications, les webhooks, les acteurs autorisés à contourner les règles, les changements d'environnement, les modifications de workflow et les voies d'accès personnelles inattendues. GitHub avertit que la suppression d'un utilisateur ne neutralise pas une clé de déploiement détenue ailleurs. Incluez donc les clés et les automatisations installées dans la revue de départ.

N'ensevelissez pas le responsable sous des événements bruts. Le dossier de preuve final doit répondre à quatre questions : qui avait accès, ce que ces personnes ont modifié, qui a approuvé les changements sensibles et si chaque voie d'accès a été supprimée ou transférée. Conservez les exports bruts selon votre politique, mais rédigez une courte liste d'exceptions qu'un futur mainteneur pourra comprendre.

La révocation commence avant le premier commit

Fixez la date de révocation au moment où vous accordez l'accès, nommez la personne qui l'exécutera et définissez ce que signifie la fin de la mission. Une date de fin enfouie dans un contrat ne retire ni un collaborateur, ni un jeton, ni une clé de déploiement, ni un compte cloud, ni un secret copié.

Utilisez un événement de calendrier ou un ticket qui s'ouvre avant la date prévue. Le responsable interne doit disposer d'assez de temps pour inspecter les branches en attente, transférer les tickets, confirmer la responsabilité du déploiement et décider si une courte prolongation se justifie. Les prolongations doivent être explicites et datées. « Ils pourraient nous aider à nouveau » n'est pas une raison de conserver l'accès à un dépôt privé.

La liste de départ doit couvrir chaque voie créée pour le travail :

• Retirez les collaborateurs externes ou l'appartenance à l'organisation accordée pour la mission.
• Révoquez l'accès des équipes, les jetons temporaires, les GitHub Apps, les clés de déploiement et les identifiants de machines devenus inutiles.
• Retirez l'équipe des listes de contournement, des propriétaires de code, des groupes de réviseurs obligatoires et des approbateurs d'environnement.
• Transférez les pull requests, tickets, procédures et responsabilités de version en cours à des responsables internes nommés.
• Renouvelez tout secret reçu par l'équipe si sa conservation continue crée un risque inacceptable.

GitHub indique que le retrait d'un collaborateur d'un dépôt privé coupe son accès et supprime les forks privés dans les cas applicables, mais les clones locaux restent. Obtenez une confirmation écrite que l'équipe a traité le code source et les données conservés conformément aux conditions de suppression convenues. Il s'agit d'un contrôle juridique et opérationnel, pas d'une fonction GitHub.

Après le retrait, vérifiez avec une nouvelle vue des accès au dépôt au lieu de vous fier à l'état du ticket. Recherchez les événements de suppression dans le journal d'audit, inspectez les applications installées et les clés de déploiement, confirmez les réviseurs d'environnement et examinez les autorisations de base de l'organisation. Une personne retirée d'une attribution directe à un dépôt peut encore hériter d'un accès par une autre voie.

Conservez l'historique de la réparation. Ne supprimez pas les branches ou les conversations uniquement pour donner une apparence propre au dépôt avant l'acceptation du travail par les responsables internes. Fusionnez ou fermez les pull requests volontairement, conservez les preuves exigées par votre politique, puis supprimez les branches obsolètes selon le processus normal du dépôt.

Une équipe de remédiation doit laisser moins d'ambiguïté opérationnelle qu'elle n'en a trouvé. Si personne ne peut nommer les administrateurs actuels du dépôt, les approbateurs de production, les identifiants actifs et la prochaine date de révocation après la fin de la mission, le code est peut-être meilleur, mais le problème de propriété demeure. Réglez les deux.