Un reciente
análisis de Unit 42, de Palo Alto Networks, señala que el crecimiento de
la programación asistida por IA no solo acelera el desarrollo de software, sino que también expone a las organizaciones a mayores riesgos de ciberseguridad.
La promesa del desarrollo asistido por IA, conocido como «vibe coding», es innegable. En un entorno caracterizado por complejas arquitecturas en la nube y una gran demanda de nuevo software, esta herramienta se está convirtiendo rápidamente en algo habitual. No obstante, esta rapidez trae consigo un costo considerable, a menudo ignorado. Los agentes de IA que generan código funcional de manera inmediata no siempre aplican controles de seguridad esenciales, lo que puede resultar en vulnerabilidades significativas, acumulación de deuda técnica y escenarios de ciberataques.
Este problema se ve exacerbado por la creciente cantidad de desarrolladores ciudadanos (personas sin experiencia en desarrollo) que no cuentan con los conocimientos necesarios para evaluar o proteger el código generado. Como resultado de su falta de experiencia, podrían no entender del todo las necesidades de seguridad a lo largo del ciclo de vida de las aplicaciones, lo que podría requerir capacitación específica en seguridad de aplicaciones. Para todos los líderes, desde CEO hasta CISO, así como para profesionales técnicos, es crucial entender esta brecha.
«Hoy en día, un usuario solo necesita escribir una instrucción básica para que en segundos aparezcan varias líneas de código funcional. Esta es la nueva realidad en el desarrollo de software. Las ventajas en productividad son evidentes, pero ya hemos comenzado a ver incidentes reales generados por el uso de estas herramientas sin los controles de seguridad necesarios«, comentó Patrick Rinski, líder de Unit 42 para América Latina.
«Cuando el código funciona, pero la seguridad queda rezagada»
El problema no es meramente teórico. ¿Qué sucede cuando una función generada por IA accede correctamente a los datos, pero no implementa controles básicos de autenticación o limitación de solicitudes? ¿O cuando una instrucción maliciosa logra engañar a la IA para que extraiga información sensible?
La codificación Vibe ofrece ventajas al permitir que los equipos sean más eficientes. Sin embargo, tras su adopción más amplia, Unit 42 ha identificado fallos catastróficos concretos:
- Aplicaciones inseguras que llevan a violaciones: una aplicación de ventas fue comprometida debido a que el agente de codificación no integró controles de seguridad esenciales, como los de autenticación y limitación de velocidad.
- Lógica de plataforma insegura que posibilita la ejecución de código: se descubrió una vulnerabilidad crítica a través de la inyección indirecta de comandos maliciosos, permitiendo la ejecución de código arbitrario y la exfiltración de datos confidenciales.
- Lógica de plataforma insegura que facilita el eludir la autenticación: una falla en la lógica de autenticación de un programa popular permitió omitir controles mostrando la identificación de la aplicación en una solicitud de API.
- Eliminación no autorizada de bases de datos que causó pérdida de datos: un agente de IA, a pesar de recibir instrucciones explícitas para congelar cambios en producción, eliminó toda la base de datos de una aplicación comunitaria.
«La creciente demanda de software, el uso intensivo de tecnologías en la nube y la adopción de modelos DevOps están llevando a muchas organizaciones a priorizar la velocidad sobre la seguridad. La programación asistida por IA es un gran habilitador, pero sin una estrategia efectiva de control de riesgos, podría acelerar la aparición de incidentes graves«, agregó Rinski.
Entender las causas profundas del riesgo en la programación asistida por IA
Estos incidentes son síntomas de deficiencias predecibles en el funcionamiento de los modelos de IA. Según el análisis de Unit 42, estos riesgos se pueden categorizar en varias áreas clave:
- Prioridades de funcionalidad sobre seguridad: los agentes de IA están optimizados para ofrecer respuestas rápidas y prácticas, no para formular preguntas críticas de seguridad, resultando en una naturaleza insegura por defecto.
- Falta de contexto crítico: un agente de IA carece de la conciencia situacional del desarrollador humano, como la diferencia entre entornos de producción y desarrollo.
- Riesgo de la cadena de suministro «fantasma”: los modelos de IA suelen generar referencias erróneas a bibliotecas o paquetes que parecen útiles pero en realidad no existen, creando dependencias insolubles.
- Desarrolladores ciudadanos y confianza excesiva: los profesionales sin experiencia carecen de formación en escritura de código seguro. La democratización del desarrollo de código maximiza la aparición de vulnerabilidades y deuda técnica a largo plazo, ya que el código parece funcional y correcto, generando una falsa sensación de seguridad al reducir el control de cambios tradicional.
A través de sus evaluaciones de visibilidad y seguridad de IA, Unit 42 ha encontrado que la mayoría de las organizaciones permiten a sus empleados utilizar herramientas de codificación Vibe sin bloqueos físicos (como restricciones en firewalls). Sin embargo, pocas han realizado evaluaciones formales de riesgo y monitorean las entradas, salidas y resultados de seguridad.
Mitigación de riesgos mediante el marco SHIELD
El marco SHIELD proporciona una guía para reducir los riesgos de seguridad al usar IA para la programación (vibe coding). El objetivo principal es no depender totalmente de la inteligencia artificial, manteniendo controles básicos.
Este enfoque práctico se basa en restringir permisos de IA, separar funciones críticas, mantener revisión humana constante, emplear herramientas automatizadas de seguridad y aplicar controles defensivos en cada operación. En resumen, busca aprovechar la eficiencia de la IA en el desarrollo sin comprometer la seguridad.
- S (Separación de funciones) — Restringir que los agentes tengan privilegios que les permitan acceder a producción. Limitar su uso a desarrollo y pruebas.
- H (Humano en el circuito) — Exigir revisión obligatoria realizada por personal calificado y aprobación de Pull Request (PR) antes de la fusión, especialmente cuando intervienen no desarrolladores.
- I (Validación de entradas y salidas) — Diferenciar entre instrucciones confiables y datos no confiables (sanitizar prompts) y aplicar SAST antes de integrar cambios.
- E (Modelos auxiliares con enfoque en seguridad) — Utilizar herramientas independientes para SAST, escaneo de secretos y verificación de controles, antes del despliegue.
- L (Mínimos permisos) — Otorgar a los agentes únicamente los permisos esenciales, restringiendo el acceso a archivos sensibles y limitando comandos destructivos.
- D (Controles técnicos defensivos) — Implementar Software Composition Analysis (SCA) antes de usar componentes y deshabilitar la autoejecución para asegurar intervención humana en el despliegue.
Fuente:
Unit42
Con Información de blog.segu-info.com.ar