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 intelligence artificielle, en protégeant tout, des IDE et des agents d’intelligence artificielle au code généré 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 base à la fois dans l’ingénierie et les 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’intelligence artificielle. L’entreprise se concentre sur la sécurisation de l’ensemble de la pile de développement native en intelligence artificielle, y compris les agents d’intelligence artificielle, 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ésoudre les risques croissants introduits par les environnements de codage automatisés et les environnements de « vibe coding ». À mesure que la création de logiciels se déplace de plus en plus vers des systèmes assistés par l’intelligence artificielle, 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’intelligence artificielle de nouvelle génération.

Vous avez occupé des postes de direction dans les produits et la R&D chez des entreprises comme Aqua Security et SAP avant de fonder Backslash. Quels sont les signaux précoces qui vous ont convaincu que le développement natif en intelligence artificielle 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 grand changement 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’intelligence artificielle 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 est maintenant moins axée sur le code lui-même et plus sur 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. Le problème est que, en permettant le développement piloté par l’intelligence artificielle, 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 tenir compte de 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é ignorent actuellement ?

La plus grande mécompréhension 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 intelligence artificielle, le risque est introduit plus tôt et dans de nombreux endroits. Cela pourrait ê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 douleur de point de terminaison se faisant passer pour un problème de codage d’intelligence artificielle. Contrairement aux vulnérabilités du code, cela ne met pas seulement les applications à risque – cela peut 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 pensée de sécurité doit-elle évoluer lorsque les agents d’intelligence artificielle 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 brisée – vous pouvez avoir des modèles et des serveurs MCP de confiance, mais en raison de la nature non déterministe de l’intelligence artificielle, 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 devraient les régir 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 répandent 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’intelligence artificielle fantôme, similaire au problème d’IT fantôme en principe, 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.

Backslash se concentre sur la sécurisation de l’ensemble de l’écosystème de développement d’intelligence artificielle 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 en isolation ?

Parce que le risque ne réside pas nettement à l’intérieur d’un produit unique dans votre pile. Le développement natif en intelligence artificielle 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 tous ce qui est construit et comment. Les organisations ne standardisent pas délibérément sur un outil unique car leurs forces relatives changent très rapidement. Si vous sécurisez uniquement un point de cette chaîne, vous manquez encore de savoir comment le risque se déplace dans le système.

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 sont effectivement un nouveau plan de contrôle pour la création de logiciels. Cela signifie qu’elles ont besoin de politique, de surveillance et de garde-fous, tout comme les définitions de code ou d’infrastructure le feraient. En 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 les données sensibles d’être exposées à travers 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 s’assurer 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 disant aux développeurs et aux agents d’« être prudent ». Vous 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. D’un point de vue de sécurité, représentent-ils le nouveau vecteur de risque le plus significatif dans les flux de travail de développement pilotés par l’intelligence artificielle ?

Les serveurs MCP et les compétences des agents représentent une nouvelle couche majeure de risque, car ils définissent comment les systèmes d’intelligence artificielle se connectent à et interagissent avec le monde réel. Les compétences définissent ce qu’un agent est habilité à faire, tandis que le serveur 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é sur ce que leurs outils d’intelligence artificielle sont capables de faire et ce qu’ils font réellement. Le passage de la génération de code à l’exécution d’actions 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’un 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 de la friction 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 se concentre sur ce qui compte vraiment. Cela a fait partie de notre réflexion depuis que Backslash a commencé, et cela compte encore plus maintenant dans le développement piloté par l’intelligence artificielle.

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

Il élargit le paysage des menaces de deux manières. Premièrement, il augmente considérablement le nombre de personnes qui peuvent produire des sorties similaires à des logiciels sans comprendre les implications de sécurité. Deuxièmement, il crée un faux sentiment de sécurité, car les outils rendent le développement conversationnel 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’intelligence artificielle é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 principes d’ingénierie de base. Cela rend la visibilité et les garanties intégrées encore plus importantes, car on ne peut plus supposer des connaissances en matière de sécurité au point de création.

En regardant vers les 12 à 24 prochains 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 intelligence artificielle ?

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 modèles de langage, 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 due à 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’intelligence artificielle (certaines de ces dernières seront également fournies par les fournisseurs de plateformes d’intelligence artificielle, par exemple, Claude Code Security et le projet Glasswing).

Cependant, j’attends des résultats beaucoup plus graves lorsqu’il s’agit d’expositions dues à l’utilisation d’outils d’intelligence artificielle 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 égalé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 les seuls systèmes de production. À mesure que l’intelligence artificielle 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 ainsi efficacement les logiciels avant même qu’ils ne soient déployés. Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Backslash Security.