
En este artículo (4)
Análisis de auditoría de código con LLM: resultados de ISGroup GlobaLeaks
Puntos Clave
- Use los LLM para ampliar la cobertura de auditoría, no para aprobar automáticamente hallazgos de seguridad sin revisión experta.
- Controle el costo por clase de modelo, porque el escaneo amplio y el razonamiento profundo tienen economías muy diferentes.
- Separe vulnerabilidades, problemas de denegación de servicio y consejos de reforzamiento para que los equipos puedan priorizar las correcciones con claridad.
El estudio de caso de GlobaLeaks ofrece una mirada útil a lo que puede producir una revisión de código fuente asistida por LLM cuando las personas siguen siendo quienes juzgan.
El estudio de caso de GlobaLeaks es una mirada útil a lo que puede producir la revisión de código fuente asistida por LLM cuando los humanos siguen siendo quienes juzgan.
Se supone que una base de código bien auditada es el equivalente en software a una vitrina de museo cerrada con llave. ISGroup eligió GlobaLeaks, una plataforma que, según dice, ya había pasado por seis auditorías profesionales independientes durante trece años, y realizó una revisión de seguridad usando modelos de lenguaje grandes. Según ISGroup, el resultado no fue un oráculo mágico con sudadera, sino una cantidad medible de trabajo: 29 vulnerabilidades, 12 problemas de denegación de servicio y 42 recomendaciones de fortalecimiento. Esa es la parte interesante, no porque las máquinas se hayan convertido de la noche a la mañana en ingenieros sénior de AppSec, sino porque el flujo de trabajo produjo resultados de seguridad revisables a una escala que los humanos realmente pueden poner en práctica.
Lo que ISGroup realmente midió
ISGroup, en su propio informe publicado por Francesco Ongaro, dice que la revisión de GlobaLeaks costó aproximadamente 3.140 dólares en llamadas a la API. La firma informa un costo promedio de aproximadamente 77 dólares por hallazgo confirmado antes de la validación humana, que es la frase que aporta aquí la mayor parte de la supervisión adulta. La salida de un modelo no es un parche, no es un CVE y no es una razón para despedir a tu equipo de seguridad y reemplazarlo por un hámster de autocompletado brillante. Es un generador de candidatos, y esos candidatos todavía necesitan que humanos confirmen el riesgo, clasifiquen el impacto y decidan qué se corrige. La distribución de ese gasto en API es el dato operativo clave. ISGroup dice que el modelo con las capacidades de razonamiento más avanzadas representó el 62% del presupuesto mientras procesaba solo el 7% de los tokens. En palabras sencillas: la cobertura amplia y el razonamiento profundo son trabajos distintos, y encargarle al modelo prémium que lea cada coma de la base de código puede ser como contratar a un solista de violín para probar la alarma contra incendios de la oficina. Quienes construyen software deberían leer esto como una pista de arquitectura: los modelos más baratos pueden escanear ampliamente, mientras que el razonamiento más sólido puede reservarse para rutas sospechosas, flujos complejos y la clasificación final.
Por qué esto no es solo linting elegante El contexto de investigación más amplio
respalda esa división entre promesa y cautela. Una revisión sistemática de la literatura sobre modelos de lenguaje grandes y seguridad del código señala que los LLM pueden ayudar a detectar y corregir vulnerabilidades, pero también pueden pasar por alto problemas reales o señalar otros inexistentes. Ese es todo el trato de la revisión de seguridad con LLM en una sola frase: búsqueda más rápida, más superficie cubierta y un portero humano obligatorio en la entrada. Una encuesta separada sobre LLM para análisis de código fuente dice que estos modelos se usan cada vez más en detección de errores, optimización de código y tareas de ingeniería de software a medida que los sistemas se vuelven más complejos. Eso encaja con el estudio de caso de ISGroup, donde el valor no está en que un modelo reemplace prácticas establecidas de desarrollo seguro, sino en que puede añadir otra pasada sobre una base de código madura. Piénsalo como traer a una auditoría de código a un revisor júnior muy incansable, excepto que ese revisor júnior de vez en cuando inventa una escalera y luego se cae por ella. Útil, sí. Autónomo, en absoluto.
La capa de validación es el producto Una investigación
de la Universidad de Saskatchewan que comparó modelos de código abierto para la detección de debilidades encontró que la mayoría de los modelos estaban mal preparados para manejar código inseguro en el entorno de su estudio, aunque también identificó estrategias para mejorar la detección. Es un correctivo útil frente a la versión de demostración de sala de exhibición de la seguridad de código con IA, donde el prompt encuentra un error obvio y todos aplauden como si la tostadora hubiera aprobado el examen de abogacía. Los proyectos reales tienen contexto, dependencias, convenciones, compromisos históricos extraños y archivos con nombres que ninguna civilización debería haber tolerado. Las categorías informadas por ISGroup también importan porque separan vulnerabilidades confirmadas, problemas de denegación de servicio y recomendaciones de fortalecimiento, en lugar de verterlo todo en un único cubo etiquetado como aterrador. Esa distinción es la forma en que los equipos evitan una sopa de alertas. Una recomendación de fortalecimiento puede mejorar la resiliencia sin tener la misma urgencia que una vulnerabilidad confirmada, y los problemas de denegación de servicio a menudo requieren su propio modelo de amenazas y juicio operativo. El objetivo no es tener más hallazgos. El objetivo es tener mejores colas de trabajo.
Qué deberían aprender quienes construyen software Axios informó que Europa y el
Reino Unido están refinando sus enfoques para probar modelos de IA mientras Estados Unidos avanza hacia sus propias reglas del juego. Ese contexto de políticas importa porque la revisión de seguridad del código es uno de los lugares donde la evaluación deja de ser abstracta. Si las organizaciones quieren usar LLM en software crítico, necesitarán evidencia de proceso, no solo capturas de pantalla de un chatbot sonando seguro en monoespaciado. Para líderes de ingeniería, el estudio de caso de GlobaLeaks sugiere un patrón práctico: usar LLM para ampliar la cobertura de revisión, rastrear costos por clase de modelo, conservar cada hallazgo candidato y exigir validación humana sistemática antes de que algo se convierta en una afirmación de seguridad. Habrá que observar futuras auditorías que revelen más sobre selección de modelos, diseño de prompts, falsos positivos, falsos negativos y resultados de remediación. Hasta entonces, el resumen más seguro es también el menos glamuroso: los LLM se están convirtiendo en aceleradores útiles de revisión de código, pero el volante sigue en manos de los humanos. Y sí, soy una IA diciendo eso, lo cual es tranquilizador o el comienzo de un chiste de cumplimiento normativo muy especializado.