Kevin Stubbings, investigador de GitHub Security Lab, publicó el 28 de septiembre un artículo explicando cómo su equipo usó el propio agente de IA de seguridad de código abierto de GitHub para auditar aplicaciones Android, encontrando y reportando en total 24 vulnerabilidades. La herramienta utilizada se llama seclab-taskflow-agent, cuyo núcleo es un conjunto de "flujos de tareas" escritos en YAML que guían paso a paso a un modelo de lenguaje para leer código, clasificar puntos de entrada, encontrar problemas y escribir pruebas de concepto.
Estos flujos de tareas ya se usaban para auditorías de código en general, y esta vez se adaptaron específicamente para móviles, con dos archivos nuevos: gather_mobile_entry_point_info.yaml y classify_application_local.yaml, encargados respectivamente de recopilar los puntos de entrada de la aplicación y de clasificar las vulnerabilidades.
Cómo funciona
Según el proceso descrito en el artículo, el usuario ejecuta un script de auditoría en GitHub Codespaces, espera unos minutos a que se inicialice el entorno y deja que el agente trabaje solo. En un repositorio de tamaño medio, el proceso tarda entre una y dos horas. Los resultados se guardan en una base de datos SQLite: basta con abrir la tabla audit_results y filtrar los registros con la columna has_vulnerability marcada para ver los puntos que el agente considera problemáticos.
Los tipos de vulnerabilidad que cubre el flujo de tareas giran en torno a varios problemas clásicos de Android: confused deputy y broadcasts inseguros relacionados con Intents, scripting entre aplicaciones en WebViews, puentes de JavaScript expuestos a páginas web, path traversal, fallos en la lógica de resolución de deep links, y filtración de cookies y tokens de inicio de sesión. Según el artículo, la lista de clasificación abarca en total 12 categorías CWE.
Dos casos explicados en detalle
OsmAnd, una aplicación de mapas y navegación de código abierto con más de 10 millones de descargas. El agente encontró 3 problemas en el proceso de importación de configuración de la app, uno de los cuales permite que una aplicación maliciosa instalada en el mismo teléfono, sin solicitar ningún permiso, importe silenciosamente una configuración mediante parámetros adjuntos a un Intent, y así rastree la ubicación y las rutas del usuario.
La aplicación Android de Wikipedia. El agente descubrió un fallo en la lógica de resolución de deep links: un atacante puede construir un enlace malicioso para llevar a la víctima a una página falsa, obtener así sus cookies y, finalmente, tomar el control de la cuenta y hacerse con un token de sesión de larga duración.
Stubbings escribe que al equipo le sorprendió lo bien que el modelo entiende el comportamiento de las API relacionadas con seguridad en distintos lenguajes, incluso sin recibir código fuente en ese lenguaje concreto; el código de prueba de concepto escrito por el agente, además, solía necesitar muy pocos ajustes para funcionar.
"LLMs are good at finding vulnerabilities but struggle at estimating severity."
Los grandes modelos de lenguaje son buenos encontrando vulnerabilidades, pero les cuesta estimar su gravedad.
Lo que todavía no logra hacer
El artículo es muy directo sobre las limitaciones. El modelo suele reportar problemas de baja severidad incluso cuando el prompt pide explícitamente no hacerlo; ante vulnerabilidades que ya cuentan con mitigaciones, calcula mal el daño real; no logra identificar problemas complejos de priorización de flujo de datos; y conseguir una prueba de concepto fiable suele requerir varias ejecuciones, a veces con un depurador conectado o instrucciones adicionales. La conclusión es que cada hallazgo debe pasar por una revisión manual de investigadores con experiencia en seguridad móvil.
En cuanto al costo, ejecutar la herramienta requiere una licencia de GitHub Copilot y consume solicitudes de modelos premium. El artículo advierte que los repositorios grandes generan un gran volumen de llamadas a herramientas, con un consumo considerable de tokens, aunque no especifica qué modelo se usó exactamente.
Para los desarrolladores en China
El flujo de tareas y los scripts son de código abierto en GitHub, así que los equipos chinos podrían adaptarlos para auditar sus propias aplicaciones Android; la barrera está en la licencia de Copilot y en el acceso a modelos extranjeros. El flujo de tareas en sí no es más que prompts y una orquestación de pasos escritos en YAML, por lo que en teoría podría sustituirse por modelos nacionales chinos, aunque de momento no existen datos comparativos públicos sobre su rendimiento.
La fragmentación de Android hace que este tipo de herramientas sea aún más útil en el mercado chino. Las tiendas de aplicaciones, los contenedores de mini-programas y los WebViews y puentes de JavaScript dentro de las "super apps" de los distintos fabricantes de teléfonos encajan justo en los tipos de vulnerabilidad que cubre esta lista. GitHub planea, como siguiente paso, ampliar el flujo de tareas a aplicaciones web y de escritorio, y abrirlo a contribuciones de la comunidad.
Fuentes: blog oficial de GitHub, CocoLoop, repositorio de código abierto de GitHub Security Lab; el número de vulnerabilidades, las descargas de OsmAnd y la duración de cada auditoría corresponden a los datos publicados en el blog de GitHub.