Zaid Al Hamani, CEO y Fundador de Boost Security – Serie de Entrevistas

Zaid Al Hamani, CEO y Fundador de Boost Security, es un líder en ciberseguridad y DevSecOps con más de dos décadas de experiencia construyendo y escalando operaciones tecnológicas globales. Desde que fundó Boost Security en 2020, se ha centrado en modernizar la forma en que las organizaciones aseguran el desarrollo de software, aprovechando sus roles anteriores, incluyendo VP de Seguridad de Aplicaciones en Trend Micro y Co-Fundador/CEO de IMMUNIO. Anteriormente, ocupó puestos de liderazgo senior en Canonical, liderando iniciativas de producto, ingeniería y soporte global, y en SITA, donde gestionó operaciones de TI a gran escala y críticas para la misión. Su carrera refleja un sólido historial de construir equipos, optimizar sistemas y avanzar en prácticas de seguridad modernas.

Boost Security es una empresa de ciberseguridad centrada en asegurar la cadena de suministro de software moderna a través de una plataforma de DevSecOps orientada al desarrollador. Su tecnología se integra directamente en las tuberías de CI/CD para detectar, priorizar y remediar vulnerabilidades de forma automática, reduciendo la carga manual mientras mantiene la velocidad de desarrollo. Al unificar la seguridad de la aplicación y la cadena de suministro en un solo sistema, la plataforma proporciona visibilidad completa en todo el código, las dependencias y la infraestructura, ayudando a las organizaciones a fortalecer la resistencia en entornos nativos de la nube complejos.

Anteriormente lideró la seguridad de aplicaciones en Trend Micro y co-fundó IMMUNIO. ¿Qué lo llevó a fundar Boost Security, y qué brecha en el mercado estaba único para identificar temprano?

IMMUN.IO fue una de las primeras empresas de RASP en ser fundada, y nuestra experiencia hasta ese momento fue que los WAF como tecnología de seguridad en tiempo de ejecución eran imposibles de mantener y no muy efectivos. Envisionamos una forma en que los WAF serían reemplazados por una solución más precisa y fácil de mantener, instrumentando la aplicación.

Eso fue en 2012, DevOps todavía estaba en sus inicios, la mayoría de los equipos no eran Ágiles, y Kubernetes no era una cosa todavía.

Trend Micro adquirió IMMUN.IO en 2017. Para entonces, había muchas más prácticas de DevOps: tuberías de CI/CD, prácticas de desarrollo Ágiles, ciclos de iteración y lanzamiento más rápidos, nube, etc. Los equipos de desarrollo de software eran mejores para construir software y enviarlo más rápido. Sin embargo, la seguridad todavía estaba rota:

• Los análisis son demasiado lentos, o los resultados llegan demasiado tarde
• Los resultados son demasiado complejos para que los desarrolladores los actúen
• Había una tasa de falsos positivos generalmente inaceptable
• Muchos nuevos tipos de artefactos no se escaneaban: infraestructura como código, contenedores, API, por ejemplo

Producir software rápido era más fácil. Producir software seguro rápido todavía era difícil.

Ese fue el problema original que nos propusimos resolver. Hacer que DevSecOps funcione en el mundo real; ¿puedes hacer que un equipo de desarrollo de software agregue fácilmente la seguridad al ciclo de vida de desarrollo, a una velocidad que coincida con los nuevos estándares de velocidad? ¿Puedes hacer que la cobertura sea amplia, donde una plataforma es todo lo que necesitas? ¿Puedes hacer que los desarrolladores no solo adopten la tecnología, sino que también la abracen y vean los beneficios? ¿Puedes hacer que se escalen para que no necesites ejércitos de profesionales de la seguridad para mantener el ritmo con la cantidad de código escrito…

Ayudamos a las empresas a inyectar seguridad en el ciclo de vida de desarrollo durante la era de DevOps. Eso fue ir de 1 a 10. Ahora estamos en la era de la codificación agente, donde los agentes escriben una cantidad enorme de código, pero es fundamentalmente el mismo problema: la velocidad y el volumen de código solo pasaron de 10 a 100, y apuntamos a continuar la misma trayectoria.

Usted ha argumentado que el ciclo de vida de desarrollo de software (SDLC) ha cambiado fundamentalmente hacia arriba. ¿Cuál fue el momento en que se dio cuenta de que los enfoques tradicionales de DevSecOps ya no eran suficientes?

Fue observar cómo los atacantes realmente estaban entrando. Seguíamos viendo el mismo patrón: un flujo de trabajo de GitHub Actions expuesto que nadie había revisado desde que se bifurcó el repositorio, un token con acceso a la nube de producción incrustado en una configuración de ejecutor, un trabajo de CI legítimo secuestrado para desplegar cargas útiles de atacantes. Estos se convirtieron en lo que se conoce como ataques “viviendo de la tubería”, porque el adversario utiliza su propia automatización en su contra, con credenciales que su equipo de seguridad ya había aprobado.

La pila de DevSecOps que habíamos construido durante una década no tenía respuesta para eso. El análisis de código fuente de la aplicación (SAST) escanea el código fuente de la aplicación. El análisis de dependencias de la aplicación (SCA) escanea las dependencias de la aplicación. Ambos asumen que la tubería que los ejecuta es de confianza. Mientras tanto, la tubería en sí es un archivo YAML con comandos de shell, acceso a la red y credenciales sensibles, y casi nadie la revisa.

Cuando eso se convierte en el camino de menor resistencia, puedes enviar código limpio y todavía entregarle a los atacantes tu nube.

¿Cómo deben replantear las empresas el ciclo de vida de desarrollo de software en un mundo donde los agentes de codificación de IA generan código continuamente en lugar de que los desarrolladores lo escriban paso a paso?

Todos debemos dejar de pensar en el ciclo de vida de desarrollo de software como una secuencia de puntos de control. Los agentes de IA han colapsado el tiempo entre “alguien escribió esto” y “esto está en producción” de semanas a minutos. El modelo antiguo asumía un ritmo humano entre la revisión de código, SAST, SCA y despliegue, pero ya estamos más allá de eso.

La seguridad debe vivir donde opera el agente: en la máquina del desarrollador, dentro del contexto de la promoción, en las conexiones del agente con los servidores MCP y los modelos externos. Para cuando el código llega a la tubería, ya has perdido la oportunidad de darle forma. El agente ya ha extraído la dependencia. El modelo ya ha visto la credencial. Mueve los controles hacia arriba, a donde realmente se realiza el trabajo.

Muchas organizaciones todavía tratan las herramientas de codificación de IA como simples capas de productividad. ¿Por qué cree que representan una superficie de ataque completamente nueva en lugar de solo una extensión de flujos de trabajo existentes?

Tratar una herramienta de codificación de IA como una capa de productividad es como tratar a un desarrollador junior con acceso de root como una capa de productividad. La etiqueta es técnicamente precisa, pero no te da ningún marco útil para pensar en qué podría salir mal.

Un agente de codificación lee tu sistema de archivos, raspa variables de entorno para contexto, busca dependencias en registros públicos, abre conexiones salientes a proveedores de modelos remotos y servidores MCP, y ejecuta comandos de shell. Cada una de esas acciones solía requerir un humano en el bucle. Ahora ocurren en milisegundos, con los mismos privilegios que el desarrollador que lanzó el agente.

Eso fusiona límites de confianza que solían ser separados: la autoridad del desarrollador, lo que puede obtener una herramienta externa y lo que puede ejecutar el código no confiable. Eso crea nuevas oportunidades para los atacantes y puntos ciegos que los defensores ni siquiera pueden ver, y mucho menos defender.

Boost enmarca la laptop del desarrollador como el nuevo plano de control. ¿Qué riesgos existen en el punto final que los equipos de seguridad están pasando por alto actualmente?

El más grande es el inventario. La mayoría de los equipos de seguridad no pueden decirte qué agentes de IA están ejecutándose en qué laptops, a qué servidores MCP están conectados esos agentes o qué extensiones de IDE están raspando contenido de repositorio en este momento. La detección de puntos finales (EDR) no tiene visibilidad en la capa del agente; el sistema de información de seguridad (SIEM) tampoco puede ver lo que hacen esos agentes localmente. Es un problema de TI sombra con privilegios de ejecución de código.

Debajo de eso se encuentra el desastre de credenciales. Construimos una herramienta de código abierto llamada Bagel en parte para hacer esto concreto. Una laptop de desarrollador típica contiene tokens de GitHub con acceso de escritura a repositorios de producción, credenciales de nube que pueden iniciar infraestructura, tokens de npm o PyPI que pueden publicar a millones de usuarios y claves de servicio de IA que los atacantes revenden. Nada de eso está endurecido de la manera que un ejecutor de CI está endurecido. La misma máquina que contiene esas credenciales también navega por la web e instala extensiones de VS Code aleatorias.

Combina los dos y tienes la superficie de ataque real. Una extensión no confiable que se ejecuta con privilegios de desarrollador en un entorno lleno de claves de nube es el objetivo de mayor valor en la empresa moderna. La mayoría de los equipos no han comenzado a buscar en ese lugar.

Ha resaltado la “trampa de contexto”, donde los agentes de IA pueden acceder a archivos locales, variables de entorno y configuraciones. ¿Cuán extendido es el riesgo de que los datos sensibles se filtren a través de las promociones, y por qué es tan difícil de detectar?

Es lo suficientemente extendido como para que lo tratemos como el estado predeterminado de cualquier entorno de desarrollador no administrado. Cada agente de codificación que hemos inspeccionado extrae el contexto de forma agresiva. Leen archivos de punto, variables de entorno, archivos recientes, a veces árboles de directorios completos, y envían ese contexto a un modelo remoto. Las herramientas están diseñadas para funcionar de esta manera; la extracción agresiva de contexto es lo que las hace útiles.

El problema de detección comienza porque el tráfico de una filtración parece idéntico al uso normal del producto. Es TLS a api.openai.com o api.anthropic.com. Viene de una aplicación de negocio aprobada. El sistema de prevención de pérdida de datos (DLP) estándar ve a un desarrollador utilizando la herramienta de IA que la empresa acaba de licenciar. No ve que una de las cadenas en esa promoción es una clave secreta de AWS que el agente extrajo de un archivo .env medio olvidado en un directorio hermano.

Solo lo detectas inspeccionando las promociones antes de que salgan de la laptop, que es exactamente donde casi ninguna pila de seguridad está actualmente posicionada.

Menciona ataques a la cadena de suministro a velocidad de máquina. ¿Puede llevarnos a través de un escenario realista en el que un agente de IA introduce una vulnerabilidad más rápido de lo que las herramientas de seguridad tradicionales pueden identificarla?

Aquí hay uno que hemos visto variaciones repetidamente. Un desarrollador le pide a un agente que agregue una función que necesita una biblioteca de reintento HTTP. El agente sugiere un nombre de paquete. El paquete es plausible, pero en realidad no existe en npm. Dentro de una hora, un atacante lo registra, lo llena con lógica de reintento que funciona y un pequeño script de postinstalación que lee ~/.aws/credentials y publica el contenido en un webhook. El agente ejecuta npm install sin verificar, porque los agentes no verifican la reputación. La credencial ya se ha ido antes de que el desarrollador incluso ejecute el código.

El ataque en sí no es técnicamente sofisticado, pero la seguridad tradicional de la cadena de suministro se basa en vulnerabilidades conocidas en paquetes conocidos: CVE, SBOM, análisis de licencias. Ese marco no tiene nada que decir sobre un paquete que no existía cuando se ejecutó la última verificación, se creó específicamente para coincidir con una alucinación de IA y se ingiere antes de que se actualicen las fuentes de amenazas.

La ventana desde la publicación hasta el compromiso ahora se mide en minutos. Cualquier cosa que verifique después del hecho está verificando demasiado tarde.

¿Están las dependencias alucinadas convirtiéndose en uno de los mayores riesgos en el desarrollo impulsado por IA, y qué pasos prácticos pueden tomar las organizaciones para defenderse contra ellas?

Ya lo son. Los atacantes monitorean activamente las herramientas de IA populares para alucinaciones y registran los nombres de paquetes sugeridos dentro de minutos. Los investigadores hace un par de años, cuando esto comenzó a suceder, lo llamaron “slopsquatting” y el nombre se quedó. Una vez que un nombre de dependencia se alucina con suficiente frecuencia, sentarse en él es un ataque a la cadena de suministro con esfuerzo casi cero.

Las defensas prácticas parecen diferentes a las que la mayoría de los equipos tienen actualmente. Comienza en la ingesta. Bloquea paquetes con errores de escritura y registros recientes en el momento en que se ejecuta npm install o pip install, en la máquina del desarrollador, antes de que algo toque el disco. La detección post mortem en CI no ayuda cuando un script de postinstalación ya ha exfiltrado una credencial. Luego da al agente guardrails para operar dentro. Inyecta tu lista de dependencias aprobadas directamente en el contexto del agente, para que el modelo vea lo que está permitido antes de generar una sugerencia. Pedir a los desarrolladores que escriban “promociones seguras” no es una estrategia. Si estás siendo estratégico, significa que la seguridad establece el límite, el agente lo hereda. Y comienza a rastrear una factura de materiales de IA. La mayoría de los equipos no pueden decirte qué agentes, modelos y paquetes están tocando qué repositorios. No puedes defender lo que no puedes inventariar.

Ha dicho que la seguridad ya no puede comenzar en CI/CD. ¿Cómo se ve una tubería de seguridad moderna cuando la protección necesita comenzar antes en el proceso de desarrollo?

Si la seguridad comienza en CI/CD, has cedido la fase precompromiso a un entorno que no controlas. El agente ya ha ingerido el contexto, tu credencial puede ya estar en los registros de alguien más.

Una tubería moderna comienza en la laptop. Eso significa inventariar los agentes y extensiones que se ejecutan allí, validar a qué servidores MCP y modelos están permitidos conectarse, sanitizar lo que sale de la máquina y bloquear paquetes maliciosos antes de que se instalen. Desde allí, la política sigue el trabajo en el IDE. Inyectamos estándares de seguridad directamente en la ventana de contexto del agente para que el código generado se mantenga dentro de los guardrails desde el primer token. La tubería en sí no desaparece. Su función se convierte en verificación: confirmando que los controles upstream se mantuvieron.

La tubería en sí no desaparece. Su papel se convierte en verificación: confirmando que los controles upstream se mantuvieron.

¿Cuáles son los cambios más críticos que las organizaciones deben hacer hoy para asegurarse de que sus entornos de desarrollo sigan siendo seguros en los próximos años, a medida que continúan adoptando agentes de codificación de IA?

El mayor error es asegurar solo lo que se confirma. El riesgo interesante ahora vive en las ocho horas antes de que ocurra un compromiso. El drama no visto puede desarrollarse en la laptop, en la promoción o en la instalación del paquete. Si tus herramientas comienzan en la PR, estás protegiendo la mitad equivocada del flujo de trabajo.

Estrechamente relacionado: deja de tratar a los agentes de codificación como software de productividad. Son usuarios no humanos con acceso de shell, privilegios de escritura de repositorio y conexiones de red salientes. Góbiernalos de la manera que gobiernas cualquier otra identidad privilegiada, con un inventario, capacidades aprobadas y registros de auditoría.

El último cambio es más difícil culturalmente. La mayoría de las herramientas de “seguridad de IA” actualmente presentan hallazgos y los envían a los humanos. Los humanos no pueden triagear al ritmo que los agentes generan. Cualquier cosa que adoptes tiene que solucionar problemas automáticamente dentro del flujo de trabajo, con razonamiento rastreable, o se convierte en otro panel que nadie lee.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Boost Security.