La adopción de asistentes de IA para la codificación ya no es experimental. En las organizaciones que los han incorporado, la IA genera aproximadamente la mitad del código comprometido. La pregunta ya no es si los desarrolladores usarán IA, sino si los programas de seguridad pueden gobernar lo que estos sistemas producen. El código generado por IA demuestra una sorprendente capacidad para generar código sintácticamente correcto, con una tasa de aprobación del 99.9%. En contraste, el rendimiento de seguridad presenta una historia muy distinta.
Actualmente, la tasa de aprobación de seguridad promedio es del 56%, lo que significa que aproximadamente el 44% de las tareas de generación de código analizadas introducen una vulnerabilidad conocida. A medida que aumenta el volumen de código generado por IA y el rendimiento de seguridad permanece prácticamente inalterado, las organizaciones corren el riesgo de introducir código más vulnerable en sus entornos de desarrollo. En este contexto, las vulnerabilidades de software se han convertido en la principal vía de brecha, representando el 31% de los incidentes, por encima de las credenciales robadas.
Superar esa brecha exige replantear cómo la seguridad se integra en el desarrollo asistido por IA. Las organizaciones deben hacer de la seguridad una parte del proceso de desarrollo desde el inicio, elegir modelos con el riesgo en mente y verificar el código en su contexto antes de que llegue a producción. El objetivo no es ralentizar a los desarrolladores; se trata de hacer que la seguridad opere al mismo ritmo y escala que el software en creación.
La elección del modelo es una decisión de seguridad
Los modelos de IA aprenden de volúmenes inmensos de código histórico y públicamente disponible, incluidos ejemplos de proyectos de código abierto y comunidades de desarrolladores. Ese conjunto de datos contiene implementaciones seguras, pero también bibliotecas desactualizadas, validaciones débiles y patrones de codificación inseguros. Aunque los modelos están diseñados para producir código útil y funcional, sin controles adecuados pueden reproducir esos patrones inseguros a gran escala.
No se puede controlar todas las fuentes utilizadas para entrenar un modelo, pero sí se puede controlar qué modelos llegan al desarrollo. El modelo más sólido probado alcanzó un 68% de tasa de aprobación de seguridad, mientras que seis de los 11 modelos se agrupaban entre el 50% y el 53%. Por tanto, la elección del modelo es, además de una decisión de productividad, una consideración de riesgo.
Elegir un modelo más fuerte puede reducir la exposición, pero no hace que la salida sea confiable por defecto. El código generado por IA debe seguir siendo probado a lo largo del ciclo de vida del desarrollo de software mediante análisis estático y políticas de seguridad exigibles. La seguridad debe formar parte del propio proceso de entrega.
La seguridad necesita contexto de la aplicación
El código generado por IA puede parecer funcionar como se espera, compilar con éxito y pasar pruebas funcionales, pero aun así contener vulnerabilidades de seguridad. Bajo presión de plazos, esa confianza puede ser errónea, especialmente cuando los desarrolladores aceptan la salida sin entender completamente su comportamiento dentro de la aplicación más amplia.
La diferencia en el rendimiento de seguridad entre tipos de vulnerabilidades demuestra por qué el contexto es crucial. Mientras los modelos lograron tasas de aprobación del 83% para inyección de SQL y del 87% para algoritmos criptográficos inseguros, su rendimiento cayó al 15% para ataques de cross-site scripting y al 12% para inyección de registros. Algunas debilidades pueden identificarse mediante patrones de codificación reconocibles, pero otras dependen de flujos de datos, límites de autorización, fronteras de confianza y la interacción entre distintas partes de una aplicación.
Por eso la verificación debe ocurrir dentro del flujo de trabajo y en el contexto de la aplicación. Un análisis nativo de IA puede añadir detección de riesgos contextual junto con análisis estático establecido, resaltando problemas como fallos lógicos y autenticación rota directamente en las pull requests. La clave es combinar análisis contextual con pruebas independientes antes de fusionar el código y permitir que el riesgo se propague.
Priorizar el riesgo, no solo los hallazgos
A medida que la IA aumenta el volumen y la velocidad del desarrollo de software, también incrementa la cantidad de riesgos que los equipos de seguridad deben evaluar, priorizar y remediar. Esto añade presión a las organizaciones que ya gestionan atrasos de vulnerabilidades sin resolver.
Ese atraso genera deuda de seguridad, ya que los fallos se identifican pero quedan sin parchear, lo que mantiene el riesgo conocido en las aplicaciones por más tiempo. Cuanta más deuda se acumula, más difícil y costoso es reducirla. Hoy la deuda de seguridad afecta al 82% de las organizaciones, mientras que la deuda crítica llega al 60%.
Estas cifras señalan un problema de capacidad creciente. Las organizaciones generan y descubren riesgos más rápido de lo que pueden reducirlos. Tratar cada hallazgo con la misma urgencia solo agrava el problema. Los equipos deben centrarse, por tanto, en la explotabilidad, la criticidad de la aplicación y el impacto comercial para dirigir la capacidad de remediación limitada hacia las vulnerabilidades que realmente podrían causar daño.
La remediación impulsada por IA puede ayudar a cerrar la brecha entre el descubrimiento y la acción, proponiendo soluciones dentro del flujo de trabajo del desarrollador y reduciendo el trabajo manual repetitivo. Pero la remediación sigue necesitando gobernanza. Una corrección generada debe ser probada, validada y verificada frente a posibles regresiones. El objetivo debe ser reducir la exposición significativa, no simplemente aumentar el número de hallazgos o correcciones que avanzan en el sistema.
Qué deben hacer los líderes ahora
La codificación asistida por IA ya está integrada en el desarrollo de software. Como resultado, los líderes deben tratar sus implicaciones de seguridad como un cambio en el modelo operativo del software.
Eso implica saber dónde entra el código generado por IA en la organización, evaluar modelos frente a requisitos de seguridad relevantes, incorporar verificación en los flujos de trabajo de los desarrolladores y focalizar la remediación en el riesgo comercial explotable. También implica conservar evidencia de qué se probó, qué se corrigió y qué riesgo se aceptó conscientemente.
Las organizaciones que tengan éxito no serán aquellas que frenen la adopción de IA, sino aquellas que evolucionen sus prácticas de desarrollo para que la seguridad pueda competir al ritmo de la creación de software. La IA facilita generar código funcional, pero la verdadera prueba es demostrar que es seguro antes de que llegue a producción.
Hemos destacado el mejor software de protección de endpoints.
Este artículo se produjo como parte de TechRadar Pro Perspectives, nuestro canal para presentar a las mentes más brillantes de la industria tecnológica hoy.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si estás interesado en contribuir, descubre más aquí: https://www.techradar.com/pro/perspectives-how-to-submit
from Latest from TechRadar https://ift.tt/Wdn3vyw
via IFTTT IA
