Por qué el código generado por IA está rompiendo tu modelo de gestión de vulnerabilidades

Los generadores de código de IA han logrado algo que años de herramientas de DevOps nunca lograron completamente: han hecho posible enviar características en días que solían tomar semanas. El problema es que la velocidad se aplica igualmente a las vulnerabilidades.

A lo largo de mis años en ciberseguridad, he visto cómo las organizaciones pasan por el mismo patrón reactivo: descubren una vulnerabilidad, se apresuran a entender su alcance, discuten sobre quién es el dueño de la solución y la remedian semanas o meses después. La IA no ha cambiado ese patrón. Lo ha acelerado a un ritmo donde el modelo antiguo ya no puede seguir el ritmo. El tiempo medio de resolución (MTTR) para vulnerabilidades críticas es superior a 60 días. El desarrollo asistido por IA no te da 60 días. Te da una nueva base de código cada sprint.

El problema de dependencia ahora es un problema de IA

El noventa y seis por ciento de las aplicaciones empresariales incluyen componentes de código abierto. La mayoría nunca fueron verificados rigurosamente, solo se extrajeron de registros públicos porque funcionaban y alguien los necesitaba esa tarde. Los equipos de seguridad han estado perdiendo terreno en esto durante años, y los asistentes de codificación de IA han convertido una hemorragia lenta en algo mucho más difícil de controlar.

Cuando un desarrollador escribe código manualmente, toma decisiones deliberadas sobre las dependencias. Cuando un modelo de IA genera código, lo extrae de lo que se entrenó. Eso a menudo significa paquetes alucinados, versiones obsoletas o componentes con CVE conocidos que el modelo no tuvo razón para evitar. El código llega limpio. El riesgo está incrustado en el árbol de dependencias, varios niveles más abajo, invisible para cualquiera que no esté buscando específicamente eso.

Me he sentado en revisiones de seguridad donde los equipos se sorprendieron al encontrar una CVE crítica en una dependencia transitiva de un paquete que aprobaron meses antes. El paquete estaba bien. Lo que lo trajo fue lo que no estaba. Esa dinámica ahora ocurre a escala de máquina, en cientos de desarrolladores que utilizan herramientas de IA que no tienen concepto de la postura de seguridad de su organización.

Escaneo después del hecho no es una estrategia

El modelo prevaleciente para la seguridad del software de código abierto es escanear y parchear: ejecutar un escáner, triage los hallazgos, asignar tickets y esperar. Ese modelo siempre ha sido reactivo, y en un entorno de desarrollo acelerado por IA, está completamente superado.

Los escáneres encuentran problemas después de que ya están en su código. La ventana entre la introducción y el descubrimiento es donde vive su exposición. Cuando la IA está generando código a escala, esa ventana se amplía y el volumen de hallazgos crece más rápido de lo que cualquier equipo puede remediar manualmente. El resultado es un backlog de CVE que se expande indefinidamente, la priorización se convierte en adivinanza y los desarrolladores pasan de 4 a 8 horas por vulnerabilidad en un trabajo que produce cero valor comercial.

Agregue los fallos de gobernanza que siguen y la imagen empeora. La propiedad de la remediación a menudo es poco clara. La seguridad marca una CVE, la ingeniería la llama una pregunta de configuración y las operaciones la llaman un problema de código. Vi este patrón hace 20 años y no ha desaparecido. La IA hace que las consecuencias de esa ambigüedad sean significativamente más difíciles de absorber.

El cambio que realmente funciona: controlar lo que entra

Las organizaciones que se adelantan a esto han dejado de intentar escanear su camino hacia la seguridad y han comenzado a controlar lo que sus desarrolladores y herramientas de IA pueden consumir en primer lugar. El mecanismo es un catálogo curado y gobernado por políticas de componentes de código abierto, construido desde la fuente, monitoreado continuamente y servido como un registro interno privado que reemplaza las extracciones directas de ecosistemas públicos como PyPI, npm o Maven.

Este enfoque desplaza la seguridad hacia la izquierda en el sentido más literal. Las vulnerabilidades se bloquean en el punto de consumo, antes de que ingresen a la tubería de construcción. Los desarrolladores utilizan las mismas herramientas que siempre han utilizado. Los asistentes de codificación de IA resuelven dependencias desde la misma fuente gobernada. El equipo de seguridad establece la política una vez, y esa política se aplica en todas partes, incluido el código que un modelo genera a las 2 a.m. sin que nadie lo revise.

Qué se ve en la práctica

Para los líderes de seguridad que trabajan en esto, hay algunas cosas que importan más que nada:

1. Defina su conjunto de componentes aprobados antes de ampliar la adopción de IA. Si sus herramientas de codificación de IA están resolviendo dependencias desde registros públicos, su proceso de aprobación existe solo en papel. Establezca un registro interno gobernado, canalice todo a través de él y exija que los componentes se construyan desde la fuente con procedencia verificable.
2. Trate la remediación como un proceso administrado, no como una cola de tickets. Las organizaciones que se mantienen por delante de la deuda de CVE no están moviéndose más rápido en la remediación manual. Han eliminado la remediación manual de la ecuación. Cuando está disponible un parche aprobado por la comunidad, se reconstruye automáticamente en el catálogo. Los desarrolladores obtienen la actualización la próxima vez que extraen. Nadie asigna un ticket. Nadie espera 60 días.
3. Asigne su cadena de herramientas de IA a sus obligaciones de cumplimiento antes de que se lo exijan. He visto a equipos construir en herramientas de IA durante meses, solo para encontrar un obstáculo cuando un cliente requirió la alineación de FedRAMP o la evidencia de SOC 2. Su catálogo curado también es su registro de auditoría de cumplimiento. Los registros SBOM y de procedencia deben enviarse con cada componente, no ensamblarse retroactivamente bajo presión de plazo.
4. Asigne una propiedad clara a nivel de gobernanza, no a nivel de ticket. Los equipos que se mueven más rápido en la remediación no son los que tienen más desarrolladores. Son los que tienen un equipo de seguridad que posee la política, un equipo de plataforma que posee la entrega y ninguno de los dos espera que el otro actúe.

Seguridad que habilita en lugar de bloquear

Hay una creencia persistente de que la seguridad y la velocidad de desarrollo están en conflicto fundamental. Nunca he encontrado que eso sea cierto cuando la seguridad se diseña en el proceso en lugar de agregarse después. Los desarrolladores que trabajan desde un conjunto de componentes curados en realidad se mueven más rápido, porque no están cuestionando aprobaciones, esperando revisiones de seguridad o limpiando vulnerabilidades que podrían haberse bloqueado aguas arriba.

Las organizaciones que navegarán el desarrollo impulsado por IA sin acumular deuda de seguridad insostenible no son las que ejecutan los escáneres más numerosos. Son las que han tomado una decisión deliberada de gobernar lo que entra en su cadena de suministro de software antes de que se convierta en un problema de respuesta a incidentes. Esa decisión pertenece al liderazgo. Las herramientas para ejecutarla existen hoy.