Caso práctico: de un 48/100 en MobSF a 124 correcciones de seguridad con seguimiento en nueve semanas

La mayoría de las agencias venden la seguridad como un adjetivo. Este caso práctico es un rastro documental: un banco minorista real, una puntuación real de un escáner, 48 carencias puntuadas, 124 tareas y una lista honesta de lo que sigue pendiente.

La app Android del banco está construida sobre un SDK bancario de marca blanca. Cuando el análisis del propio banco arrojó una puntuación de seguridad de MobSF de 48 sobre 100, la cuestión no era solo cómo subir el número. Era qué significaba realmente ese número, qué carencias eran reales y cómo corregirlas de forma que el equipo de seguridad del banco pudiera comprobarlo.

En este artículo repasamos cómo se realizó la auditoría, qué incluyó la remediación, cómo se verificaron las correcciones y qué sigue pendiente.

---

El punto de partida

Una puntuación de 48/100 suena alarmante, pero una puntuación bruta dice poco por sí sola. Antes de cualquier corrección, teníamos que responder a tres preguntas:

• ¿Podemos reproducir la puntuación? Si no obtenemos el mismo resultado, no podremos demostrar una mejora más adelante.

• ¿Qué hallazgos son reales? Los escáneres mezclan debilidades auténticas con ruido de la configuración del build y falsos positivos.

• ¿Qué se le escapa al escáner? Las herramientas automatizadas ven el binario, no la lógica. Los flujos de autenticación, la gestión de claves y el almacenamiento de datos necesitan una revisión humana.

📌 Idea clave:

La puntuación de un escáner es donde empieza una auditoría, no donde termina. El resultado útil es una lista de carencias reales y puntuadas, cada una con un responsable.

---

Cómo se realizó la auditoría

Fase 1: reproducir la puntuación del escáner

Rehicimos el análisis y reprodujimos el resultado del banco. Después dividimos en categorías cada punto que había perdido la app. El hallazgo que más sorprendió al banco: entre 6 y 7 de los 52 puntos que faltaban se debían únicamente al tipo de build, porque el análisis se había hecho sobre un build de depuración y no sobre el build de release que instalan realmente los usuarios. Además, dos comprobaciones que el escáner había marcado como seguras resultaron ser falsos positivos.

Fase 2: auditoría manual con el OWASP Mobile Top 10 (2024)

Revisamos la app categoría por categoría frente al OWASP Mobile Top 10 (2024), desde el uso indebido de credenciales (M1) y la seguridad de la cadena de suministro (M2) hasta el almacenamiento de datos inseguro (M9) y la criptografía insuficiente (M10). Cada carencia recibió una puntuación CVSS, para que el banco pudiera priorizar por gravedad y no por lo alarmante que sonara un hallazgo.

Resultado: 48 carencias puntuadas con CVSS.

Fase 3: un plan de remediación presupuestado

Las 48 carencias se desglosaron en 124 tareas con seguimiento. Cada cambio iba acompañado de un breve memorando por escrito sobre la amenaza y la decisión: cuál es el riesgo, qué opción elegimos, qué descartamos y por qué. Cuando el banco decidió aceptar un riesgo en lugar de corregirlo, esa decisión también quedó registrada.

Fase 4: remediación y refuerzo de la seguridad

Además de corregir los hallazgos, construimos y probamos un conjunto de controles en tiempo de ejecución y contra el abuso, entre ellos:

• Protección frente a superposiciones (overlays) en tres capas, más un clasificador para detectar el abuso de los servicios de accesibilidad.

• Inicio de sesión biométrico vinculado a un CryptoObject, para que un callback interceptado no pueda falsear un inicio de sesión correcto.

• Detección de root, Frida y emuladores, con 35 pruebas para la detección de emuladores por valores exactos y sin falsos positivos en Chromebooks.

• Protección contra el reempaquetado mediante una comprobación del certificado de firma y una comprobación del instalador.

• Borrado del portapapeles a los 60 segundos para los valores sensibles copiados.

• Solo TLS 1.3 para el tráfico de red.

• Cifrado de sobre para los datos locales en lugar de SQLCipher, lo que ahorró 6,5 MB de código nativo con un coste de alrededor de 1 ms por pantalla.

---

Cómo se verificaron las correcciones

Las correcciones que solo ha probado el desarrollador son afirmaciones, no evidencias. La verificación se hizo en dos capas.

Paquete independiente de pruebas de seguridad de QA

QA creó un paquete de verificación de seguridad de 79 comprobaciones automatizadas que cubrían 45 tickets de seguridad. Cada comprobación confirma que un control concreto funciona en un build real.

Probar las pruebas

Después probamos el propio paquete de QA con pruebas de mutación: rompimos deliberadamente controles de seguridad en builds de prueba y confirmamos que las comprobaciones detectaban cada rotura. El ejecutor detectó todos los mutantes. Igual de importante: 13 de esos mutantes habían sobrevivido a las pruebas de los propios desarrolladores, justo las lagunas que una comprobación independiente debe encontrar.

Evidencia de la cadena de suministro en CI

Cada versión se publica ahora con un SBOM en formato CycloneDX, y las dependencias se analizan con OWASP Dependency-Check. El primer análisis produjo 1.388 coincidencias brutas de CVE. Cada una se clasificó y se suprimió con un motivo fechado y por escrito, y ninguna resultó ser una vulnerabilidad real en el APK de release.

---

Resultados de un vistazo

Elemento	Resultado
Puntuación inicial de MobSF	48/100, reproducida
Puntos explicados solo por el tipo de build	6–7 de 52
Marcas de «seguro» del escáner que eran falsas	2
Carencias puntuadas con CVSS	48
Tareas de remediación con seguimiento	124
Comprobaciones de seguridad de QA	79 comprobaciones sobre 45 tickets
Coincidencias brutas de CVE clasificadas	1.388 → 0 reales
Duración	Unas nueve semanas

Lo que sigue pendiente

Publicamos las carencias junto con los resultados, porque eso es lo que hace creíble todo lo demás:

• Aún no hay una nueva puntuación final ni un pentest externo. No afirmamos haber obtenido una calificación final de MobSF, haber superado una prueba de penetración ni cumplir por completo OWASP MASVS.

• El certificate pinning está preparado y, antes de activarse, espera a la política de rotación de claves del banco.

• El análisis de dependencias informa, pero todavía no bloquea las versiones cuando hay hallazgos de gravedad alta.

---

El Mobile Security Teardown de Mobian

Este proyecto se convirtió en la plantilla de nuestro Mobile Security Teardown: dos semanas, precio cerrado. Reproducimos la puntuación de su escáner, realizamos una auditoría manual con el OWASP Mobile Top 10 (2024), puntuamos con CVSS cada carencia y entregamos un plan de remediación presupuestado que su equipo, o el nuestro, puede ejecutar.

En Mobian no somos una consultora de cumplimiento normativo y no le diremos que una auditoría le hace cumplir la normativa. Lo que entregamos es evidencia que su auditor puede seguir, hasta el archivo y la línea.

Conclusión

Una puntuación de MobSF de 48/100 le dijo al banco que algo iba mal, pero no qué. Reproducir la puntuación, auditar manualmente con OWASP, puntuar cada carencia y verificar cada corrección convirtió un número alarmante en 124 tareas trazables, cada una con su responsable. Si alguien (un banco socio, un auditor, un regulador) ya ha encontrado un problema en su app móvil, ese es el punto de partida.

Preguntas frecuentes

¿Qué abarcó la auditoría de seguridad?

Cuatro cosas: la reproducción del análisis de MobSF del propio banco, una auditoría manual de la app Android frente a las diez categorías del OWASP Mobile Top 10 (2024), una puntuación CVSS para cada carencia encontrada y un plan de remediación presupuestado. La remediación y la verificación independiente de QA se realizaron dentro del mismo proyecto.

¿Superó la app una prueba de penetración después de las correcciones?

No lo afirmamos. Todavía no se ha realizado ninguna prueba de penetración externa ni una nueva puntuación final con MobSF. Lo que sí podemos mostrar es un rastro fechado y numerado: 48 carencias puntuadas, 124 tareas con seguimiento y un paquete de QA que verifica las correcciones y que, a su vez, se probó contra builds rotos deliberadamente.

¿Basta una puntuación de MobSF para juzgar la seguridad de una app?

No. En este proyecto, entre 6 y 7 de los 52 puntos que faltaban se debían únicamente a haber analizado un build de depuración en lugar de un build de release, y dos comprobaciones que el escáner marcó como seguras eran falsos positivos. Una puntuación es el punto de partida de una auditoría manual, no un veredicto.

¿Hace este trabajo que una app cumpla DORA u otras normativas?

Mobian no es una consultora de cumplimiento normativo, y una auditoría por sí sola no hace que una app cumpla la normativa. Lo que produce es evidencia que un auditor puede seguir: hallazgos puntuados, una decisión por escrito para cada cambio, una remediación a nivel de archivo y resultados de QA independientes. Sus equipos de cumplimiento y legal deciden qué cubre esa evidencia.

¿Pueden los mismos controles proteger apps de criptomonedas o de juegos?

Muchos de ellos, sí. La protección frente a superposiciones (overlays), la detección del abuso de la accesibilidad, la detección de hooking y de emuladores y las comprobaciones contra el reempaquetado atacan patrones de abuso que son iguales en todas las apps que manejan dinero. No hemos desarrollado funciones específicas de cada nicho, como la custodia de claves o la geolocalización certificada, y lo decimos de entrada.