La IA cambia cómo se construye el software, no quién es responsable de asegurarlo

Más código implica más vulnerabilidades, incluso con mejores herramientas

Cada avance en seguridad automatizada trae consigo una suposición tentadora: que una mejor detección acabará por cerrar la brecha. Pero las cuentas no salen así. A medida que la IA acelera el desarrollo, el volumen de código que se produce crece más rápido de lo que cualquier mejora en la detección puede compensar.

Esto quiere decir que el desafío de seguridad no se reduce, sino que se acumula. Y se acumula en un entorno donde la mayoría de los equipos empiezan a pensar en seguridad después del paso a producción, no antes. Se vuelve al patrón de construir primero y evaluar el riesgo después, lo que implica que las vulnerabilidades llegan a producción antes de que alguien las haya evaluado. Cuando se combina ese hábito con la velocidad sin precedentes a la que el código pasa del resultado de un agente a un despliegue en vivo, las pruebas en producción se convierten en algo esencial.

También se está formando una suposición peligrosa en torno a la remediación asistida por IA. Dado que los agentes de IA ya pueden detectar una vulnerabilidad y proponer un fix dentro del mismo flujo de trabajo, algunos concluirán que el ciclo está cerrado: el agente escribe el código, encuentra los errores y los corrige. El código tiene que ser seguro. Pero no es así. Que un agente remedie su propio output no garantiza un resultado seguro, sino un ciclo más rápido que todavía requiere validación.

La IA cambia el proceso, no al responsable

En Fluid Attacks enmarcamos el cambio actual de esta manera: "La IA construye. Los humanos dirigen. Nosotros aseguramos". El énfasis en "dirigen" es adrede. Los agentes de IA están transformando cada etapa del desarrollo de software, desde la escritura de código hasta las pruebas y las propuestas de remediación; sin embargo, la responsabilidad de la seguridad no se transfiere al agente. Los humanos siguen al mando. Son quienes definen lo que se construye, establecen la tolerancia al riesgo y rinden cuentas cuando algo sale mal.

Si el agente puede codificar, escanear y remediar, ¿para qué involucrar a los humanos? La respuesta es que la seguridad es una decisión de criterio que depende de un contexto que el agente no posee por completo: la lógica de negocio de la aplicación, el modelo de amenazas de la organización, los requisitos regulatorios de la industria, la tolerancia al riesgo. Estas son decisiones humanas.

Además, está el caso de los falsos negativos. Sabemos que los falsos positivos, por su parte, perderán algo de peso en un mundo donde la velocidad de desarrollo abarata y agiliza la remediación, incluso cuando se trata de falsas alarmas. Pero un falso negativo, es decir, una vulnerabilidad real que pasa desapercibida, siempre es relevante. Representa un riesgo no gestionado y un vector abierto de ataque. Por eso, las pruebas por capas, que combinan razonamiento con IA, análisis determinista de código fuente, pruebas dinámicas y revisión humana, no son un lujo: son el único enfoque que minimiza los puntos ciegos que cualquier método aislado inevitablemente tiene.

Nuestros pentesters ya han probado herramientas de IA para amplificar su trabajo, y resumimos esa sinergia así: Los humanos piensan estratégicamente; los agentes ejecutan masivamente. El agente escala la ejecución: lanza pruebas en paralelo, analiza repositorios enteros y genera candidatos de vulnerabilidades. El humano aporta el pensamiento estratégico, la creatividad para encontrar caminos que ningún modelo anticipa y el criterio para confirmar si una vulnerabilidad es explotable en el contexto del sistema real en ejecución.

Un panorama en transformación exige una visión más amplia

Aunque resulta tentador centrarse en lo que Claude Code Security hace y no hace, la conversación más importante gira en torno a los cambios más amplios que están reconfigurando el desarrollo de software y, en consecuencia, la seguridad de aplicaciones.

El rol del desarrollador está evolucionando: de escribir código a instruir agentes, definir requisitos y validar resultados. Creemos que las herramientas también están cambiando: es muy probable que los entornos de desarrollo integrado (IDE) den paso a interfaces de línea de comandos con agentes, y eventualmente a entornos donde los modelos extensos de lenguaje (LLM) funcionen como un cerebro con acceso al escritorio del desarrollador. Las propias máquinas de los desarrolladores podrían convertirse en los sandboxes donde se prueben las aplicaciones. No se trata de escenarios lejanos, sino de la dirección hacia la que ya se dirigen los equipos de adopción temprana.

Al mismo tiempo, las arquitecturas de las aplicaciones se vuelven más distribuidas. Las API proliferan. Los servidores de protocolo de contexto de modelo (MCP) surgen como nuevos componentes en la forma en que los sistemas se interconectan. Los LLM y los modelos de IA se convierten en actores dentro de la cadena de suministro de software, con un rol cada vez más crítico tanto en el desarrollo como en producción. Nuevas interfaces de usuario, como el chat y la voz, introducen nuevas categorías de debilidades que no existían hace unos pocos años.

Todo esto genera superficies de ataque más dinámicas y difíciles de gestionar. Y una herramienta que lee código fuente, por inteligente que sea, solo se ocupa de una fracción de este problema. Un código con sintaxis perfecta puede seguir siendo vulnerable. Una aplicación cuyo código fuente pasa todos los controles de análisis estático puede seguir siendo explotable si su entorno de ejecución está mal configurado, si su infraestructura tiene brechas o si las interacciones entre sus componentes introducen fallos que solo se manifiestan cuando el sistema está realmente en funcionamiento.

Probar el sistema como un todo

Esto es lo que creemos que la conversación debe poner en el centro, y es el principio que guía nuestro trabajo en Fluid Attacks: la seguridad requiere probar el sistema coherente como un todo, a través de la capa de código, el entorno de ejecución y la infraestructura.

El análisis estático, incluso el impulsado por IA, examina el código sin ejecutarlo. Muchas de las vulnerabilidades que terminan en los reportes de incidentes no son problemas que se puedan encontrar leyendo el código fuente con más detenimiento. Son comportamientos que emergen cuando una aplicación se ejecuta en su entorno real, cuando las solicitudes pasan por la pila de API, cuando los middlewares de autenticación se encadenan y cuando los componentes interactúan entre servicios. Estas vulnerabilidades requieren ejecutar la aplicación y probarla en condiciones que se asemejen a las que un atacante usaría para explorarla.

Claude Code Security no hace esto. Tampoco lo hace ninguna herramienta de análisis estático, ya sea tradicional o impulsada por IA. No se trata de un defecto en el diseño de Claude Code Security, sino simplemente del alcance de lo que se propuso lograr. La pregunta para los equipos de seguridad es si sus programas cubren las capas que el escaneo de código, por sofisticado que sea, no alcanza.

La misma lógica se aplica a la explotación de vulnerabilidades. Confirmar que un hallazgo es genuinamente explotable en un entorno específico requiere más que leer código y razonar sobre él; requiere probar el sistema en vivo. Este es el dominio del pentesting, donde la experiencia humana sigue siendo valiosa. En Fluid Attacks, combinamos herramientas automatizadas, incluido nuestro AI SAST, con pentesting manual experto, ya que cada uno tiene ventajas y limitaciones que el otro compensa. El análisis automatizado con IA cubre la amplitud: escanea repositorios enteros a gran velocidad y genera contexto sobre la superficie de ataque que los pentesters utilizan para dirigir las pruebas. El pentester aporta la profundidad: la capacidad de probar si un fallo es genuinamente explotable en el entorno desplegado y de explorar el comportamiento del sistema de maneras que ninguna herramienta automatizada puede.

El riesgo de terceros se expande más allá de paquetes

La conversación sobre seguridad de la cadena de suministro se ha centrado históricamente en las dependencias de código abierto: escanear paquetes en busca de Vulnerabilidades y Exposiciones Comunes (CVE) conocidos, generar una lista de materiales de software (SBOM) y verificar licencias. Eso sigue siendo importante, pero la cadena de suministro de una aplicación moderna ahora incluye componentes que nunca estuvieron en la mira del análisis de composición de software (SCA) tradicional.

Cuando una aplicación depende de un LLM para la toma de decisiones, ese modelo es una dependencia de terceros. Cuando se conecta a servicios externos a través de servidores MCP, esos servidores forman parte de la superficie de ataque. Cuando los agentes de IA usan skills y plugins para extender sus capacidades, cada skill es un componente que puede introducir riesgo. Las pruebas de componentes de terceros ya no se reducen al SCA sobre paquetes; deben extenderse a modelos, skills y servidores MCP. Las herramientas y la metodología para este tipo de pruebas todavía están en desarrollo, y representan una de las fronteras más importantes en la seguridad de aplicaciones.

Lo que realmente gestionan los programas empresariales de AppSec

El software empresarial no vive en un solo repositorio mantenido por un solo equipo. Es un ecosistema extenso: cientos de aplicaciones, equipos distribuidos en diferentes geografías y husos horarios, una mezcla de sistemas heredados y microservicios modernos, shadow IT que los equipos de seguridad ni siquiera saben que existe y servicios cuya criticidad va desde herramientas internas hasta sistemas que afectan la vida diaria de millones de personas. Una vulnerabilidad en un servicio de procesamiento de pagos no es lo mismo que una vulnerabilidad en una wiki interna, y el programa de seguridad debe entender esa diferencia.

Esta complejidad es lo que hace que un escáner de código, por inteligente que sea, resulte insuficiente como pilar de un programa de seguridad empresarial. El desafío no es solo detectar vulnerabilidades, sino garantizar que las pruebas se ejecuten de manera consistente y exhaustiva en todo un ecosistema que cambia constantemente.

Piensa en los puntos de control que una empresa debe gobernar. El código se escribe en el entorno del desarrollador, se revisa en un pull request, se integra en un pipeline de integración continua (CI) y se despliega en producción. Cada una de estas etapas es una oportunidad para probar, pero también una oportunidad para que una vulnerabilidad se cuele si las pruebas no se ejecutan. ¿Se están ejecutando escaneos en la interfaz de línea de comandos (CLI) durante el desarrollo? ¿Se aplican de forma obligatoria en el pull request antes de fusionar el código? ¿El pipeline de CI está configurado para bloquear compilaciones que no cumplan con los umbrales de seguridad? ¿Se está probando la aplicación después del despliegue, en el entorno de ejecución donde ocurren los ataques reales? Un programa de seguridad empresarial debe garantizar que las pruebas se ejecuten en múltiples puntos de control, porque depender de uno solo deja puertas abiertas.

Y en este contexto, un falso negativo puede ser catastrófico. Hablamos de sistemas que procesan transacciones financieras, gestionan datos de salud, controlan infraestructura crítica y median el acceso a servicios de los que las personas dependen todos los días. Una vulnerabilidad que pasa desapercibida, un riesgo real que nadie sabe que existe, es un vector abierto de ataque contra sistemas cuyo compromiso tiene consecuencias que van mucho más allá de la propia organización. Por eso, las empresas necesitan la certeza no solo de que existen buenas herramientas, sino de que esas herramientas se están ejecutando, de que sus resultados son trazables y de que nada se queda sin revisar.

El sistema de registro perdura

Las herramientas que usan los desarrolladores para escribir código están cambiando a gran velocidad; algunas de ellas, como los IDE tradicionales, podrían no sobrevivir la transición al desarrollo con agentes. Los sistemas de creación son, por naturaleza, transitorios: evolucionan, se reemplazan y siguen las preferencias de herramientas del momento.

Una plataforma para la gestión de la postura de seguridad de las aplicaciones (ASPM), en cambio, está llamada a convertirse en la fuente autoritativa de verdad sobre la postura de seguridad del portafolio de software de una organización. Es donde cada hallazgo de cada método de prueba converge en un único conjunto de datos gobernado y trazable. Es donde viven los flujos de remediación, donde se aplican las políticas, donde se genera la evidencia de cumplimiento y donde los equipos de desarrollo y seguridad se encuentran en torno a información compartida y completa.

Mientras los sistemas de creación siguen cambiando, el sistema de registro perdura. Y las organizaciones que gestionan el riesgo de forma eficaz serán aquellas que anclen sus programas de seguridad no a cualquier herramienta de escaneo nueva, sino a una plataforma que persiste, integra y gobierna a través de todas las capas de la aplicación.

Nuestra plataforma se construye sobre esta convicción. Es la fuente única de verdad donde convergen los resultados de todos los métodos de prueba, donde los flujos organizacionales en torno a esos resultados (asignación, remediación, verificación, cumplimiento de políticas, reportes de compliance) forman parte del mismo sistema, y donde las personas indicadas en cada equipo tienen la información que necesitan para tomar decisiones de seguridad de forma conjunta.

Avanzando juntos

Celebramos Claude Code Security como una señal de que la industria está convergiendo hacia una verdad que en Fluid Attacks sostenemos desde hace tiempo: el razonamiento con IA tiene un lugar en la seguridad de aplicaciones, y mejora de manera significativa lo que el análisis estático de código puede lograr. La tecnología madurará, su alcance se expandirá y las herramientas construidas sobre ella pasarán a formar parte de la manera en que cada organización piensa en la seguridad de su código.

Pero también creemos que el futuro de la seguridad de aplicaciones no se define por una sola capacidad de escaneo, por poderosa que sea. Se define por probar los sistemas de manera integral, su código, entorno e infraestructura; por reunir a los equipos de desarrollo y seguridad en torno a información compartida y completa; y por anclar los programas de seguridad a un sistema de registro que perdure mientras las herramientas a su alrededor evolucionan.

La IA cambia cómo se construye el software, no al responsable de asegurarlo. Ese es el principio sobre el que construimos en Fluid Attacks, y la llegada de Claude Code Security refuerza nuestra convicción de que es el correcto.