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 una profunda experiencia 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 prompting. 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 a lo largo del ciclo de vida del 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 roles técnicos y de liderazgo en entornos de startup y unidades de tecnología de defensa de Israel, lo que le dio una sólida base 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 centra 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 desarrolladores 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 pretende 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 de que la seguridad necesitaba ser reconstruida para respaldarlo?

Ya había vivido un cambio importante 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 remodelar todo el entorno que rodea la creación de software.

Seguir la seguridad del código es ahora menos sobre el código en sí y más sobre el 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 vasta y altamente conectada 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 fragmento de código es vulnerable. El problema es 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. 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 prompts, 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 prompts, 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 extienden su alcance. Un laptop de un solo usuario puede ser tomado y utilizado como el punto de partida de un ataque más amplio. Es un punto de dolor 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 sus aplicaciones, sino que también puede poner en riesgo toda su organización. Si solo se mira el código, se está perdiendo 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 la inspección periódica a la 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 mal 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 vacío más grande 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 sombra IT 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 por sí 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 sobrepasadas 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.

Backslash se centra 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 continúan tratando estos riesgos de forma aislada?

Porque el riesgo no se encuentra únicamente dentro de un producto en su 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, las herramientas y 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 solo se segura un punto en esa cadena, aún se pierde cómo el riesgo se mueve a través del sistema.

La prompting está surgiendo como una nueva capa de programabilidad. ¿Cómo deben abordar las organizaciones la seguridad de las prompts y la prevención de problemas como la inyección de prompts, la fuga de datos o la manipulación?

Las prompts 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 lo harían. En la práctica, eso comienza limitando qué pueden acceder las prompts y qué acciones pueden desencadenar. También significa definir reglas de prompts que se alineen con las expectativas de seguridad y calidad, prevenir la exposición de datos sensibles a través de ventanas de contexto y vigilar intentos de manipulación como la inyección de prompts o el secuestro 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 prompts. El punto más amplio es que no se segura la prompting instruyendo a los desarrolladores y agentes para que “tengan cuidado”. Se segura incorporando controles en el entorno donde realmente sucede la prompting.

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 el MCP extiende 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 sobre 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 temáticas principales 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.

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 “vibe coders” no desarrolladores?

Amplía el panorama de amenazas de dos maneras. Primero, aumenta dramáticamente el número de personas que pueden producir salidas similares a 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 bajo riesgo.

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 dependencias, 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 ahora 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 de antemano a través de mejoras en los LLM en sí, o a través de reglas de prompts mejor incrustadas 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).

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