Auditoría de dependencias y fallos lógicos con LLMs

Un escáner SAST convencional busca firmas conocidas (por ejemplo, el uso de la función eval o una concatenación simple en una consulta SQL). Sin embargo, si una vulnerabilidad surge porque una función en el archivo A valida los permisos pero el archivo B asume que la comprobación ya se hizo y despacha el saldo bancario, el escáner SAST no detecta nada anómalo. Los modelos de lenguaje, al procesar lenguaje y contexto de ejecución, destacan encontrando estas discrepancias lógicas entre distintas partes del código.

En una revisión asistida, el operador pide al modelo rastrear una variable desde su punto de entrada (por ejemplo, un parámetro JSON recibido en el controlador web) hasta su punto de consumo en una llamada al sistema o base de datos. El modelo ayuda a seguir el rastro a través de tres capas de abstracción (servicios, repositorios, utilidades), señalando si en algún punto intermedio la validación de tipos o saneamiento fue omitida.

Muchas aplicaciones empresariales dependen de librerías empaquetadas en binarios (archivos JAR de Java, DLLs de .NET) que no tienen código fuente disponible. Tras descompilarlas a código intermedio, el resultado suele ser código sin comentarios y con variables ofuscadas. Un modelo de lenguaje es capaz de desofuscar y explicar qué hace cada clase, permitiendo al auditor entender la arquitectura interna de la librería y encontrar vectores de ataque ocultos.

Un modelo de lenguaje tiende a sobrestimar la explotabilidad: puede ver una concatenación de cadenas y afirmar con total seguridad que existe una inyección SQL crítica, sin darse cuenta de que la variable concatenada es un entero validado previamente en la línea anterior. El deber del auditor es reproducir el flujo con una prueba de concepto en el entorno de laboratorio antes de reportar el hallazgo.