Un développeur a poussé par accident une clé d'accès AWS dans un dépôt GitHub PUBLIC. Quel est le bon ordre de réponse ?

Une fuite d'identifiant cloud est un incident où le chrono tourne. Des bots automatisés scrutent en continu les événements publics de GitHub, et les clés AWS exposées servent couramment à déployer des flottes de minage de cryptomonnaie en l'espace de quelques minutes après la poussée. Le réflexe du candidat doit être le confinement avant le nettoyage.

Pourquoi révoquer et faire tourner d'abord

Dès qu'un secret atterrit dans un commit public, il faut le considérer comme compromis — impossible de prouver qu'aucun bot ne l'a récupéré. Révoquer (désactiver/supprimer) et faire tourner la clé d'accès coupe l'herbe sous le pied de tout attaquant qui la détiendrait déjà. Ce n'est qu'une fois la clé active neutralisée que l'on enquête : récupérer CloudTrail pour voir ce que la clé a fait, chercher des appels d'API inattendus, de nouveaux utilisateurs IAM, des instances lancées ou des accès aux données, puis purger le secret de l'historique git (par exemple avec git filter-repo) et avertir quiconque a forké le dépôt.

Pourquoi les distracteurs sont faux

• Supprimer le commit. C'est la réponse faible classique. Une fois poussé dans un dépôt public, le commit a probablement été cloné, forké, indexé par des scanners et mis en cache par l'API d'événements de GitHub. Réécrire l'historique ne dé-divulgue pas le secret — et donne un faux sentiment de sécurité pendant qu'une clé active reste valide.
• Rendre le dépôt privé et continuer à utiliser la clé. La clé était déjà publique ; basculer la visibilité du dépôt ne fait rien contre les copies déjà prises. Continuer à utiliser une clé divulguée, c'est laisser la porte d'entrée ouverte.
• Ajouter le fichier de clé au .gitignore. .gitignore n'empêche que les fichiers futurs, non suivis d'être indexés. Il n'a aucun effet sur un secret déjà commité et poussé.

Ce que sonde l'interlocuteur

Il veut voir que vous ordonnez vos actions par réduction du rayon d'impact : tuer l'identifiant, puis enquêter, puis nettoyer. Il veut aussi la conscience situationnelle que l'exposition publique est irréversible, donc la seule hypothèse sûre est la compromission totale. Point bonus pour mentionner des contrôles compensatoires — scan de secrets en pré-commit, identifiants éphémères via des rôles IAM ou OIDC, et la protection de poussée GitHub — pour que cela ne se reproduise jamais.