¿Es usted CISO o líder de ingeniería y le preocupa la seguridad y el costo de la generación de código mediante LLM?

Consulte el SCW AI Trust Index, nuestros datos patentados de evaluación comparativa de LLM, antes de apostar todo por un modelo de IA

El sector de la ciberseguridad está desbordado. Herramientas como Mythos de Anthropic (y Fable 5, que fue rápidamente bloqueado y luego liberado) están impulsando a muchos líderes de seguridad a ampliar sus programas con rapidez para seguir el ritmo de los vertiginosos cambios en la velocidad de explotación, por no mencionar el volumen mucho mayor de código generado gracias a la tecnología de IA.

En estas circunstancias, puede resultar tentador sumergirse en medidas de seguridad preventivas (y, seamos sinceros, reactivas) para combatir la supuesta avalancha de riesgos de brechas impulsadas por la IA. Sin embargo, hoy existe un problema mucho más generalizado que probablemente afecte a todos los CISO: la elección de los modelos LLM en los entornos de producción de software. Aunque las consecuencias de la IA en la sombra están bien documentadas, esto es solo una parte del preocupante panorama de riesgos. No deberíamos pagar tokens para generar código, pagar más tokens para usar la IA para encontrar problemas de seguridad en el código y luego volver a pagar tokens para generar y aplicar correcciones de seguridad. Todos los modelos de IA son susceptibles de producir debilidades y vulnerabilidades a diferentes ritmos, especialmente al comparar el rendimiento entre marcos de trabajo o lenguajes de programación. En este aspecto, es necesario determinar qué modelo es el adecuado para respaldar la pila tecnológica, los lenguajes y los marcos de trabajo existentes, y esta información ha sido difícil de obtener, hasta ahora.

Secure Code Warrior se asoció con investigadores clave de la RMIT University, y hemos pasado meses planteando una pregunta engañosamente sencilla: cuando entregas tu base de código a un modelo de IA, ¿cuánta vulnerabilidad de seguridad estás heredando exactamente? La respuesta, basada en nuestro estudio empírico de más de 1700 bases de código de aplicaciones completas generadas a través de modelos líderes de vanguardia y económicos, y once marcos de lenguaje, es: más de lo que crees, y de formas que te sorprenderán.

Estas son las cinco conclusiones que debes extraer de nuestro informe de investigación a medida que llevas tu programa de seguridad a la era de la IA:

1. El coste no es un indicador de seguridad.

Es tentador asumir que pagar más garantiza un código generado más seguro. Nuestros datos muestran que la realidad es más compleja. GPT 5.1 obtuvo la puntuación de seguridad normalizada más alta en nuestro estudio original (79,6 sobre 100) con un coste promedio de 5,60 $ por ejecución. Claude Sonnet 4.5 obtuvo 71,2, una puntuación significativamente menor, con un coste de 43,99 $ por ejecución. Eso es casi 8 veces más caro para un resultado de seguridad peor.

La brecha de costes no se debe solo al precio por token. Los modelos de Anthropic ejecutaron significativamente más turnos de llamadas a herramientas dentro del bucle de codificación agente, generando 176 millones de tokens de salida en las ejecuciones de Sonnet 4.5 en comparación con los 42 millones de GPT 5.1, por ejemplo. Más actividad, más tokens y más costes no proporcionaron más seguridad. El presupuesto no es calidad, así que no dejes que sustituya a la medición.

2. Cada modelo tiene una huella de vulnerabilidad.

A través de más de 1700 bases de código y 16 modelos, identificamos 83 categorías únicas de CWE con hallazgos validados como positivos verdaderos. No son aleatorios; cada modelo exhibe un patrón sistemático que persiste independientemente del marco de trabajo o lenguaje. En nuestro estudio original de 6 modelos, 39 de las 87 categorías CWE identificadas fueron producidas por todos y cada uno de los modelos probados, lo que demuestra que un gran núcleo de tipos de vulnerabilidad es independiente del modelo, no específico del proveedor. Los modelos Claude de Anthropic, por ejemplo, mostraron una tendencia recurrente hacia credenciales codificadas de forma rígida (CWE-798). Gemini 2.5 Flash dejó constantemente código de depuración en las compilaciones de producción (CWE-489).

Estas huellas sugieren sesgos impulsados por los datos de entrenamiento o la alineación, más que ruido aleatorio. Esa previsibilidad es realmente útil: una vez que conoces los puntos ciegos de tu modelo, puedes configurar reglas de escaneo específicas y comprobaciones posteriores a la generación en torno a ellos.

3. Algunas vulnerabilidades son universales... y ningún modelo probado las evita.

Por ejemplo, uno de los hallazgos más generalizados en nuestro índice actual es CWE-532 (Inserción de información confidencial en archivos de registro), y ha aparecido como un positivo verdadero 6765 veces.

Todos los modelos trabajaron a partir de la misma especificación de aplicación común, el tipo de resumen en lenguaje sencillo que un equipo de producto escribe cada día, no una lista de verificación de seguridad ni un prompt simplificado diseñado para inducir al error. En lugar de indicar un caso extremo exótico, la mayoría del resto de las vulnerabilidades muestran fallos por omisión: credenciales dejadas en el código fuente, valores predeterminados demasiado permisivos, falta de comprobaciones de autorización; el tipo de brecha que se cierra en el momento en que la solicitas explícitamente, porque el modelo no la deducirá por sí solo a partir de una especificación común. La excepción es el hallazgo más importante: el registro de datos confidenciales no es algo que los modelos olvidaran añadir, es algo que escribieron activamente, sin que se les pidiera, de la misma manera que podría hacerlo un desarrollador humano poco cualificado. Esto es algo que el modelo hace voluntariamente, sin que un humano le pida explícitamente que adopte ese comportamiento. El modelo implementa fielmente lo que se describe en el prompt, incluyendo todo lo que no se menciona desde una perspectiva de refuerzo de la seguridad.

4. El contexto del marco de trabajo moldea el rendimiento del modelo.

Este hallazgo debería cambiar la forma en que las organizaciones piensan sobre el desarrollo asistido por IA. El estudio deja claro que las fortalezas de los modelos varían según las pilas tecnológicas. Un modelo que funciona bien en un marco de trabajo puede tener un rendimiento inferior en otro, por lo que los equipos deben evaluar los modelos donde realmente se van a utilizar.

En nuestro SCW AI Trust Index actual, la brecha entre marcos de trabajo empequeñece a la que existe entre modelos. JavaScript Basic (agregado a través de los 13 modelos que hemos probado) conlleva una puntuación de riesgo total de 6770. C#/.NET Basic, el marco de trabajo más seguro del estudio, se sitúa en solo 111. Es una diferencia de 61 veces en el riesgo de seguridad, impulsada únicamente por la elección del marco de trabajo.

Nuestro estudio original encontró la razón probable: los marcos de trabajo con valores predeterminados de seguridad definidos (por ejemplo, C# con los tokens antifalsificación integrados de ASP.NET o el modelo de seguridad declarativo de Java Spring) produjeron un código drásticamente más seguro, independientemente del modelo que lo generara. Los entornos sin procesar como JavaScript Basic amplifican las diferencias entre modelos de forma catastrófica. Elige tu marco de trabajo con intención de seguridad desde el principio, si es posible, en tu organización.

5. Ningún modelo es superior en todos los casos; la selección del modelo debe considerar el framework utilizado.

En nuestro estudio original, GPT 5.1 lideró los resultados generales, pero quedó último en Swift para iOS. Sonnet 4.5 generó el código Java Spring más seguro de todo el estudio, pero ocupó el último lugar en la API de Java EE. Gemini 2.5 Pro dominó en Python y Swift, aunque tuvo un desempeño mediocre en Java. No existe un modelo universalmente seguro.

Las organizaciones con bases de código políglotas deben aceptar los puntos ciegos específicos de cada modelo en su stack o adoptar una estrategia de enrutamiento que asigne cada framework al modelo con el perfil de seguridad más sólido para ese contexto. Independientemente del modelo elegido, el escaneo de seguridad es obligatorio. Incluso el modelo con mejor desempeño generó vulnerabilidades validadas en todos los frameworks que probamos.

La presión por los costos no desaparecerá. A medida que los flujos de trabajo de agentes escalan, también lo hace la factura: más llamadas a herramientas, más ciclos de regeneración y más tokens por tarea. Es probable que el aumento de los costos por tarea y por token lleve a algunas organizaciones a optar por modelos más antiguos o económicos para controlar el gasto. Nuestros datos indican que esta decisión debe basarse en evidencia, no en intuición: GPT 5 Mini fue el modelo más barato de nuestro estudio original y, a la vez, el menos seguro. La presión de costos es real y debe impulsarle a medir en lugar de adivinar.

La cuestión nunca ha sido si es necesario escanear; los líderes de seguridad deben priorizar la recopilación de datos adecuados, señales de riesgo y observabilidad de IA para saber qué es lo que realmente deben analizar. Aquí es donde la gobernanza de IA desempeña un papel fundamental, y contamos con una solución integral para ofrecer esta información vital ahora mismo. ‍

‍

>>> MÁS INFORMACIÓN: SCW Trust Agent: IA
>>> DESCARGAR: eBook
>>> DESCUBRIR: Nuestro micrositio de benchmarking (el informe completo se enlazará aquí)