El informe de la evaluación móvil

La guía de pruebas pide que el informe tenga un resumen ejecutivo, el alcance y el contexto, los métodos usados, las fuentes de información, los hallazgos priorizados, los hallazgos detallados y una recomendación para corregir cada defecto. Dentro de los hallazgos detallados, cada uno responde las mismas preguntas: qué se encontró, qué requisito incumple, cómo se vio, qué impacto tiene en esta app concreta y cómo se corrige.

La evidencia es lo que separa un hallazgo de una opinión. Una captura del archivo, una línea del registro o un fragmento del manifiesto permiten que otra persona compruebe lo mismo sin fiarse de quien escribió el informe. La remediación, por su parte, tiene que cerrar el fallo, no rodearlo.

Un hallazgo sin evidencia citada es una afirmación que el cliente tendrá que aceptar por fe o rechazar por falta de pruebas. En ambos casos el informe pierde. Si el equipo vio el fallo pero no guardó la evidencia, hay que volver a obtenerla antes de entregar; si no se puede, el hallazgo baja a observación con una nota clara de que no está respaldado.

Abre la tabla de hallazgos del borrador y revisa la columna de evidencia. Uno de los cinco no cita ninguna, aunque su severidad es alta y su descripción suena razonable.

El informe del borrador tiene siete apartados esperados, con un código cada uno, y la tabla dice cuáles están presentes. Que falte uno no invalida el informe, pero algunos faltan con consecuencias: sin el alcance, nadie sabe qué se evaluó; sin los métodos, nadie puede repetir ni discutir cómo se llegó a cada conclusión. Es el apartado que permite al cliente, o a otra firma, comprobar que el trabajo se hizo como se dice.

Revisa los apartados y localiza el que el borrador no tiene. Escribe su código, no su nombre.

La severidad de un hallazgo sale de su impacto y de lo fácil que es aprovecharlo en el contexto real de la app: qué dato queda expuesto, a quién, con qué condiciones. No sale del perfil al que pertenece el control. Que un control sea de un perfil avanzado dice cuánta exigencia se esperaba de la app, no cuánto daña su fallo. Una vulnerabilidad conocida en una biblioteca puede ser grave o irrelevante según si el código vulnerable se llega a usar.

Revisa la columna de justificación de la severidad. Cada hallazgo debería explicar qué pasa si se aprovecha. Hay uno que basa su severidad en el perfil del control en lugar de en su impacto, lo que obliga a rehacer su valoración con datos de la app.

Una remediación se mide por lo que cierra. Quitar el token del registro cierra la fuga; actualizar la biblioteca cierra la vulnerabilidad. Hay medidas que parecen remediaciones y solo añaden fricción: esconder el problema o hacerlo más incómodo de encontrar no lo arregla, y quien sabe mirar lo encuentra igual. La ruta lo vio con la ofuscación: sirve de poco cuando el fallo sigue ahí.

Una de las remediaciones del borrador es de ese tipo. Busca la que propone esconder en lugar de corregir y escribe el id de su hallazgo.