Imagina esta escena.

Un equipo de desarrollo recibe una alerta de seguridad sobre una posible vulnerabilidad.

El aviso entra en la cola. Alguien tiene que revisarlo. Después hay que comprobar si el fallo es real, reproducirlo, entender qué parte del código lo provoca, preparar una corrección y asegurarse de que ese cambio no rompe nada más.

No es un proceso especialmente llamativo, pero consume muchas horas entre Desarrollo y Seguridad.

Y es precisamente ahí donde la IA empieza a cambiar las cosas.

AWS publicó recientemente nuevos resultados de AWS Continuum for code vulnerabilities, un sistema multiagente que ha sido probado sobre CyberGym-E2E, un benchmark diseñado para evaluar todo ese recorrido: descubrir una vulnerabilidad, demostrar que puede explotarse, generar un parche y comprobar que el software sigue funcionando.

Continuum completó correctamente 819 de 920 tareas, un 89 % en la principal métrica end-to-end del benchmark.

Pero la cifra no es lo más interesante.

Lo importante es lo que la IA tuvo que hacer para conseguirla.

De lanzar una alerta a investigar el problema

Estamos acostumbrados a herramientas que analizan código y avisan:

“Aquí podría haber una vulnerabilidad.”

El trabajo de verdad empieza después.

¿Es realmente explotable?
¿Podemos reproducirla?
¿Dónde está la causa?
¿Cómo la corregimos?

En CyberGym-E2E, el agente no recibe la descripción de la vulnerabilidad ni el parche original. Tiene que encontrar el problema, crear una prueba que lo demuestre y generar una posible solución. Después se comprueba si el fallo desaparece y si el proyecto continúa superando sus pruebas.

La diferencia es importante.

Ya no hablamos solo de una IA diciendo:

“Aquí veo algo raro.”

Empieza a poder decir:

“Este es el problema, esta es la prueba y esta es una posible corrección.”

Para un profesional de AppSec o DevSecOps, eso significa comenzar la investigación varios pasos más adelante.

¿Entonces la IA ya puede arreglar nuestro código de forma autónoma?

No exactamente.

El resultado es relevante, pero hay que ponerlo en contexto.

CyberGym-E2E trabaja con vulnerabilidades reales procedentes de proyectos open source, pero está especialmente centrado en problemas de seguridad de memoria en C y C++. No representa todos los lenguajes, arquitecturas ni tipos de vulnerabilidades que encontramos en una empresa.

Y hay algo todavía más importante.

La IA puede analizar el código.

Pero no conoce automáticamente todo lo que ocurre alrededor.

Una vulnerabilidad puede estar en un servicio aislado o en un componente conectado a información crítica. Una corrección puede funcionar técnicamente y, al mismo tiempo, afectar a otro proceso del negocio.

El código cuenta una parte de la historia.

El contexto cuenta el resto.

El momento delicado llega cuando dejamos que actúe

Supongamos que el agente encuentra una vulnerabilidad, consigue reproducirla, prepara una corrección y los tests indican que todo sigue funcionando. En ese punto aparece la pregunta realmente importante: ¿aplicamos el cambio automáticamente o necesitamos que una persona lo revise antes? Ahí es donde la conversación deja de ser puramente técnica y pasa a hablar de confianza, riesgo y nivel de autonomía.

AWS plantea un modelo de autonomía progresiva: empezar con acciones propuestas para que una persona las revise y permitir después determinados niveles de automatización dentro de límites definidos.

Y tiene sentido.

No debería tener el mismo nivel de autonomía una corrección sobre un entorno de desarrollo que un cambio sobre un sistema crítico en producción.

Cuanto más capaz sea el agente, más importantes serán los guardrails:

• • qué puede modificar;

• • dónde puede hacerlo;

• • qué pruebas debe superar;

• • quién aprueba el cambio;

• • y cómo volvemos atrás si algo falla.

La parte difícil deja de ser únicamente construir una IA capaz de actuar.

También hay que decidir cuánto queremos dejarla actuar.

Los tests se vuelven todavía más importantes

Hay una paradoja interesante.

Cuanto más avanzada es la IA, más importantes se vuelven algunas prácticas bastante tradicionales de ingeniería de software.

Por ejemplo, los tests.

CyberGym-E2E no considera suficiente que el agente elimine una vulnerabilidad. El software tiene que seguir superando sus pruebas funcionales.

En una empresa ocurre exactamente lo mismo.

Una IA puede generar una corrección en segundos.

Pero si el equipo no tiene una buena cobertura de pruebas, seguirá necesitando mucho tiempo para descubrir si ese cambio ha roto otra funcionalidad.

La automatización no elimina la necesidad de hacer bien las cosas.

En muchos casos, la hace más evidente.

¿Qué cambia entonces para Desarrollo y Seguridad?

Probablemente no desaparezcan ni el desarrollador ni el profesional de seguridad.

Lo que sí puede cambiar es dónde dedican su tiempo.

Menos horas revisando manualmente cada hallazgo.

Más tiempo entendiendo arquitectura, evaluando riesgos, revisando evidencias y tomando decisiones.

Un desarrollador tendrá que saber si una corrección tiene sentido dentro del sistema completo.

Un profesional AppSec tendrá que valorar cuándo confiar en una prueba automatizada y cuándo investigar más.

Y un responsable DevSecOps tendrá que decidir qué puede automatizarse dentro del pipeline y qué necesita una aprobación humana.

La IA puede hacer cada vez más trabajo técnico.

Eso hace que el criterio profesional sea todavía más importante.

Del asistente de código al compañero de trabajo

Hasta hace poco, cuando hablábamos de IA aplicada al desarrollo pensábamos sobre todo en asistentes capaces de completar una función o generar unas líneas de código.

Ahora empieza a aparecer otra idea.

Un agente que investiga.

Prueba.

Corrige.

Vuelve a probar.

Y deja evidencias de lo que ha hecho.

AWS está trabajando además para integrar estas capacidades dentro de herramientas utilizadas por desarrolladores, de forma que el análisis de seguridad pueda acercarse cada vez más al momento en el que se escribe el software.

Eso podría cambiar bastante la relación entre Desarrollo y Seguridad.

En lugar de desarrollar primero y revisar después, el análisis y la corrección pueden formar parte del mismo flujo.

No se trata de dejar que la IA haga todo

Quizá esa sea la conclusión más importante.

La pregunta no debería ser:

“¿Cuándo podrá la IA corregir nuestro código sin nosotros?”

La pregunta más útil es:

“¿Qué partes de este proceso podemos automatizar de forma segura?”

Para responderla harán falta buenas prácticas de desarrollo, testing, seguridad, CI/CD y gestión del riesgo.

La IA puede encontrar el fallo.

Puede demostrarlo.

Puede incluso preparar una solución.

Pero seguirán siendo las personas las que tengan que decidir cuándo esa solución es suficientemente buena como para confiar en ella.

La IA está cambiando tanto la forma de desarrollar software como la manera de protegerlo.

Si trabajas en sistemas, desarrollo o seguridad, entender vulnerabilidades, hacking, DevSecOps y el uso de IA en tareas de análisis y defensa empieza a formar parte de un mismo conjunto de competencias.

Explora la formación de Avante en ciberseguridad y desarrollo seguro.