De un hallazgo a un requisito del estándar

Un hallazgo se mapea por lo que incumple, no por dónde se vio ni con qué herramienta se encontró. Que un dato se haya visto en el manifiesto no lo convierte en un problema de almacenamiento; que un fallo aparezca en una captura de tráfico no lo convierte en un problema de red si lo que falla es una decisión del servidor. La pregunta correcta es: ¿qué requisito del estándar dice lo contrario de lo que acabo de leer?

Por eso el mapeo se hace leyendo el enunciado del control y comparándolo con la evidencia. Si el enunciado y el hallazgo hablan de lo mismo —un dato guardado, un canal sin cifrar, una pantalla invocable por otras apps— el control es ese. La herramienta que reveló el hallazgo no cuenta.

Revisar un mapeo es leerlo fila por fila con el catálogo al lado. Casi siempre el error no es un disparate sino una asociación por cercanía: el hallazgo se parece a otro de la lista y hereda su control. Un compañero con prisa asigna al grupo de almacenamiento todo lo que «está en el paquete», porque el paquete es donde guarda cosas la app.

En el laboratorio tienes los seis hallazgos, los controles candidatos y el borrador. Lee cada hallazgo, busca el control cuyo enunciado describe lo que falla, y compáralo con lo que el borrador asignó. Solo una fila asigna un control que no corresponde a lo que el hallazgo describe.

Hay un hallazgo que el borrador dejó pendiente: una biblioteca incluida en el paquete que tiene un aviso de seguridad público sin corregir. No es un fallo del código propio de la app; es un componente de terceros con una vulnerabilidad conocida. El estándar tiene un requisito específico para eso, dentro del grupo que trata de componentes, actualizaciones y validación de entradas.

Busca en los controles candidatos el enunciado que habla de componentes de software con vulnerabilidades conocidas y escribe su identificador. Así la fila deja de estar pendiente y el hallazgo queda citable.

El último hallazgo de la hoja es distinto: la API devuelve la reclamación de otro asegurado cuando se cambia el número en la petición. Eso es un fallo de control de acceso del servidor. El estándar móvil estrechó a propósito su alcance y delega lo que es del servidor en otros estándares, como el de verificación de seguridad de aplicaciones web de OWASP. El borrador, por eso, escribió «fuera del estándar».

Eso no significa que el hallazgo desaparezca. Es probablemente el más grave de la hoja, y el cliente lo necesita. Lo que cambia es cómo se cita: se deja en el informe con su propia referencia y se remite a la evaluación de la API, en lugar de forzarlo en un control móvil al que no pertenece.