Desarrollo de apps3 min de lectura

Lo que realmente le dice su puntuación de MobSF

La puntuación de MobSF no es un veredicto de seguridad. Cómo la distorsionan el tipo de build, los falsos positivos y los puntos ciegos, y qué hacer después.

Un socio de seguridad, un auditor o su propio equipo pasa MobSF por su app y aparece un número: por ejemplo, 48 sobre 100. La reacción natural es preguntar cómo subirlo a 80. La pregunta acertada es de qué está hecho realmente ese 48.

En este artículo explicamos qué mide la puntuación de MobSF, las tres formas en que induce a error y cómo convertir el informe de un escáner en hallazgos que alguien pueda asumir y corregir, con cifras reales de una auditoría que realizamos a una app bancaria.


Qué mide MobSF

MobSF (Mobile Security Framework) analiza de forma estática el binario de una app. Lee el manifiesto, descompila el código, enumera las bibliotecas y contrasta la configuración con un conjunto de reglas. Cada regla que falla resta puntuación.

Eso hace que MobSF sea rápido, reproducible y útil. También significa que la puntuación refleja patrones en el binario, no lo segura que es la app cuando se usa.

📌 Idea clave:

La puntuación de MobSF responde a «¿cuántas reglas ha incumplido este binario?», no a «¿qué tan difícil es atacar esta app?».


Tres formas en que la puntuación induce a error

1. El tipo de build cambia la puntuación

Los builds de depuración incluyen ajustes que un build de release no debería tener: flags de depuración, configuración de pruebas, registros detallados y más. Si analiza el build equivocado, está puntuando algo que sus usuarios nunca instalan.

En la app bancaria que auditamos, entre 6 y 7 de los 52 puntos que faltaban se debían únicamente al tipo de build. Antes de que nadie cambiara una sola línea de código, parte del problema era simplemente qué archivo se había analizado.

2. «Seguro» no siempre es seguro

Las reglas estáticas buscan patrones. Cuando el código parece una implementación correcta, la regla se da por superada, aunque el control no funcione como aparenta. En la misma auditoría, dos comprobaciones marcadas como seguras eran falsos positivos. Una marca verde es una afirmación que hay que verificar, no una conclusión.

3. El escáner no ve la lógica

Algunas de las debilidades móviles más graves están en la lógica, no en la configuración:

  • Un flujo de autenticación que confía en un indicador del lado del cliente.

  • Un inicio de sesión biométrico que solo comprueba un callback de éxito.

  • Datos sensibles escritos en el almacenamiento, en un lugar que las reglas no inspeccionan.

Ninguno de estos casos altera de forma fiable una puntuación estática. Requieren una revisión humana.


Cómo leer correctamente un informe de MobSF

  1. Reproduzca la puntuación con el build de release. Sin una línea base reproducible, no se puede demostrar ninguna mejora.

  2. Divida los puntos perdidos en categorías: ruido del tipo de build, carencias reales de configuración y hallazgos que necesitan contexto.

  3. Verifique las marcas verdes en todo lo que sea crítico para la seguridad.

  4. Realice una auditoría manual con el OWASP Mobile Top 10 (2024) como referencia para cubrir lo que el escáner no ve.

  5. Puntúe cada carencia real con CVSS, para que las prioridades sigan la gravedad y no el volumen.


Puntuación frente a hallazgos

Aspecto Puntuación bruta de MobSF Hallazgos auditados
Qué cuenta Reglas incumplidas por el binario Debilidades reales y verificadas
Ruido del tipo de build Incluido Eliminado
Falsas marcas de «seguro» Ocultas Identificadas
Fallos de lógica Casi siempre invisibles Cubiertos por la revisión manual
Priorización Ninguna Puntuación CVSS por carencia

Cómo ayuda Mobian

En Mobian, la auditoría detrás de estas cifras partió de una puntuación de 48/100 y terminó con 48 carencias puntuadas con CVSS y 124 correcciones con seguimiento. Si ya tiene un informe de MobSF, podemos darle una lectura de una página sobre qué es real, qué es ruido y qué merece una segunda mirada. Para una visión completa, nuestro Mobile Security Teardown de dos semanas añade una auditoría manual según OWASP y un plan de remediación presupuestado.

Conclusión

MobSF es una buena herramienta usada para la tarea equivocada cuando su puntuación se toma como un veredicto. Analice el build de release, separe el ruido de los hallazgos, verifique las marcas verdes y audite la lógica a mano. El número importa menos que la lista de carencias reales y puntuadas que se obtiene de él.

Preguntas frecuentes

¿Qué es MobSF?

MobSF (Mobile Security Framework) es una herramienta de código abierto que analiza los binarios de aplicaciones Android e iOS. Su análisis estático inspecciona el manifiesto, el código, las bibliotecas y la configuración, y genera un informe con una puntuación de seguridad de 0 a 100.

¿Por qué cambió mi puntuación de MobSF entre dos análisis de la misma app?

La causa más habitual es el tipo de build. Un build de depuración incluye ajustes, como los flags de depuración y la configuración de pruebas, que un build de release no tiene, y el escáner los penaliza. En una auditoría que realizamos, entre 6 y 7 de los 52 puntos que perdía una app se debían únicamente al tipo de build. Analice siempre el build que instalan sus usuarios.

¿Puede estar equivocada una comprobación de MobSF marcada como segura?

Sí. El análisis estático busca patrones; no entiende la intención. En la auditoría de una app bancaria, dos comprobaciones que el escáner daba por seguras eran falsos positivos. Toda comprobación importante, superada o no, merece una revisión manual.

¿Qué no detecta MobSF?

El análisis estático ve el binario, no la lógica de negocio. No puede juzgar si un flujo de autenticación se puede eludir, si un inicio de sesión biométrico está vinculado a una clave o si los datos sensibles se almacenan correctamente en su contexto. Para eso hace falta una auditoría manual, por ejemplo con el OWASP Mobile Top 10 (2024) como referencia.

¿Puede Mobian explicarnos nuestro informe de MobSF?

Sí. Si nos envía su propio APK o su informe de MobSF, le devolvemos una lectura de una página sobre qué es real, qué es ruido del tipo de build y qué puede ser un falso visto bueno de seguridad. Solo lo hacemos cuando lo pide el propietario de la app: nunca analizamos la app pública de una empresa sin que nos lo solicite.

Estimación gratuita · sin compromiso

¿Planea un desarrollo con este stack?

Hemos trabajado con las herramientas sobre las que escribimos. Cuéntenos su proyecto y obtenga una segunda opinión de ingenieros que ya las han usado en producción.

  • 1Revisamos su producto, su stack y su roadmap
  • 2Le señalamos los riesgos que hemos visto en proyectos similares
  • 3Recibe una propuesta de equipo y un calendario estimado en 48 horas

Cuéntenos sobre su proyecto

¿Prefiere hablar primero? Reserve una llamada de 30 minutos