Shahar Man, co-fondateur et PDG de Backslash Security – Série d’entretiens

Shahar Man, co-fondateur et PDG de Backslash Security, est un leader technologique expérimenté avec une expertise approfondie dans le développement cloud, la cybersécurité et les logiciels d’entreprise. Il dirige actuellement Backslash Security, une entreprise qui se concentre sur la sécurisation des environnements de développement de logiciels natifs en IA, en protégeant tout, des IDE et des agents IA aux codes générés et aux flux de travail de prompt. Auparavant, il a occupé des postes de direction chez Aqua Security, où il a été vice-président de la gestion de produits et vice-président de la R&D, aidant à construire l’une des principales plateformes de sécurité de conteneur tout au long du cycle de développement. Plus tôt dans sa carrière, Man a passé plus d’une décennie chez SAP, où il a dirigé des initiatives de développement et de produits, notamment SAP Web IDE, et a travaillé en étroite collaboration avec des clients d’entreprise mondiaux, tout en contribuant à la croissance de l’écosystème des développeurs. Sa carrière a commencé dans des rôles techniques et de direction dans des environnements de startup et des unités de technologie de défense israéliennes, lui donnant une solide formation en ingénierie et en systèmes à grande échelle.

Backslash Security est une plateforme de cybersécurité émergente conçue spécifiquement pour l’ère du développement de logiciels piloté par l’IA. L’entreprise se concentre sur la sécurisation de l’ensemble de la pile de développement native en IA, y compris les agents IA, les pipelines de génération de code et les flux de travail de développement modernes, un domaine que les outils de sécurité traditionnels ignorent souvent. En fournissant une visibilité, une gouvernance et une protection en temps réel sans perturber la vitesse des développeurs, Backslash vise à répondre aux risques croissants introduits par la codification automatisée et les environnements de « vibe coding ». Alors que la création de logiciels se déplace de plus en plus vers des systèmes assistés par l’IA, la plateforme est conçue pour garantir que la sécurité évolue en parallèle plutôt que de devenir un goulet d’étranglement, positionnant Backslash à l’intersection de DevSecOps et du développement d’IA de nouvelle génération.

Vous avez occupé des postes de direction dans la gestion de produits et la R&D chez des entreprises comme Aqua Security et SAP avant de fonder Backslash. Quels sont les premiers signaux qui vous ont convaincu que le développement natif en IA et le « vibe coding » allaient fondamentalement remodeler la création de logiciels, et que la sécurité devait être reconstruite pour les soutenir ?

J’avais déjà vécu un changement majeur lorsque les logiciels sont passés aux architectures cloud natives. Chez SAP et plus tard chez Aqua, nous avons vu de visu que lorsque le développement change autant, la sécurité est généralement en retard. L’IA a porté cette vérité à un tout nouveau niveau, non seulement parce qu’elle peut aider à écrire du code plus rapidement, mais parce qu’elle a commencé à remodeler l’ensemble de l’environnement autour de la création de logiciels.

La sécurisation du code n’est plus seulement une question de code lui-même, mais plutôt de l’environnement qui l’entoure. En moins d’un an, ce qui était autrefois un ensemble de développement relativement contenu et à faible risque s’est étendu en une vaste surface d’attaque hautement connectée avec peu de surveillance ou de gouvernance. Une fois que cela s’est produit, les questions de sécurité autour des vulnérabilités du code ont changé complètement. Le véritable problème n’est pas de savoir si un morceau de code donné est vulnérable, mais plutôt que, en permettant le développement piloté par l’IA, nous avons introduit des systèmes, des agents, des intégrations et des chemins d’accès qui s’étendent bien au-delà du code lui-même. La sécurité ne peut plus se concentrer uniquement sur la sortie du code ; elle doit prendre en compte l’ensemble de l’environnement qui rend ce code possible.

Vous décrivez le « vibe coding » comme l’expansion de la surface d’attaque au-delà du code vers les invites, les agents, les serveurs MCP et les couches d’outils. Quels sont les risques les plus mal compris dans cette nouvelle pile que les développeurs et les équipes de sécurité négligent actuellement ?

La plus grande méconnaissance est que de nombreuses équipes pensent encore que le risque réside principalement dans le code généré. Ce n’est qu’une couche. Dans le développement natif en IA, le risque est introduit plus tôt et dans de nombreux endroits. Cela peut être dans les invites, dans le contexte fourni au modèle, dans les autorisations accordées aux agents, dans les serveurs MCP auxquels ils se connectent ou dans les outils et plugins externes qui étendent leur portée. Un seul ordinateur portable d’un utilisateur peut être pris en charge et utilisé comme tête de pont d’une attaque plus large. Il s’agit d’un point de vulnérabilité de point de terminaison se faisant passer pour un problème de codage IA. Contrairement aux vulnérabilités du code, cela ne met pas seulement les applications à risque, mais peut également mettre l’ensemble de l’organisation à risque. Si vous ne regardez que le code, vous manquez la majeure partie du tableau.

La sécurité des applications traditionnelles s’est concentrée lourdement sur la revue de code. Comment la réflexion sur la sécurité doit-elle évoluer lorsque les agents IA génèrent, modifient et déployent du code en temps réel ?

La sécurité doit passer d’une inspection périodique à une surveillance continue. La notion de confiance est complètement rompue – vous pouvez avoir des modèles et des serveurs MCP de confiance, mais en raison de la nature non déterministe de l’IA, ils peuvent toujours être manipulés ou simplement se comporter de manière inattendue pour créer des risques inattendus.

Cela signifie également qu’il doit y avoir un changement de mentalité dans lequel la sécurité opère aux côtés du processus de développement à mesure qu’il se déroule et a une gouvernance, des garde-fous et des capacités de détection et de réponse beaucoup plus profondes dans cet environnement. Cela signifie réfléchir de manière critique aux outils utilisés, au contexte qu’ils consomment, aux politiques qui les régissent et aux actions qu’ils prennent en temps réel.

Des outils comme Cursor, Claude Code et GitHub Copilot deviennent standard dans les flux de travail des développeurs. Où voyez-vous les plus grands écarts de sécurité lorsque les équipes adoptent ces outils sans une couche de gouvernance appropriée ?

Le plus grand écart est la visibilité. Dans de nombreuses organisations, ces outils se propagent rapidement sans examen formel. Les équipes de sécurité ne savent souvent pas quels agents sont utilisés, comment ils sont configurés, quels données ils peuvent accéder ou quels systèmes externes ils sont connectés. Cela crée un problème d’IA fantôme, similaire au principe de l’IT fantôme, mais plus rapide et plus dynamique.

Le deuxième plus grand écart est le manque de politiques applicables. La plupart des organisations peuvent avoir des lignes directrices, mais les lignes directrices seules n’aident pas beaucoup lorsque qu’un développeur bouge rapidement à l’intérieur de l’IDE. Sans gouvernance au niveau de l’outil et du flux de travail, les équipes risquent d’avoir des outils sur-autorisés qui ne répondent pas aux normes d’entreprise. Ces outils ne sont pas intrinsèquement mauvais, mais les adopter sans gouvernance signifie que vous écalez la vitesse de développement sans échelle de contrôle.

Un troisième écart émergeant est que tout le monde peut potentiellement devenir développeur – ce que nous appelons les développeurs citoyens, utilisant des outils de « vibe coding ». Lorsque la personne des finances utilise Claude Code pour automatiser les processus et se connecter à des systèmes internes, cela crée un risque potentiel et constitue un point aveugle important, même aujourd’hui.

Backslash se concentre sur la sécurisation de l’ensemble de l’écosystème de développement d’IA plutôt que d’outils individuels. Pourquoi cette approche full-stack est-elle nécessaire, et qu’est-ce qui se passe si les organisations continuent de traiter ces risques de manière isolée ?

Parce que le risque ne réside pas dans un produit spécifique de votre pile. Le développement natif en IA est inhérentement un problème d’écosystème, car il opère dans de nombreux endroits différents, en utilisant de nombreux outils différents. L’IDE, le modèle, les agents, les serveurs MCP, les plugins externes, les identités et les sources de données connectées influencent toutes ce qui est construit et comment. Les organisations ne standardisent pas délibérément sur un seul outil, car leurs forces relatives changent si rapidement. Si vous sécurisez uniquement un point de cette chaîne, vous manquez toujours la façon dont le risque se déplace dans le système.

Le traitement de ces risques de manière isolée conduit à des défenses fragmentées et à des points aveugles dangereux. Vous pouvez durcir l’analyseur de code, mais ignorer le serveur MCP qui a alimenté un contexte risqué dans le modèle. C’est pourquoi nous croyons que l’approche appropriée est la visibilité full-stack et la protection en temps réel sur l’ensemble de l’écosystème de développement d’IA. Sinon, les organisations continueront à résoudre les symptômes tandis que la surface d’attaque réelle continue de s’étendre en dessous d’elles.

La saisie émerge comme une nouvelle couche de programmabilité. Comment les organisations devraient-elles aborder la sécurisation des invites et la prévention de problèmes tels que l’injection d’invite, la fuite de données ou la manipulation ?

Les invites façonnent de plus en plus la logique et le comportement. Dans de nombreux cas, elles constituent effectivement un nouveau plan de contrôle pour la création de logiciels. Cela signifie qu’elles nécessitent une politique, une surveillance et des garde-fous, tout comme les définitions de code ou d’infrastructure le feraient. Dans la pratique, cela commence par limiter ce que les invites peuvent accéder et quelles actions en aval elles peuvent déclencher. Cela signifie également définir des règles d’invite qui s’alignent sur les attentes de sécurité et de qualité, empêcher l’exposition de données sensibles via les fenêtres de contexte et surveiller les tentatives de manipulation telles que l’injection d’invite ou le détournement d’instruction indirect. Et cela inclut également de garantir que les règles elles-mêmes ne sont pas utilisées comme des portes dérobées pour l’injection d’invite. Le point plus large est que vous ne sécurisez pas l’invite en demandant aux développeurs et aux agents d’être « prudents ». Vous les sécurisez en intégrant des contrôles dans l’environnement où l’invite se produit réellement.

Les serveurs MCP et les compétences des agents introduisent des connexions dynamiques entre les systèmes. Du point de vue de la sécurité, représentent-ils le nouveau vecteur de risque le plus important dans le développement piloté par l’IA ?

Les serveurs MCP et les compétences des agents représentent une nouvelle couche majeure de risque, car ils définissent la façon dont les systèmes IA se connectent à et interagissent avec le monde réel. Les compétences définissent ce qu’un agent est habilité à faire, tandis que MCP étend son accès au contexte et aux systèmes. Ensemble, ils façonnent le comportement réel de l’agent. Si ces couches ne sont pas étroitement contrôlées, les organisations perdent la visibilité de ce que leurs outils IA sont capables de faire et de ce qu’ils font réellement. Le passage de la génération de code à l’action est ce qui rend ce domaine si critique pour la sécurité, et ils deviennent plus imprévisibles lorsqu’ils sont enchaînés.

L’une de vos thèmes principaux est « être le département du Oui » – permettre la sécurité sans ralentir les développeurs. Comment équilibrez-vous la protection en temps réel avec la vitesse des développeurs dans des environnements où la vitesse est critique ?

La sécurité crée des frictions lorsqu’elle se produit tard ou est déconnectée de la façon dont les développeurs travaillent réellement. Elle devient beaucoup plus efficace lorsqu’elle est intégrée directement dans le flux de travail et axée sur ce qui compte vraiment. Cela a fait partie de notre réflexion depuis le début de Backslash, et cela compte encore plus maintenant dans le développement piloté par l’IA.

Dans la pratique, cela signifie mettre en évidence les quelques problèmes qui représentent un risque réel, et non inonder les développeurs de tout ce qui semble théoriquement suspect. Cela signifie appliquer les politiques dans le flux de travail de l’IDE et de l’agent, et non après coup. Et cela signifie créer des garde-fous transparents et déterministes pour que les équipes puissent bouger rapidement tout en sachant quels outils sont utilisés, quels sont leurs droits et quand quelque chose de inhabituel se produit. L’objectif n’est pas de ralentir l’adoption de l’IA, mais d’aider les organisations à l’adopter avec confiance sans perdre le contrôle. Dans les faits, cela signifie qu’un développeur aurait moins de marge pour faire des erreurs en premier lieu, mais si elle en fait une, elle sera rapidement détectée et traitée.

Nous voyons de plus en plus d’utilisateurs non techniques construire des logiciels à l’aide d’outils IA. Comment l’essor des « vibe coders » non développeurs change-t-il le paysage des menaces ?

Cela élargit le paysage des menaces de deux manières. Premièrement, cela augmente considérablement le nombre de personnes qui peuvent produire des sorties similaires à des logiciels sans comprendre les implications de sécurité. Deuxièmement, cela crée un faux sentiment de sécurité, car les outils rendent le développement conversatif et à faible friction.

Cela signifie que les organisations verront plus d’applications, d’automatisations et d’intégrations créées par des personnes qui ne sont pas formées pour considérer les limites de confiance, la validation des entrées, l’hygiène des dépendances, le contrôle d’accès ou l’exposition des données. En d’autres termes, la surface d’attaque s’étend non seulement parce que l’IA écrit plus de code, mais parce que plus de personnes peuvent maintenant générer des flux de travail et des systèmes qui se comportent comme des logiciels sans appliquer les disciplines d’ingénierie de base. Cela rend la visibilité et les garanties intégrées encore plus importantes, car vous ne pouvez plus supposer des connaissances en matière de sécurité au point de création.

En regardant vers l’avenir, sur 12 à 24 mois, quels types d’attaques ou de vulnérabilités attendez-vous d’émerger spécifiquement en raison des flux de travail de développement natif en IA ?

Nous attendons que de nombreuses vulnérabilités de code courantes soient évitées dès le départ grâce à l’amélioration des LLM eux-mêmes, ou grâce à de meilleures règles d’invite intégrées dans le « harnais » qui entoure ces outils. Si nous voyons actuellement une augmentation du volume de vulnérabilités simplement en raison de la vitesse accrue, cela se corrigera. Et ce qui ne sera pas corrigé sera poursuivi par la SAST et la SCA activées par l’IA (certaines d’entre elles seront également fournies par les fournisseurs de plateformes IA, par exemple Claude Code Security et le projet Glasswing).

Cependant, je m’attends à des résultats beaucoup plus graves lorsqu’il s’agit d’expositions dues à l’utilisation d’outils IA non vérifiés et non supervisés dans le développement d’applications – tels que les agents open source (OpenClaw est un bon exemple), qui ont de très mauvaises configurations de sécurité par défaut, couplées à une base d’utilisateurs dont les connaissances en matière de sécurité sont loin d’être surpassées par leur enthousiasme pour le « vibe coding ».

Par conséquent, je pense que nous allons voir un déplacement vers des attaques ciblant l’écosystème de développement lui-même plutôt que seulement les systèmes de production. Alors que l’IA fait partie de la création de logiciels, les attaquants se concentreront sur la manipulation des outils et des connexions qui façonnent ce processus, compromettant efficacement les logiciels avant même qu’ils ne soient déployés.

Je vous remercie pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Backslash Security.