Shahar Man, Co-fundador y CEO de Backslash Security – Serie de entrevistas

Shahar Man, Co-fundador y CEO de Backslash Security, es un líder tecnológico experimentado con profundos conocimientos en desarrollo de cloud, ciberseguridad y software empresarial. Actualmente lidera Backslash Security, una empresa enfocada en proteger entornos de desarrollo de software nativos de IA, protegiendo todo, desde IDE y agentes de IA hasta código generado y flujos de trabajo de promoción. Anteriormente, ocupó puestos de liderazgo senior en Aqua Security, donde se desempeñó como Vicepresidente de Gestión de Producto y Vicepresidente de I+D, ayudando a construir una de las principales plataformas de seguridad de contenedores en todo el ciclo de desarrollo. Al comienzo de su carrera, Man pasó más de una década en SAP, donde lideró iniciativas de desarrollo y producto, incluyendo SAP Web IDE, y trabajó en estrecha colaboración con clientes empresariales globales, mientras también contribuía al crecimiento del ecosistema de desarrolladores. Su carrera comenzó en puestos técnicos y de liderazgo en entornos de startup y unidades de tecnología de defensa de Israel, lo que le dio una base sólida en ingeniería y sistemas a gran escala.

Backslash Security es una plataforma de ciberseguridad emergente diseñada específicamente para la era del desarrollo de software impulsado por IA. La empresa se enfoca en proteger toda la pila de desarrollo nativa de IA, incluyendo agentes de IA, pipelines de generación de código y flujos de trabajo de desarrollo modernos, un área que las herramientas de seguridad tradicionales a menudo pasan por alto. Al proporcionar visibilidad, gobernanza y protección en tiempo real sin interrumpir la velocidad de los desarrolladores, Backslash busca abordar los riesgos crecientes introducidos por entornos de codificación automatizados y “vibe coding”. A medida que la creación de software se desplaza cada vez más hacia sistemas asistidos por IA, la plataforma está diseñada para garantizar que la seguridad evolucione en paralelo en lugar de convertirse en un cuello de botella, posicionando a Backslash en la intersección de DevSecOps y desarrollo de IA de próxima generación.

Ha ocupado puestos de liderazgo en producto y I+D en empresas como Aqua Security y SAP antes de fundar Backslash. ¿Qué señales tempranas lo convencieron de que el desarrollo nativo de IA y el “vibe coding” cambiarían fundamentalmente la creación de software, y que la seguridad necesitaba ser reconstruida para apoyarlo?

Ya había vivido un gran cambio cuando el software se trasladó a arquitecturas nativas de cloud. En SAP y más tarde en Aqua, vimos de primera mano que cuando el desarrollo cambia tanto, la seguridad suele quedarse atrás. La IA ha llevado esa verdad a un nivel completamente nuevo, no solo porque puede ayudar a escribir código más rápido, sino porque ha comenzado a cambiar todo el entorno que rodea la creación de software.

Proteger el código ya no se trata solo del código en sí, sino del entorno que lo rodea. En menos de un año, lo que solía ser un entorno de desarrollo relativamente contenido y de bajo riesgo se ha expandido en una superficie de ataque conectada y con poca supervisión o gobernanza. Una vez que sucedió esto, las preguntas de seguridad sobre vulnerabilidades de código cambiaron por completo. El problema real no es si un determinado trozo de código es vulnerable, sino que al habilitar el desarrollo impulsado por IA, hemos introducido sistemas, agentes, integraciones y rutas de acceso que se extienden mucho más allá del código en sí. La seguridad ya no puede centrarse solo en la salida del código, sino que debe tener en cuenta todo el entorno que hace posible ese código.

Describe el “vibe coding” como la expansión de la superficie de ataque más allá del código en promociones, agentes, servidores MCP y capas de herramientas. ¿Cuáles son los riesgos más malentendidos en esta nueva pila que los desarrolladores y los equipos de seguridad están pasando por alto actualmente?

El mayor malentendido es que muchos equipos aún creen que el riesgo reside principalmente en el código generado. Eso es solo una capa. En el desarrollo nativo de IA, el riesgo se introduce antes y en muchos más lugares. Esto podría ser en promociones, en el contexto suministrado al modelo, en los permisos otorgados a los agentes, en los servidores MCP a los que se conectan o en las herramientas y plugins externos que amplían su alcance. Un solo portátil de un usuario puede ser tomado y utilizado como el punto de partida de un ataque más amplio. Es un punto débil de endpoint que se disfraza como un problema de codificación de IA. A diferencia de las vulnerabilidades de código, esto no solo pone en riesgo las aplicaciones, sino que también puede poner en riesgo toda la organización. Si solo se examina el código, se pierde la mayor parte de la imagen.

La seguridad de aplicaciones tradicional se ha centrado mucho en la revisión de código. ¿Cómo debe evolucionar el pensamiento de seguridad cuando los agentes de IA generan, modifican y despliegan código en tiempo real?

La seguridad debe pasar de una inspección periódica a una supervisión continua. La noción de confianza está completamente rota: puede tener modelos y servidores MCP de confianza, pero debido a la naturaleza no determinista de la IA, aún pueden ser manipulados o simplemente comportarse de manera inesperada para crear riesgos inesperados.

Esto también significa que debe haber un cambio de mentalidad en el que la seguridad opera junto con el proceso de desarrollo a medida que sucede y tiene una gobernanza, guardias y capacidades de detección y respuesta mucho más profundas dentro de ese entorno. Eso significa pensar críticamente sobre qué herramientas se están utilizando, qué contexto están consumiendo, qué políticas deben regirlos y qué acciones están tomando en tiempo real.

Herramientas como Cursor, Claude Code y GitHub Copilot se están convirtiendo en estándar en los flujos de trabajo de los desarrolladores. ¿Dónde ve los mayores vacíos de seguridad cuando los equipos adoptan estas herramientas sin una capa de gobernanza adecuada?

El mayor vacío es la visibilidad. En muchas organizaciones, estas herramientas se están extendiendo rápidamente y sin una revisión formal. Los equipos de seguridad a menudo no saben qué agentes se están utilizando, cómo están configurados, qué datos pueden acceder o qué sistemas externos están conectados. Eso crea un problema de IA en la sombra, similar al de la IT en la sombra en principio, solo que más rápido y dinámico.

El segundo vacío más grande es la falta de políticas aplicables. La mayoría de las organizaciones pueden tener directrices, pero las directrices solas no ayudan mucho cuando un desarrollador se mueve rápidamente dentro del IDE. Sin gobernanza en la capa de herramientas y flujos de trabajo, los equipos arriesgan herramientas sobre-permitidas que no cumplen con los estándares empresariales. Estas herramientas no son inherentemente malas, pero adoptarlas sin gobernanza significa que efectivamente se está escalando la velocidad de desarrollo sin escalar el control.

Un tercer vacío emergente es que cualquier persona puede potencialmente convertirse en desarrollador, lo que llamamos desarrolladores ciudadanos, que utilizan herramientas de codificación de “vibe”. Cuando la persona de finanzas utiliza Claude Code para automatizar procesos y conectarse a sistemas internos, esto crea un riesgo potencial y es un punto ciego incluso hoy en día.

Backslash se enfoca en proteger todo el ecosistema de desarrollo de IA en lugar de herramientas individuales. ¿Por qué es necesario este enfoque de pila completa, y qué sucede si las organizaciones siguen tratando estos riesgos de manera aislada?

Porque el riesgo no se encuentra cómodamente dentro de ningún producto en la pila. El desarrollo nativo de IA es inherentemente un problema de ecosistema porque opera en muchos lugares diferentes, utilizando muchas herramientas diferentes. El IDE, el modelo, los agentes, los servidores MCP, los plugins externos, las identidades y las fuentes de datos conectadas influyen en lo que se construye y cómo. Las organizaciones no están estandarizando en una sola herramienta porque sus fortalezas relativas están cambiando muy rápidamente. Si se asegura solo un punto en esa cadena, aún se pierde cómo el riesgo se mueve a través del sistema.

Tratar estos riesgos de manera aislada conduce a defensas fragmentadas y puntos ciegos peligrosos. Puede endurecer el escáner de código, pero pasar por alto el servidor MCP que alimentó contexto riesgoso al modelo. Eso es por qué creemos que el enfoque correcto es la visibilidad y la protección en tiempo real en toda la pila de desarrollo de IA. De lo contrario, las organizaciones seguirán resolviendo síntomas mientras la superficie de ataque real sigue expandiéndose debajo de ellos.

La promoción está emergiendo como una nueva capa de programabilidad. ¿Cómo deben abordar las organizaciones la protección de las promociones y la prevención de problemas como la inyección de promociones, la fuga de datos o la manipulación?

Las promociones cada vez más dan forma a la lógica y el comportamiento. En muchos casos, son efectivamente un nuevo plano de control para la creación de software. Eso significa que necesitan política, monitoreo y guardias como el código o las definiciones de infraestructura. En la práctica, eso comienza con limitar qué pueden acceder las promociones y qué acciones pueden desencadenar. También significa definir reglas de promoción que se alineen con las expectativas de seguridad y calidad, prevenir que los datos sensibles sean expuestos a través de ventanas de contexto y vigilar intentos de manipulación como la inyección de promociones o la captura de instrucciones indirectas. Y también incluye asegurarse de que las reglas en sí no se utilicen como puertas traseras para la inyección de promociones. El punto más amplio es que no se protege la promoción instruyendo a los desarrolladores y agentes para que “tengan cuidado”. Se protege incorporando controles en el entorno donde realmente sucede la promoción.

Los servidores MCP y las habilidades de los agentes introducen conexiones dinámicas entre sistemas. Desde una perspectiva de seguridad, ¿representan el vector de riesgo más significativo en el desarrollo impulsado por IA?

Los servidores MCP y las habilidades de los agentes representan una capa de riesgo importante porque definen cómo los sistemas de IA se conectan y interactúan con el mundo real. Las habilidades definen lo que un agente está autorizado a hacer, mientras que MCP amplía su acceso a contexto y sistemas. Juntos, dan forma al comportamiento real del agente. Si esas capas no están controladas firmemente, las organizaciones pierden visibilidad en lo que pueden hacer y están haciendo realmente las herramientas de IA. El cambio de la generación de código a la toma de acciones es lo que hace que esta sea un área crítica para la seguridad, y se vuelven más impredecibles cuando se encadenan.

Una de sus principales temáticas es “ser el departamento de Sí” – permitir la seguridad sin frenar a los desarrolladores. ¿Cómo equilibra la protección en tiempo real con la velocidad de los desarrolladores en entornos donde la velocidad es crítica?

La seguridad crea fricción cuando sucede tarde o está desconectada de cómo los desarrolladores realmente trabajan. Se vuelve mucho más efectiva cuando se incorpora directamente en el flujo de trabajo y se centra en lo que realmente importa. Eso ha sido parte de nuestro pensamiento desde que Backslash comenzó, y importa aún más ahora en el desarrollo impulsado por IA.

En la práctica, eso significa mostrar los pocos problemas que representan un riesgo real, no inundar a los desarrolladores con todo lo que parece teóricamente sospechoso. Significa aplicar políticas en el flujo de trabajo del IDE y del agente, no después del hecho. Y significa crear guardias transparentes y deterministas para que los equipos puedan moverse rápidamente mientras aún saben qué herramientas están en uso, qué permisos tienen y cuándo algo anormal está sucediendo. El objetivo no es frenar la adopción de IA, sino ayudar a las organizaciones a adoptarla con confianza sin perder el control. En términos reales, esto significa que un desarrollador tendría menos espacio para cometer errores en primer lugar, pero si lo hace, se capturará y se manejará rápidamente.

Estamos viendo a usuarios no técnicos construir software cada vez más utilizando herramientas de IA. ¿Cómo cambia el panorama de amenazas la aparición de desarrolladores de “vibe” no técnicos?

Amplía el panorama de amenazas de dos maneras. Primero, aumenta drásticamente el número de personas que pueden producir resultados similares al software sin entender las implicaciones de seguridad. Segundo, crea una falsa sensación de seguridad porque las herramientas hacen que el desarrollo se sienta conversacional y de baja fricción.

Esto significa que las organizaciones verán más aplicaciones, automatizaciones e integraciones creadas por personas que no están capacitadas para considerar límites de confianza, validación de entrada, higiene de dependencia, control de acceso o exposición de datos. En otras palabras, la superficie de ataque se expande no solo porque la IA escribe más código, sino porque más personas pueden generar flujos de trabajo y sistemas que se comportan como software sin aplicar disciplina de ingeniería básica. Eso hace que la visibilidad y las salvaguardas incorporadas sean aún más importantes, porque ya no se puede asumir conocimiento de seguridad en el punto de creación.

Mirando hacia adelante 12 a 24 meses, ¿qué tipos de ataques o vulnerabilidades espera que surjan específicamente debido a los flujos de trabajo de desarrollo nativos de IA?

Esperamos que muchas de las vulnerabilidades de código comunes se eviten desde el principio a través de mejoras en los LLM en sí, o a través de reglas de promoción mejor incorporadas en el “arnés” que rodea esas herramientas. Si ahora estamos viendo un aumento en el volumen de vulnerabilidades simplemente debido a la mayor velocidad, esto se corregirá. Y lo que no se corrija será perseguido por SAST y SCA habilitados por IA (algunos de los cuales también serán proporcionados por los propios proveedores de plataformas de IA, por ejemplo, Claude Code Security y proyecto Glasswing).

Sin embargo, espero resultados mucho peores cuando se trate de exposiciones debido al uso de herramientas de IA no supervisadas y no verificadas en el desarrollo de aplicaciones, como agentes de código abierto (OpenClaw es un buen ejemplo), que tienen muy malas configuraciones de seguridad predeterminadas, combinadas con una base de usuarios cuyo conocimiento de seguridad está muy superado por su entusiasmo por la codificación de “vibe”.

Como consecuencia, creo que veremos un cambio hacia ataques que apuntan al ecosistema de desarrollo en sí, en lugar de solo a los sistemas de producción. A medida que la IA se convierte en parte de cómo se crea el software, los atacantes se centrarán en manipular las herramientas y conexiones que dan forma a ese proceso, comprometiendo efectivamente el software antes de que se despliegue.

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