Zaid Al Hamani, PDG et fondateur de Boost Security – Série d’entretiens

Zaid Al Hamani, PDG et fondateur de Boost Security, est un leader en cybersécurité et en DevSecOps avec plus de deux décennies d’expérience dans la construction et la mise à l’échelle d’opérations technologiques mondiales. Depuis la fondation de Boost Security en 2020, il s’est concentré sur la modernisation de la façon dont les organisations sécurisent le développement de logiciels, en tirant parti de ses précédents rôles, notamment celui de vice-président de la sécurité des applications chez Trend Micro et de co-fondateur et PDG d’IMMUNIO. Auparavant, il occupait des postes de direction chez Canonical, où il dirigeait les initiatives de produits, d’ingénierie et de support mondial, et chez SITA, où il gérait des opérations informatiques à grande échelle et critiques pour la mission. Sa carrière reflète un solide bilan de construction d’équipes, d’optimisation des systèmes et de promotion de pratiques de sécurité modernes.

Boost Security est une entreprise de cybersécurité axée sur la sécurisation de la chaîne d’approvisionnement logicielle moderne par le biais d’une plate-forme DevSecOps orientée développeur. Sa technologie s’intègre directement dans les pipelines CI/CD pour détecter, prioriser et remédier automatiquement aux vulnérabilités, réduisant ainsi la charge manuelle tout en maintenant la vitesse de développement. En unifiant la sécurité des applications et de la chaîne d’approvisionnement dans un seul système, la plate-forme offre une visibilité complète sur le code, les dépendances et l’infrastructure, aidant ainsi les organisations à renforcer leur résilience dans des environnements cloud natifs complexes.

Vous avez précédemment dirigé la sécurité des applications chez Trend Micro et co-fondé IMMUNIO. Qu’est-ce qui vous a amené à fonder Boost Security, et quel écart sur le marché étiez-vous particulièrement bien placé pour identifier tôt ?

IMMUN.IO était l’une des premières entreprises RASP à être fondée – et notre expérience jusqu’à ce point était que les WAF en tant que technologie de sécurité en temps réel étaient impossibles à maintenir et pas très efficaces. Nous avons imaginé un moyen de remplacer les WAF par une solution plus précise et plus facile à maintenir – en instrumentant l’application.

C’était en 2012, DevOps était encore en début, la plupart des équipes n’étaient pas Agile, et Kubernetes n’était pas encore une chose.

Trend Micro a acquis IMMUN.IO en 2017. À ce moment-là, il y avait beaucoup plus de pratiques DevOps : pipelines CI/CD, pratiques de développement Agile, cycles de publication plus rapides, cloud, etc. Les équipes de développement de logiciels étaient meilleures pour construire des logiciels et les livrer plus rapidement. La sécurité était toujours cassée, cependant :

• Les analyses sont trop lentes, ou les résultats arrivent trop tard
• Les résultats sont trop complexes pour que les développeurs puissent agir
• Il y a un taux de faux positifs généralement inacceptable
• De nombreux nouveaux types d’artefacts ne sont pas analysés : infrastructure en tant que code, conteneurs, API, par exemple

Produire des logiciels rapidement était plus facile. Produire des logiciels sécurisés rapidement était toujours difficile.

C’était le problème initial que nous nous sommes efforcés de résoudre. Faire fonctionner DevSecOps dans le monde réel ; pouvez-vous amener une équipe de développement de logiciels à ajouter facilement la sécurité dans le cycle de vie du développement logiciel, à une vitesse qui correspond aux nouvelles normes de vélocité ? Pouvez-vous rendre la couverture large – où une plate-forme est tout ce dont vous avez besoin ? Pouvez-vous le rendre ainsi que les développeurs, et non seulement adoptent la technologie, mais l’adoptent et voient les avantages ? Pouvez-vous le rendre ainsi que vous n’avez pas besoin d’armées de professionnels de la sécurité pour suivre la quantité de code écrit…

Nous avons aidé les entreprises à injecter la sécurité dans le cycle de vie du développement logiciel pendant l’ère DevOps. C’était passer de 1 à 10. Nous sommes maintenant dans l’ère de la codification agente – où les agents écrivent une quantité énorme de code – mais c’est fondamentalement le même problème – la vitesse et le volume de code sont passés de 10 à 100 ; et nous visons à continuer la même trajectoire.

Vous avez soutenu que le cycle de vie du développement logiciel (SDLC) a fondamentalement changé en amont. Quel a été le moment où vous avez réalisé que les approches traditionnelles de DevSecOps n’étaient plus suffisantes ?

C’était en regardant comment les attaquants obtenaient réellement accès. Nous voyions constamment le même modèle : un flux de travail GitHub Actions exposé que personne n’avait examiné depuis que le référentiel a été forké, un jeton avec un accès à la production cloud intégré dans une configuration de runner, un travail CI légitime détourné pour déployer des charges utiles d’attaquants. Ceux-ci sont devenus connus sous le nom d’attaques « vivant sur le pipeline » parce que l’adversaire utilise votre propre automation contre vous, avec des informations d’identification que votre équipe de sécurité a déjà approuvées.

La pile DevSecOps que nous avions construite au cours d’une décennie n’avait pas de réponse à cela. SAST analyse le code source de l’application. SCA analyse les dépendances de l’application. Les deux supposent que le pipeline qui les exécute est fiable. Pendant ce temps, le pipeline lui-même est un fichier YAML avec des commandes shell, un accès réseau et des informations d’identification sensibles, et presque personne ne le revoit.

Lorsque cela devient le chemin le plus facile, vous pouvez expédier du code parfaitement propre et toujours donner aux attaquants votre cloud.

Comment les entreprises devraient-elles repenser le SDLC dans un monde où les agents IA génèrent du code en continu plutôt que les développeurs qui l’écrivent étape par étape ?

Nous devons tous arrêter de penser au SDLC comme une séquence de points de contrôle. Les agents IA ont compressé le temps entre « quelqu’un a écrit cela » et « cela est en production » de semaines à minutes. Le vieux modèle supposait un rythme humain entre la révision de code, SAST, SCA et déploiement, mais nous sommes au-delà de cela maintenant.

La sécurité doit vivre où l’agent opère : sur la machine du développeur, dans le contexte de la invite, dans les connexions de l’agent aux serveurs MCP et aux modèles externes. Dès que le code atteint le pipeline, vous avez déjà perdu la chance de le façonner. L’agent a déjà tiré la dépendance. Le modèle a déjà vu les informations d’identification. Déplacez les contrôles en amont, là où le travail se déroule réellement.

De nombreuses organisations traitent toujours les outils de codage IA comme de simples couches de productivité. Pourquoi pensez-vous qu’ils représentent une toute nouvelle surface d’attaque plutôt que simplement une extension des flux de travail existants ?

Traiter un outil de codage IA comme une couche de productivité est comme traiter un développeur junior avec un accès root comme une couche de productivité. L’étiquette est techniquement exacte, mais elle ne vous donne aucun cadre utile pour réfléchir à ce qui pourrait mal se passer.

Un agent de codage lit votre système de fichiers, gratte les variables d’environnement pour le contexte, récupère les dépendances à partir de registres publics, ouvre des connexions sortantes vers les fournisseurs de modèles et les serveurs MCP, et exécute des commandes shell. Chacune de ces actions nécessitait auparavant un humain dans la boucle. Maintenant, elles se produisent en millisecondes, avec les mêmes privilèges que le développeur qui a lancé l’agent.

Cette compression fusionne les limites de confiance qui étaient séparées : l’autorité du développeur, ce qu’un outil externe peut récupérer et ce que du code non fiable peut exécuter. Cela crée de nouvelles opportunités pour les attaquants et des angles morts que les défenseurs ne peuvent même pas voir, encore moins défendre.

Boost présente le laptop du développeur comme le nouveau plan de contrôle. Quels risques existent-ils sur le point de terminaison que les équipes de sécurité négligent actuellement ?

Le plus grand est l’inventaire. La plupart des équipes de sécurité ne peuvent pas vous dire quels agents IA sont en cours d’exécution sur quels laptops, quels serveurs MCP ces agents sont connectés, ou quelles extensions IDE sont en train de gratter le contenu du référentiel en ce moment. L’EDR n’a pas de visibilité dans la couche de l’agent ; le SIEM ne peut pas non plus voir ce que font ces agents localement.

En dessous de cela se trouve le désordre des informations d’identification. Nous avons construit un outil open source appelé Bagel en partie pour concrétiser cela. Un laptop de développeur typique contient des jetons GitHub avec un accès en écriture à des référentiels de production, des informations d’identification cloud qui peuvent lancer des infrastructures, des jetons npm ou PyPI qui peuvent publier vers des millions d’utilisateurs, et des clés de service IA que les attaquants revendent. Aucun de ceux-ci n’est durci de la même manière qu’un runner CI est durci. La même machine qui contient ces informations d’identification navigue également sur le Web et installe des extensions VS Code aléatoires.

Associez les deux et vous avez la véritable surface d’attaque. Une extension non fiable s’exécutant avec des privilèges de développeur dans un environnement rempli de clés cloud est la cible la plus rentable dans l’entreprise moderne. La plupart des équipes n’ont pas encore commencé à regarder cela.

Vous avez mis en évidence le « piège de contexte », où les agents IA peuvent accéder à des fichiers locaux, des variables d’environnement et des configurations. À quel point le risque de fuite de données sensibles par le biais des invites est-il répandu, et pourquoi est-il si difficile à détecter ?

Assez répandu pour que nous le traitions comme l’état par défaut de tout environnement de développeur non géré. Chaque agent de codage que nous avons inspecté récupère agressivement le contexte local. Ils lisent les fichiers dot, les variables d’environnement, les fichiers récents, parfois des arbres de répertoires entiers, et expédient ce contexte à un modèle distant. Les outils sont conçus pour fonctionner de cette manière ; la récupération agressive de contexte est ce qui les rend utiles.

Le problème de détection commence parce que le trafic d’une fuite ressemble exactement à une utilisation normale du produit. Il s’agit de TLS vers api.openai.com ou api.anthropic.com. Il provient d’une application commerciale approuvée. La DLP standard voit un développeur utilisant l’outil IA que l’entreprise vient d’acheter une licence. Il ne voit pas qu’une des chaînes dans cette invite est une clé secrète AWS que l’agent a récupérée à partir d’un fichier .env à moitié oublié dans un répertoire frère.

Vous ne le détectez que si vous inspectez les invites avant qu’elles quittent le laptop, ce qui est exactement là où presque aucune pile de sécurité n’est actuellement positionnée.

Vous mentionnez des attaques de chaîne d’approvisionnement à vitesse machine. Pouvez-vous décrire un scénario réaliste dans lequel un agent IA introduit une vulnérabilité plus rapidement que les outils de sécurité traditionnels ne peuvent l’identifier ?

Voici l’un que nous avons vu des variations à plusieurs reprises. Un développeur demande à un agent d’ajouter une fonctionnalité qui nécessite une bibliothèque de réessai HTTP. L’agent suggère un nom de package. Le package est plausible mais n’existe pas réellement sur npm. Dans l’heure qui suit, un attaquant l’enregistre, le remplit avec une logique de réessai fonctionnelle ainsi qu’un petit script post-install qui lit ~/.aws/credentials et les publie sur un webhook. L’agent exécute npm install sans vérifier, car les agents ne vérifient pas la réputation. Les informations d’identification sont parties avant même que le développeur n’exécute le code.

L’attaque elle-même n’est pas techniquement sophistiquée, mais la sécurité de la chaîne d’approvisionnement traditionnelle est construite autour de vulnérabilités connues dans des packages connus : CVE, SBOM, analyse de licence. Ce cadre n’a rien à dire sur un package qui n’existait pas lorsque l’analyse a été exécutée pour la dernière fois, a été créé spécifiquement pour correspondre à une hallucination IA et est ingéré avant que les flux de menace ne soient mis à jour.

La fenêtre de publication à compromis est maintenant mesurée en minutes. Tout ce qui vérifie après les faits vérifie trop tard.

Les dépendances hallucinées deviennent-elles l’un des plus grands risques dans le développement piloté par IA, et quels sont les mesures pratiques que les organisations peuvent prendre pour se défendre contre elles ?

Ils sont déjà l’un des plus grands. Les attaquants surveillent activement les outils IA populaires pour les hallucinations et enregistrent les noms de packages suggérés dans les minutes qui suivent. Les chercheurs il y a quelques années, lorsque cela a commencé à se produire, l’ont appelé slopsquatting et le nom est resté. Une fois qu’un nom de dépendance est halluciné suffisamment fréquemment, s’y asseoir est une attaque de chaîne d’approvisionnement passive avec un effort presque nul.

Les défenses pratiques ont l’air différentes de ce que la plupart des équipes ont actuellement. Commencez par l’ingestion. Bloquez les packages typosquattés et nouvellement enregistrés au moment où npm install ou pip install s’exécute, sur la machine du développeur, avant que quoi que ce soit n’atteigne le disque. La détection post-mortem dans CI ne aide pas lorsque un script post-install a déjà exfiltré une information d’identification. Ensuite, donnez à l’agent des garde-fous pour opérer à l’intérieur. Injectez votre liste de dépendances approuvées directement dans le contexte de l’agent, afin que le modèle voie ce qui est autorisé avant de générer une suggestion. Demander aux développeurs d’écrire des « invites sécurisées » n’est pas une stratégie. Si vous êtes stratégique, cela signifie que la sécurité définit la limite, l’agent l’hérite. Et commencez à suivre une facture de matériel IA. La plupart des équipes ne peuvent pas vous dire quels agents, modèles et packages touchent quels référentiels. Vous ne pouvez pas défendre ce que vous ne pouvez pas inventorier.

Vous avez déclaré que la sécurité ne peut plus commencer à CI/CD. À quoi ressemble une pipeline de sécurité moderne lorsque la protection doit commencer plus tôt dans le processus de développement ?

Si la sécurité commence à CI/CD, vous avez cédé la phase pré-engagement à un environnement que vous ne contrôlez pas. L’agent a déjà ingéré le contexte, vos informations d’identification peuvent déjà être dans les journaux de quelqu’un d’autre. Vous analysez un cadavre.

Une pipeline moderne commence sur le laptop. Cela signifie inventorier les agents et les extensions qui s’exécutent là, valider quels serveurs MCP et quels modèles ils sont autorisés à parler, nettoyer ce qui quitte la machine et bloquer les packages malveillants avant qu’ils ne s’installent. À partir de là, la politique suit le travail dans l’IDE. Nous injectons les normes de sécurité directement dans la fenêtre de contexte de l’agent afin que le code généré reste à l’intérieur des garde-fous dès le premier jeton. La pipeline s’exécute toujours, faisant une vérification finale sur les contrôles qui ont déjà été appliqués en amont.

La pipeline elle-même ne disparaît pas. Son rôle devient la vérification : confirmer que les contrôles en amont ont tenu.

Alors que les organisations continuent d’adopter des agents de codage IA, quels sont les changements les plus critiques qu’elles doivent apporter aujourd’hui pour garantir que leurs environnements de développement restent sécurisés au cours des prochaines années ?

L’erreur la plus grande est de sécuriser uniquement ce qui est validé. Le risque intéressant vit maintenant dans les huit heures avant qu’une validation se produise. Un drame invisible peut se dérouler sur le laptop, dans l’invite ou dans l’installation du package. Si vos outils commencent à la PR, vous protégez la mauvaise moitié du flux de travail.

Lié à cela : arrêtez de traiter les agents de codage comme des logiciels de productivité. Ils sont des utilisateurs non humains avec un accès shell, des privilèges d’écriture de référentiel et des connexions réseau sortantes. Gérez-les de la même manière que vous gérez toute autre identité privilégiée, avec un inventaire, des capacités approuvées et des journaux d’audit.

Le dernier déplacement est plus difficile sur le plan culturel. La plupart des outils de « sécurité IA » actuels affichent des résultats et les acheminent vers les humains. Les humains ne peuvent pas trier à la vitesse à laquelle les agents les génèrent. Tout ce que vous adoptez doit résoudre les problèmes automatiquement à l’intérieur du flux de travail, avec un raisonnement traçable, ou cela devient un autre tableau de bord que personne ne lit.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Boost Security.