Vous pouvez clôturer un rapport de fuite d’identifiants lorsque vous savez expliquer ce qui a mis fin à l’exposition, ce qui a invalidé l’ancien secret, ce qui empêche une récidive et ce que vous avez vérifié concernant son éventuelle utilisation abusive. Consignez séparément les preuves et les travaux restants. Une page de téléchargement devenue privée ou un déploiement réussi ne répond qu’à une partie de ces questions.

Nul besoin d’un grand service de réponse aux incidents. Il faut un responsable du rapport capable de distinguer une action terminée d’un résultat vérifié, ainsi qu’une note de clôture compréhensible sans avoir à rouvrir cinq conversations.

## Que nous apprend le cas Baseten sur la clôture d’un rapport ?

Supprimer un accès public et invalider un identifiant sont deux actions distinctes. Une récente discussion sur Hacker News en donne un exemple concret, même si l’incident est antérieur.

Dans un récit publié le 1ᵉʳ septembre, Strix explique avoir découvert en juillet un jeton GitHub encore valide dans une image de conteneur de Baseten. Selon sa chronologie, le rapport a été transmis le 13 juillet. Baseten a restreint l’accès au projet du registre le lendemain matin, mais Strix a signalé que le jeton fonctionnait toujours. Plus tard dans l’après-midi, l’équipe de sécurité de Baseten a confirmé sa rotation. Le récit salue la réaction de l’équipe et indique que les autres problèmes signalés ont été clôturés le 17 juillet. Il ne mentionne aucun test indépendant du jeton après cette rotation. [Lire le récit de Strix](https://www.strix.ai/blog/baseten-harbor-github-pat-takeover).

La [discussion sur HN](https://news.ycombinator.com/item?id=49716476) a remis ce récit en lumière. Nous tirons ici un enseignement d’un incident de juillet rendu public, sans prétendre qu’une nouvelle intrusion vient de se produire.

Pour votre équipe, la question est simple : **que signifie exactement « corrigé » dans ce rapport ?** Pour le responsable de l’infrastructure, cela peut vouloir dire que le téléchargement est bloqué. Pour celui des identités, que le jeton est invalidé. Le responsable de l’incident, lui, peut encore examiner ce qui s’est passé avant ces deux changements.

## Désignez un responsable pour chaque vérification avant clôture

Distinguez quatre vérifications pour un rapport de fuite d’identifiants. C’est la méthode de travail que nous recommandons, pas une norme officielle ni une procédure censée s’appliquer dans le même ordre à tous les incidents.

Le confinement et l’enquête peuvent avancer en parallèle. N’attendez pas un rapport parfaitement rédigé avant de prendre les mesures urgentes. Le tableau sert à suivre le travail au fil de l’intervention, sans obliger chacun à attendre son tour.

| Question de clôture | Responsable proposé | Preuves à consigner | Ce qu’elles n’établissent pas |
|---|---|---|---|
| Le contenu exposé reste-t-il accessible par la voie signalée ? | Responsable de l’artefact ou du service | Vérification d’accès sur un périmètre défini, références des artefacts concernés, heure du changement | Si quelqu’un l’a déjà copié |
| L’ancien identifiant permet-il encore un accès ? | Responsable des identifiants ou des identités | Trace de révocation chez le fournisseur et vérification adaptée menée par le responsable | Si des accès ont eu lieu avant la révocation |
| Le même processus peut-il publier un autre secret ? | Responsable de la chaîne de compilation ou de l’application | Modification du traitement des secrets et examen d’un nouvel artefact | Si toutes les copies historiques ont disparu |
| Que savons-nous des utilisations antérieures ? | Responsable de l’incident | Systèmes examinés, période couverte, résultats et lacunes des preuves | Que rien ne s’est produit hors du périmètre examiné |

Dans une petite startup, un seul ingénieur peut remplir plusieurs rôles. Indiquez tout de même son nom en face de chaque réponse. La relève sera plus simple si l’incident se prolonge au-delà d’une astreinte, de congés ou de la fin d’une mission.

Décidez qui approuve la clôture. Le responsable du rapport doit réunir les réponses, sans supposer à la place de l’administrateur des identifiants qu’un changement encore non confirmé a bien eu lieu.

## Supprimez l’exposition sans confondre nettoyage et révocation

Décrivez la suppression de l’exposition comme un résultat précis : tel fichier, telle image, tel journal ou tel point d’accès n’est plus disponible pour le public qui pouvait auparavant y accéder. Consignez la voie vérifiée et l’artefact qu’elle permettait d’obtenir.

Pour une image de conteneur, notez un identifiant stable de l’artefact en plus de son étiquette lisible. Pour un journal publié, précisez l’exécution concernée et le chemin d’accès. C’est ce que nous recommandons de consigner : « le registre est privé » renseigne moins le prochain relecteur qu’un artefact identifié et une vérification d’accès décrite.

Dans ses recommandations sur les données sensibles, GitHub place la révocation ou le remplacement du secret avant le nettoyage de l’historique du dépôt. GitHub précise aussi que réécrire l’historique a un coût et n’est pas toujours nécessaire une fois le risque d’accès supprimé. Ces recommandations portent sur les dépôts Git ; la distinction entre invalider un identifiant et supprimer ses copies aide également à raisonner sur d’autres artefacts. [Recommandations de GitHub sur la suppression de données sensibles](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository).

N’exigez pas, pour clôturer le rapport, une preuve impossible à obtenir : la disparition de toutes les copies sur Internet. Consignez plutôt la décision prise en matière de nettoyage. Une copie restante peut-elle encore révéler du code source, des données client ou un autre secret ? Si oui, révoquer cet identifiant ne résout pas ces expositions distinctes.

Conservez les preuves nécessaires à l’enquête dans un espace à accès restreint tout en supprimant les copies inutiles. Le rapport public, les échanges avec le chercheur et le dossier interne de l’incident n’ont pas besoin de contenir les mêmes détails. Désignez l’identifiant par une référence interne, sans recopier sa valeur intégrale dans chaque message.

Vos vérifications doivent rester dans le périmètre autorisé. Un rapport concernant votre service ne vous autorise pas automatiquement à tester les systèmes d’un fournisseur. Notre [guide sur le périmètre des analyses de sécurité](/blog/security-scanning-asset-scope-authorization) explique comment fixer cette limite avant de commencer.

## Établissez que l’ancien identifiant est invalidé

Avant de clôturer le rapport, vérifiez le sort de l’identifiant qui a fuité. « Nous avons créé un nouveau jeton » et « l’ancien jeton ne permet plus de s’authentifier » sont deux affirmations différentes.

GitHub indique que les jetons révoqués ou expirés ne peuvent plus servir à authentifier des requêtes Git ou API. Un événement de suppression d’autorisation peut aussi apparaître dans le journal de sécurité. La trace du fournisseur constitue donc une preuve utile, sans que la documentation garantisse le même événement visible dans tous les cas. [Expiration et révocation des jetons GitHub](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation).

Demandez au responsable de noter le fournisseur, la référence de l’identifiant, l’heure de révocation et la méthode de confirmation. Si cela s’y prête, un responsable autorisé peut effectuer une vérification limitée selon une procédure approuvée. L’essentiel est de distinguer une confirmation du fournisseur, un résultat d’authentification observé et une supposition d’un collègue.

N’ajoutez pas une obligation de nouveau test par un tiers. Le chercheur peut être indisponible ou ne pas avoir l’autorisation d’effectuer d’autres requêtes. Il revient à votre équipe d’obtenir des preuves suffisantes auprès de ses propres administrateurs et systèmes.

Les recommandations d’OWASP sur la gestion des secrets distinguent révocation, remplacement et suppression dans la réponse à un incident. Elles préconisent un confinement rapide et la possibilité de vérifier l’état de révocation. Gardez cette distinction lorsque vous préparez le changement : rétablir un service dépendant est une tâche d’exploitation ; neutraliser l’identifiant exposé est l’objectif de sécurité. [Guide OWASP sur la gestion des secrets](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#92-remediation).

Précisez toute période de transition pendant laquelle les deux identifiants fonctionnent. Désignez un responsable et une condition de fin. Un test réussi du bon fonctionnement de l’application ne remplace pas la confirmation que l’ancien identifiant a été invalidé.

## Modifiez le processus à l’origine de la fuite

L’identifiant de remplacement doit être transmis à l’application ou au processus de compilation de façon plus sûre. Sinon, la prochaine version publiée pourrait reproduire le même problème avec un nouveau secret.

Docker déconseille de transmettre les secrets de compilation par les arguments ou les variables d’environnement du Dockerfile, car ils peuvent persister dans l’image finale. Les montages de secrets recommandés par Docker rendent les identifiants accessibles temporairement, le temps d’une instruction de compilation. [Recommandations de Docker sur les secrets de compilation](https://docs.docker.com/build/building/secrets/).

La vérification `SecretsUsedInArgOrEnv` mentionne également leur persistance dans les métadonnées de l’image. C’est une bonne raison d’examiner l’artefact produit, plutôt que de relire uniquement la ligne de code modifiée. [Référence de la vérification Docker](https://docs.docker.com/reference/build-checks/secrets-used-in-arg-or-env/).

Nous recommandons une note de validation en deux parties : ce qui a changé dans le traitement des secrets et ce qui a été vérifié dans le nouvel artefact. Une revue de code peut établir que le changement paraît correct. L’examen d’un artefact nouvellement produit permet de vérifier si celui-ci contient encore le problème que vous cherchiez à supprimer.

Adaptez la vérification à la fuite. Si une compilation a écrit des URL contenant des identifiants dans un fichier de configuration, examinez ce fichier. Si une tâche de publication a exposé ses variables d’environnement, examinez le journal produit et les personnes qui peuvent y accéder. Évitez une simple mention « analyse réussie » sans préciser le périmètre de l’analyse ni l’artefact examiné.

Réévaluez aussi les accès nécessaires à l’identifiant de remplacement. GitHub recommande les GitHub Apps pour les accès au nom d’une organisation ou les intégrations durables. Si vous utilisez encore un jeton d’accès personnel, choisissez délibérément ses permissions et sa durée de validité ; changer de type d’identifiant ne prouve pas à lui seul que les accès sont adaptés. [Recommandations de GitHub sur les jetons d’accès personnels](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

D’autres travaux de sécurisation peuvent rester à mener après la correction du problème immédiat. Distinguez-les de ce que vous déclarez résolu. « La compilation concernée est corrigée ; Maya examinera les autres chaînes de compilation d’ici vendredi » est une décision utile. « Toute la gestion des secrets est désormais sécurisée » dépasse ce que ce travail permet d’affirmer.

## Examinez les conséquences et précisez les limites

La révocation permet de savoir si cet identifiant peut encore donner accès au système. Elle ne dit pas ce qui s’est passé lorsqu’il était valide.

Les recommandations de GitHub pour les enquêtes sur incident préconisent d’examiner, dans les journaux d’audit, l’activité associée au jeton compromis, les acteurs inattendus et les expositions pertinentes. Elles rappellent aussi qu’un incident peut se propager par plusieurs vecteurs d’attaque : la découverte d’un identifiant exposé peut donc conduire à élargir l’enquête. [Domaines d’enquête recommandés par GitHub](https://docs.github.com/en/code-security/reference/security-incident-response/investigation-areas).

Dans la note de clôture, nous recommandons de décrire brièvement le périmètre couvert. Précisez les systèmes examinés, la période couverte par les données disponibles, la personne chargée de l’examen et le résultat. Ajoutez ce que vous n’avez pas pu établir. Le lecteur ne devrait pas avoir à deviner si « rien de suspect » repose sur une semaine de journaux complets ou quelques heures de traces partielles.

Distinguez l’observation de la conclusion. Vous pouvez ne trouver aucune activité inattendue dans les traces disponibles, tout en n’ayant pas de visibilité sur l’ensemble de la période d’exposition. Écrivez ces deux constats. Préciser cette limite aide le responsable de l’incident à décider si d’autres travaux sont nécessaires.

Tenez compte des permissions de l’identifiant pour choisir où chercher. Un accès à la configuration de déploiement pose d’autres questions qu’un accès en lecture seule à un paquet logiciel. Consignez le raisonnement qui a déterminé le périmètre de l’enquête : un relecteur pourra ainsi le remettre en question sans tout recommencer.

Si l’enquête révèle un nouveau problème, attribuez-lui un responsable et une référence distincts. La clôture du rapport d’exposition initial ne doit pas faire disparaître un incident qui reste ouvert ailleurs. Inversement, ne laissez pas indéfiniment ouvert un rapport de chercheur dont le problème précis est résolu, sans expliquer quelle autre décision vous attendez.

## Rédigez une note de clôture vérifiable par un collègue

Une bonne note de clôture expose le résultat, les preuves et le travail restant. Elle doit être assez courte pour être lue lors d’une relève et assez précise pour pouvoir être discutée.

GitHub matérialise cette distinction dans son propre traitement des alertes : retirer un jeton d’un dépôt ne clôture pas automatiquement l’alerte de détection de secrets. Ses recommandations prévoient également un commentaire de clôture qui rejoint l’historique de l’alerte. [Résolution des alertes de détection de secrets](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-secret-scanning-alerts/resolving-alerts).

Cet **exemple est fictif**. L’organisation, les identifiants, les horaires et les résultats sont inventés pour illustrer le format ; ils ne décrivent ni Baseten ni un client de Kit.

> **Rapport :** identifiant de compilation exposé dans l’artefact `release-184`.
>
> **Exposition :** Lena a restreint l’accès à l’artefact concerné à 10 h 15 UTC. Une vérification d’accès autorisée a confirmé que la voie publique signalée ne le rendait plus accessible. Les autres artefacts ont été examinés dans le cadre de la tâche d’inventaire liée.
>
> **Ancien identifiant :** Arun a révoqué l’identifiant `build-reader-previous` à 10 h 18 UTC. La trace du fournisseur et le résultat de la vérification approuvée sont conservés dans le dossier d’incident à accès restreint. Les services dépendants utilisent désormais l’identifiant de remplacement.
>
> **Prévention d’une récidive :** Lena a modifié le traitement des secrets lors de la compilation. Le nouvel artefact et ses métadonnées ont été examinés pour rechercher le mécanisme de fuite signalé. Les preuves indiquent la référence du nouvel artefact et l’heure de la vérification.
>
> **Conséquences :** Jo a examiné les journaux disponibles du service d’identités et des dépôts pour la période d’exposition indiquée. Aucune utilisation inattendue n’y a été trouvée. Les anciens journaux de téléchargement du registre n’étaient pas disponibles ; nous ne pouvons donc pas établir qui a obtenu des copies antérieures.
>
> **Décision :** Jo a approuvé la clôture de ce rapport. La tâche liée d’amélioration de la journalisation reste attribuée à Arun. Le message au chercheur décrit les corrections terminées et les limites de l’enquête, sans inclure d’identifiants.

La note ne prétend pas que toutes les copies ont disparu, que le chercheur a personnellement confirmé chaque action ou qu’une recherche sans résultat suspect dans les journaux prouve que personne n’a accédé au système.

Vous pouvez reprendre ces rubriques comme modèle vierge. N’acceptez « sans objet » comme réponse que si le responsable en explique la raison. Si un identifiant signalé était déjà invalide, par exemple, notez comment vous l’avez établi et si l’artefact exposé contient autre chose qui nécessite une intervention.

Avant d’approuver la clôture, faites relire la note par une seconde personne si l’équipe peut le faire. Demandez-lui de repérer une phrase dont la preuve n’est pas claire. Cette courte relecture est notre suggestion pratique pour éviter les ambiguïtés lors des transmissions, pas une étape de certification obligatoire.

## Gardez la décision et les échanges dans le rapport Kit

Gardez le résumé des preuves avec le rapport pour que son statut ait une explication. Un collègue qui reprend le dossier doit pouvoir retrouver qui a confirmé la vérification du correctif et sur quoi portait cette décision.

Le cycle de vie des rapports dans Kit consigne les changements de statut avec leur auteur, la date, l’heure et un commentaire facultatif. Un membre autorisé de l’équipe peut marquer un correctif comme vérifié et ajouter une note. La [documentation sur le triage](/docs/triaging-reports) décrit ce fonctionnement.

Cette action consigne une décision humaine. **Kit ne révoque pas l’identifiant exposé, n’impose pas les quatre vérifications ci-dessus et n’exige pas de confirmation du chercheur avant ce changement de statut.** Il revient à votre équipe de réunir les preuves et de décider ce qui suffit. Résumez-les dans la note et renvoyez aux documents à accès restreint pour les détails qui doivent y rester.

La conversation associée au rapport permet les échanges internes et les messages destinés au chercheur. Conservez les détails techniques de l’enquête dans le canal approprié, puis indiquez au chercheur quelles corrections sont terminées et si les vérifications complémentaires demandées restent dans le périmètre autorisé. Le [guide de communication avec les chercheurs](/docs/communicating-with-researchers) explique ces choix de visibilité.

Pour votre prochain rapport de fuite d’identifiants, commencez par quatre rubriques : exposition, ancien identifiant, prévention d’une récidive, conséquences. Désignez les responsables pendant l’intervention. Au moment de clôturer, la note doit expliquer ce que vous savez sans laisser quiconque deviner ce que signifiait « corrigé ».

> [!CTA]
> **Essayez cette note de clôture sur un rapport.** Regroupez les responsables, la décision et les échanges avec le chercheur, puis vérifiez qu’un collègue peut comprendre le résultat à partir de ce dossier.
>
> [Démarrez votre essai gratuit](/users/sign_up)