Seguridad del código generado por IA: un 56 % de éxito y lo que puedes comprobar

Un programa que arranca y presta el servicio pedido puede tener una puerta abierta. Veracode mide desde hace dos años la seguridad del código generado por los grandes modelos y la tasa no ha cambiado. Qué cubre la cifra y los cuatro requisitos antes de publicar.

La seguridad del código generado por IA se estanca en un 56 % de éxito en las pruebas, frente al 55 % de un año antes, según el informe 2026 GenAI Code Security publicado por Veracode el 28 de julio de 2026. El mismo informe indica que el 44 % de las tareas de generación produce una vulnerabilidad.

Lo que cubre la cifra

La corrección de la sintaxis sí es un problema resuelto: los modelos escriben código que compila. Veracode somete tareas de generación a modelos y después hace pasar pruebas de seguridad al resultado. Un código puede compilar, ejecutarse y prestar el servicio pedido, y aun así fallar esta prueba. Las tasas por categoría de modelo están muy próximas: 51 % para los especializados en código, 52 % para los generalistas, 56 % para los que razonan y 53 % para los grandes, frente al 51 % de los medianos y pequeños. Elegir un modelo más grande no resuelve, por tanto, la cuestión, y el mejor probado se queda en el 68 %. El estancamiento de un punto en un año es el hecho destacado del informe: los modelos han progresado en casi todo salvo en esto.

Las vulnerabilidades donde se desploma la tasa

La media oculta una diferencia brusca según la clase de vulnerabilidad. En la inyección SQL, el ataque que desvía una consulta para leer toda una base, el código generado supera la prueba en el 83 % de los casos, y en algoritmos criptográficos en el 87 %. En cross-site scripting, la vulnerabilidad que permite a un visitante inyectar contenido que se ejecuta para otros visitantes, la tasa cae al 15 %. En inyección en registros de eventos, al 12 %. Son las vulnerabilidades más habituales de la web, las que un atacante prueba primero, y las que la generación falla con más frecuencia.

Lo que un competidor hace mejor que nosotros aquí

Lovable anunció el 5 de agosto de 2026 que cada aplicación publicada en su plataforma recibe una página de seguridad dedicada, alojada en la dirección de la aplicación, que muestra los controles de seguridad activos. La pregunta «¿es segura mi aplicación?» pasa a ser consultable en lugar de una intuición. Es un reconocimiento útil: hasta entonces, la seguridad era invisible para quien encarga el programa. Maestro no ofrece hoy un equivalente y es un requisito que conviene plantear a cualquier herramienta, incluida la nuestra.

Lo que detecta la verificación automática y lo que deja pasar

En Maestro, el agente Félix verifica cada etapa construida y las pruebas se escriben antes del código. Estas pruebas se refieren al comportamiento esperado: se crea el presupuesto, el total se redondea como estaba previsto y el usuario sin permisos no ve la página. No sustituyen un análisis de seguridad y no escribiremos lo contrario. Un programa cuyas pruebas se superan puede seguir dejando pasar contenido inyectado en un campo de comentarios porque ninguna prueba funcional piensa en pegar código en una zona de texto. El control funcional y el control de seguridad son dos oficios, y uno no exime del otro.

Los cuatro requisitos que debes plantear

Una tribuna de Yves Wattel (Delinea) publicada por el Journal du Net el 12 de agosto de 2026 enumera cuatro defensas frente a los usos ofensivos de la generación de código: mínimo privilegio, rotación de credenciales, accesos temporales y vigilancia de comportamientos. Traducidas para un directivo, dan cuatro frases para quien construye tu programa. Cada cuenta solo accede a lo que necesita, incluida la tuya. Las claves y contraseñas se cambian, y ese cambio está previsto en algún sitio en lugar de dejarse a la memoria de una persona. Los accesos concedidos a un proveedor caducan solos. Existe un registro de lo consultado y de quién lo consultó. Pedir estas cuatro cosas al principio no cuesta nada; añadirlas después de publicar supone un trabajo.

En la práctica, antes de publicar

Empieza por el control más breve: si tu base de datos es accesible desde fuera y si lo ha sido desde el primer día. Después revisa la lista de campos donde un visitante escribe texto libre (comentarios, nombres y mensajes) y pregunta qué ocurre si alguien pega algo distinto de texto. Estas dos comprobaciones caben en una noche y cubren las dos categorías donde la tasa medida por Veracode es más baja. El resto pertenece al capítulo de las trampas del desarrollo con IA y al de las cuentas que debe rendir tu programa, que ya tiene fecha.