Auge de la IA potencia el sector empresarial, pero lo expone a más ciberataques

Por: Patrick Rinski, líder de Unit 42 para América Latina.

La promesa del desarrollo asistido por IA, o “codificación vibrante“, es innegable. En un panorama definido por complejas arquitecturas nativas de la nube y una intensa demanda de nuevo software, este factor multiplicador de fuerza se está convirtiendo rápidamente en una práctica habitual. Sin embargo, esta velocidad conlleva un coste considerable, a menudo desatendido. Dado que los agentes de IA que generan código funcional en segundos, con frecuencia no aplican controles de seguridad críticos, lo que genera vulnerabilidades masivas, deuda técnica y escenarios de vulneración reales.

Este desafío se puede agravar por el auge de desarrolladores ciudadanos (personal sin experiencia en desarrollo) que carecen de los conocimientos necesarios para revisar o proteger el código generado. Debido a esta falta de experiencia en desarrollo, es posible que los desarrolladores no comprendan plenamente los requisitos de seguridad del ciclo de vida de las aplicaciones, lo que puede requerir formación o experiencia en seguridad de aplicaciones. Para todos los líderes, desde el CEO hasta el CISO, así como para los profesionales técnicos, comprender esta brecha es fundamental.

Hoy basta con que un usuario escriba una instrucción simple para que en segundos aparezcan varias líneas de código funcional. Esa es la nueva realidad del desarrollo de software. Las ganancias de productividad son innegables, pero ya estamos viendo incidentes reales provocados por el uso de estas herramientas sin los controles de seguridad adecuados.

Cuando el código de IA funciona, pero la seguridad queda atrás

El problema no es hipotético. ¿Qué ocurre cuando una función generada por IA obtiene los datos correctamente, pero no incluye controles básicos de autenticación o limitación de solicitudes? ¿O cuando una instrucción maliciosa logra engañar al agente de IA para extraer información sensible?

La codificación Vibe ofrece una ventaja, ya que permite a los equipos hacer más con menos. Sin embargo, tras una adopción más generalizada, la Unidad 42 ha observado que se han producido fallos catastróficos reales:

• Desarrollo de aplicaciones inseguras que conducen a una violación. Una aplicación de ventas fue violada con éxito porque el agente de codificación de vibraciones no incorporó controles de seguridad clave, como los de autenticación y limitación de velocidad.
• Lógica de plataforma insegura que conduce a la ejecución de código. Los investigadores descubrieron una falla crítica a través de la inyección indirecta de indicaciones que permitía la inyección de comandos maliciosos a través de contenido no confiable, ejecutando código arbitrario y permitiendo la exfiltración de datos confidenciales.
• Lógica de plataforma insegura que conduce a la elusión de la autenticación. Una falla crítica en la lógica de autenticación de un programa popular permitió eludir los controles simplemente mostrando la identificación públicamente visible de una aplicación en una solicitud de API.
• Eliminación no autorizada de una base de datos que provoca pérdida de datos. Un agente de IA, a pesar de las instrucciones explícitas de congelar los cambios de producción, eliminó toda la base de datos de producción de una aplicación comunitaria.

La creciente demanda de software, uso intensivo de tecnologías en la nube y adopción generalizada de modelos DevOps están llevando a muchas organizaciones a priorizar la velocidad sobre la seguridad. La programación asistida por IA puede ser gran habilitador, pero sin una estrategia de control de riesgos, es un acelerador de incidentes graves.

Comprender las causas profundas del riesgo en la programación asistida por IA

Estos incidentes son síntomas de deficiencias predecibles y fundamentales en el funcionamiento de los modelos de IA. Según el análisis de Unidad 42, estos riesgos se agrupan en varias categorías clave:

• Los modelos priorizan la funcionalidad sobre la seguridad. Los agentes de IA están optimizados para proporcionar una respuesta práctica y rápida. No están optimizados intrínsecamente para formular preguntas de seguridad críticas, lo que resulta en una naturaleza insegura por defecto.
• Ceguera del contexto crítico: un agente de IA carece de la conciencia situacional que posee un desarrollador humano (por ejemplo, distinguir entre entornos de producción y desarrollo).
• El riesgo de la cadena de suministro “fantasma”. Los modelos de IA a menudo generan alucinaciones con bibliotecas o paquetes de código que parecen útiles pero que en realidad no existen, lo que genera dependencias irresolubles.
• Desarrolladores ciudadanos y exceso de confianza en los desarrolladores. Los profesionales sin experiencia en desarrollo carecen de formación para escribir código seguro. La democratización del desarrollo de código acelera la aparición de vulnerabilidades de seguridad y la deuda técnica a largo plazo. Además, el código parece correcto y funciona. Esto crea una falsa sensación de seguridad, lo que acelera la aparición de vulnerabilidades debido a la falta de control de cambios tradicional y revisión segura del código.

A través de sus evaluaciones de visibilidad y seguridad de IA, la Unidad 42 ha descubierto que la mayoría de las organizaciones evaluadas permiten a sus empleados usar herramientas de codificación de vibraciones debido a la ausencia de bloqueos físicos (por ejemplo, herramientas de bloqueo en el firewall). Sin embargo, muy pocas de estas organizaciones han realizado una evaluación formal de riesgos sobre el uso de estas herramientas y muy pocas monitorean las entradas, salidas y resultados de seguridad.

Abordar el riesgo a través del marco SHIELD

El marco SHIELD es una guía para reducir riesgos de seguridad cuando se usa IA para programar (vibe coding). El objetivo principal es no dejar todo en manos de la inteligencia artificial y mantener controles básicos.

Este enfoque práctico se basa en limitar los permisos de la IA, separar funciones críticas, mantener siempre la revisión humana, usar herramientas automatizadas de seguridad y aplicar controles defensivos ante cualquier operación. En resumen, aprovecha la eficiencia de la IA en el desarrollo de software sin comprometer la seguridad de los sistemas ni de la organización.

• S — Separación de funciones. Evitar que los agentes tengan privilegios mezclados que alcancen la producción. Restringir su uso a desarrollo y pruebas.
• H — Humano en el circuito. Exigir revisión obligatoria de código por personal calificado y aprobación de Pull Request (PR) antes del merge, especialmente cuando participan no desarrolladores.
• I — Validación de entradas y salidas. Separación de instrucciones confiables y datos no confiables (sanitizar prompts con guardrails) y aplicar SAST antes de integrar cambios.
• E — Modelos auxiliares centrados en seguridad. Usar herramientas independientes para SAST, escaneo de secretos, verificación de controles y detección de secretos hardcodeados, previo al despliegue.
• L — Agencia mínima. Otorgar a los agentes sólo los permisos indispensables, restringir acceso a archivos sensibles y poner límites a comandos destructivos.
• D — Controles técnicos defensivos. Aplicar Software Composition Analysis (SCA) antes de consumir componentes y deshabilitar la auto‑ejecución para asegurar siempre la intervención humana en el despliegue.

Más información y noticias de TENDENCIAS aquí.