Willem Delbare, Co-Fondateur et PDG d’Aikido – Série d’entretiens

Willem Delbare, Co-Fondateur et PDG d’Aikido, est un entrepreneur en série de logiciels en tant que service et un fondateur technique avec une solide expérience dans la construction d’entreprises de logiciels axées sur les développeurs. Avant de lancer Aikido en 2022, il a co-fondé la plate-forme RH Officient, l’initiative de durabilité FutureproofedCities et la société CRM Teamleader, où il a occupé le poste de CTO et a aidé à développer l’entreprise en l’une des réussites les plus notables de la Belgique dans le domaine des logiciels en tant que service. Tout au long de sa carrière, Delbare s’est concentré sur la simplification de défis techniques complexes dans les infrastructures cloud, la scalabilité des logiciels en tant que service et la cybersécurité. Sous sa direction, Aikido a rapidement grandi pour devenir l’une des startups de cybersécurité à la croissance la plus rapide en Europe en se concentrant sur des solutions de sécurité pratiques conçues pour les équipes de développement modernes.

Aikido est une entreprise de cybersécurité basée en Belgique qui aide les développeurs et les équipes d’ingénieurs à sécuriser les applications et les environnements cloud grâce à une plate-forme unifiée. L’entreprise combine plusieurs fonctions de sécurité telles que l’analyse de code, l’analyse de dépendances, la gestion de la posture de sécurité cloud, la protection en temps réel et les tests assistés par l’IA dans un système rationalisé. Son approche est conçue pour réduire la complexité, minimiser les faux positifs et éliminer la nécessité pour les organisations de gérer des piles de sécurité fragmentées auprès de plusieurs fournisseurs. Conçue avec une philosophie axée sur le développeur, Aikido met l’accent sur l’automatisation, la surveillance continue et les flux de travail de remédiation simplifiés pour aider les entreprises à intégrer la sécurité directement dans le cycle de vie de développement logiciel.

Quelles expériences issues de la construction et de la mise à l’échelle d’entreprises comme Teamleader et Officient vous ont amené à fonder Aikido Security en 2022, et comment votre expérience en tant que fondateur technique a façonné votre vision pour créer une approche plus conviviale pour les développeurs en matière de cybersécurité ?

Au cours de la dernière décennie, j’ai trouvé ma vocation dans les logiciels en tant que service B2B. Avec trois startups en tant que co-fondateur technique et CTO et trois sorties dans les domaines des ressources humaines, de la technologie de facturation et de la comptabilité carbone. Tous ces mondes sont très différents, mais avec la même obsession de construire des logiciels qui ne font pas vouloir jeter son ordinateur portable par la fenêtre.

Mais dans chacune de ces entreprises, la sécurité me gardait éveillé la nuit. La peur d’une violation de données était réelle, et les outils censés aider ressemblaient à l’intérieur d’un cockpit de F-16. Coûteux, accablants et conçus pour quelqu’un titulaire d’un doctorat en informatique, et non pour une équipe de développement qui essaie de livrer rapidement.

Nous avons fondé Aikido Security pour résoudre directement ce défi. Aikido fournit une plate-forme de sécurité logicielle unifiée et axée sur le développeur pour les organisations de toutes tailles, qui rassemble les fonctionnalités de sécurité essentielles sur le code, le cloud et le temps d’exécution en un seul endroit pour faciliter aux développeurs la livraison de logiciels en toute sécurité.

Depuis, l’IA a rendu la livraison de logiciels encore plus rapide et la surface d’attaque plus grande. Notre prochain chapitre consiste à permettre aux organisations de suivre le rythme d’un logiciel auto-sécurisant.

En février, nous avons lancé Aikido Infinite, notre solution de test de pénétration continu à l’aide de l’IA qui valide l’exploitabilité et ferme la boucle de remédiation avant que le code n’atteigne la production.

Les environnements de développement sont maintenant décrits comme l’un des principaux angles morts de la sécurité. Qu’est-ce qui a changé récemment pour en faire une question si critique ?

Les ordinateurs des développeurs ont toujours été des cibles précieuses. Ils contiennent des informations d’identification cloud, des clés SSH, des jetons de publication npm, des configurations Kubernetes, un accès direct au code source. Mais ce qui a changé au cours des 6 à 12 derniers mois, c’est que les attaquants ont découvert à quel point il est facile de les compromettre via les outils que les développeurs font déjà confiance. Nous avons suivi cela tout au long de l’année. Trivy, TanStack, Bitwarden CLI, l’extension Nx Console VS Code et maintenant GitHub, toutes compromises via les outils de développement, toutes ciblant l’appareil.

Le problème est que la plupart des équipes de sécurité n’ont aucune visibilité sur ce qui s’exécute réellement sur ces machines. L’EDR surveille au niveau de l’application, mais ne voit pas les packages, les extensions ou les outils d’IA qui s’exécutent à l’intérieur de ces applications. Pendant ce temps, les développeurs tirent de nouveaux packages, extensions et outils d’IA chaque jour avec très peu de contrôles. Les LLM ont également facilité la création de logiciels malveillants convaincants, ce qui a abaissé la barre pour les attaquants dans l’ensemble. L’écart entre ce qui se trouve sur les machines des développeurs et ce que les équipes de sécurité peuvent réellement voir est là où toutes ces attaques atterrissent.

Nous assistons à une vague d’attaques de la chaîne d’approvisionnement au moment où l’IA est de plus en plus adoptée. Comment l’IA modifie-t-elle l’équilibre entre les attaquants et les défenseurs ?

L’IA a considérablement facilité la création de logiciels malveillants de la chaîne d’approvisionnement. La création de charges utiles convaincantes, l’obfuscation de code et la compréhension de la façon dont les registres de packages fonctionnent suffisamment pour les exploiter, tout cela nécessitait autrefois de réelles compétences techniques. Maintenant, cela ne nécessite qu’un abonnement à un LLM. Nous avons vu cela directement avec TeamPCP, qui est derrière la plupart des importantes attaques de la chaîne d’approvisionnement cette année, y compris la récente violation de GitHub. Ils ne sont pas un groupe particulièrement sophistiqué, mais ils ont été prolifiques, et l’IA est une grande partie de la façon dont ils ont évolué. Il y a un an, nous traitions de compromis de packages uniques. Maintenant, nous voyons des vers auto-replicants comme Shai-Hulud et des campagnes enchaînées qui se déplacent à travers les registres, volant des informations d’identification d’une compromission à l’autre.

Du côté défensif, l’IA aide également, mais de différentes manières. Les équipes de sécurité peuvent maintenant effectuer des tests de pénétration continus sur l’ensemble des bases de code à l’aide d’agents d’IA qui testent des centaines de chemins d’attaque en parallèle. Cela libère du temps pour les appels de jugement qui nécessitent toujours un humain. Au niveau de l’appareil, l’IA aide également à détecter des packages malveillants plus tôt en analysant ce qui est installé avant qu’il n’atteigne la machine du développeur. Mais la réalité honnête est que les attaquants bénéficient actuellement plus de l’IA que les défenseurs. La barre pour créer des logiciels malveillants a baissé plus vite que la barre pour les détecter.

Aikido parle de déplacer la sécurité en amont. Qu’est-ce que cela signifie en termes pratiques pour les équipes qui construisent et livrent des logiciels aujourd’hui ?

La plupart de l’industrie a passé des années à déplacer la sécurité vers la gauche dans le pipeline CI/CD. Le problème est que la surface d’attaque a déplacé encore plus loin que cela, sur la machine du développeur lui-même. La violation de GitHub est un bon exemple. Ce n’était pas du code insécurisé qui atteignait la production. C’était une extension VS Code compromise sur l’ordinateur portable d’un développeur qui exfiltrait des informations d’identification avant même que quelqu’un n’écrive une ligne de code.

En termes pratiques, déplacer en amont signifie que la sécurité doit fonctionner en continu là où le code est réellement écrit et où les outils sont installés. Cela signifie valider ce qui s’exécute sur les appareils des développeurs, détecter les packages et les extensions malveillants avant qu’ils n’atterrissent, et tester automatiquement les risques exploitables à mesure que le code change, plutôt que d’attendre qu’un humain planifie cela. L’objectif est une boucle fermée où la détection, la validation et la remédiation se produisent dans le cadre du flux de travail de développement, plutôt que comme un processus distinct qui s’exécute après coup.

Étant donné que les agents d’IA téléchargent automatiquement les dépendances et les outils, comment les entreprises devraient-elles repenser la confiance dans le code open source et le code tiers ?

La valeur par défaut avec les agents d’IA est qu’ils téléchargent les dépendances et les outils automatiquement avec très peu de surveillance humaine. Cela change fondamentalement le modèle de confiance, car vous avez du code qui s’exécute sur les machines des développeurs que personne n’a explicitement choisi d’installer.

La violation de Vercel est un bon exemple de où cela va mal. Vercel n’a pas été piraté directement. Une extension d’IA légitime avait un accès OAuth au compte Google (GOOGL ) d’un employé, et cette extension a été compromise en amont via un vol d’informations sur le côté du fournisseur. C’est le même modèle que nous voyons constamment dans le code open source, où le code tiers de confiance devient le point d’entrée. Le risque se cumule car une station de travail de développeur compromise donne à un attaquant le même niveau d’accès qu’un ingénieur de confiance. Ils peuvent modifier le code, insérer des dépendances malveillantes ou publier des versions altérées de logiciels légitimes, et ces modifications sont récupérées par les pipelines de construction et se propagent via des mises à jour de confiance en aval.

Les entreprises doivent commencer à traiter tout ce qui s’exécute sur la machine d’un développeur comme faisant partie de leur surface d’attaque. Cela inclut les agents d’IA, les outils qu’ils installent, les extensions dont ils dépendent, tout. Si vous n’avez qu’une visibilité sur les packages open source connus, vous manquez les couches où ces attaques se produisent réellement.

Le concept de logiciel auto-sécurisant est convaincant. Quelles sont les capacités de base requises pour que cette vision fonctionne à grande échelle ?

Pour que le logiciel auto-sécurisant fonctionne à grande échelle, vous avez besoin d’une boucle fermée. Le système doit être capable de tester des chemins d’attaque réels chaque fois que le code change, de confirmer si quelque chose est réellement exploitable ou de le rejeter s’il ne l’est pas, et de générer et d’appliquer des correctifs dans le flux de travail de développement, puis de tester à nouveau pour confirmer que la correction a fonctionné. Tout ce cycle doit s’exécuter en continu sans attendre qu’un humain le planifie. L’élément important est que cela ne consiste pas à supprimer les humains de la sécurité. Il s’agit de gérer le travail constant pour que les équipes de sécurité puissent se concentrer sur les décisions qui nécessitent réellement un jugement.

Les développeurs ont souvent du mal avec trop d’alertes et de faux positifs provenant des outils de sécurité. Comment Aikido aide-t-il les équipes à se concentrer sur ce qui compte vraiment ?

Les deux tiers des dirigeants de la sécurité dans notre enquête sur l’état de l’IA dans la sécurité et le développement ont déclaré que leurs équipes ont contourné les processus de sécurité, rejeté les résultats ou retardé les correctifs en raison de faux positifs. C’est le coût réel de l’outillage bruyant. Ce n’est pas seulement une perte de temps, cela dégrade activement la sécurité, car les gens cessent de faire confiance aux alertes.

La façon dont nous abordons cela chez Aikido est à travers l’analyse de portée et l’auto-tri. Plutôt que de signaler chaque vulnérabilité et de laisser l’équipe de sécurité déterminer ce qui est important, nous analysons si une vulnérabilité est réellement accessible dans votre code et peut être exploitée dans votre environnement. Si ce n’est pas le cas, votre équipe ne le voit pas. Cela réduit considérablement le volume d’alertes et signifie que lorsque quelque chose passe, cela vaut la peine d’agir.

Votre plate-forme combine la sécurité du code, la sécurité du cloud, la sécurité du runtime et les tests de pénétration automatisés. Pourquoi une approche unifiée est-elle plus efficace que l’utilisation de plusieurs outils autonomes ?

Notre recherche sur l’état de l’IA dans la sécurité et le développement a révélé quelque chose de contre-intuitif : les équipes de sécurité qui ont subi des incidents exécutaient en réalité plus d’outils de fournisseurs que celles qui n’en ont pas subi. Plus d’outils ne signifiait pas une meilleure sécurité. Cela signifiait plus de bruit, plus de résultats en double et plus de temps passé à corréler les alertes entre les tableaux de bord au lieu de vraiment résoudre les problèmes.

C’est pourquoi nous avons construit Aikido comme une plate-forme unique couvrant le code, le cloud, le runtime, les dépendances et les pipelines. Lorsque tous ces signaux sont en un seul endroit, vous pouvez supprimer les résultats en double, comprendre si une vulnérabilité dans votre code est réellement accessible dans votre environnement cloud et prioriser en fonction du risque réel plutôt que de traiter chaque sortie d’un analyseur comme étant également urgente. Les équipes passent moins de temps à trier les outils et plus de temps à remédier à ce qui compte vraiment. Et chacune de ces capacités doit tenir debout par elle-même. Une plate-forme unifiée qui est médiocre dans tout n’est que la consolidation du problème. Chaque partie de la plate-forme doit être aussi bonne ou meilleure que l’alternative autonome, sinon l’argument de consolidation s’effondre.

Aikido a grandi rapidement et a atteint une traction significative en peu de temps. Quels ont été les plus grands défis pour construire et développer une entreprise de cybersécurité à ce rythme ?

L’évidence est d’être une entreprise de cybersécurité en Belgique. L’industrie a traditionnellement été construite à partir de Tel Aviv et de la Silicon Valley, et il y avait un scepticisme initial quant à savoir si une plate-forme de sécurité de classe mondiale pouvait provenir d’ailleurs. Mais cette distance s’est avérée être un avantage. Nous n’avons pas recyclé les mêmes cahiers de jeux. Nous avons commencé avec une approche axée sur le développeur et un produit groupé qui a facilité l’autorisation des équipes, c’est ainsi que nous sommes devenus discrètement la plate-forme de sécurité des développeurs dominante pour les PME.

Le plus grand défi est simplement le rythme. Nous avons atteint le statut de licorne en janvier 2026 avec notre série B, le chiffre d’affaires a augmenté de cinq fois l’an dernier, et nous sommes maintenant une confiance de plus de 100 000 équipes, y compris la Premier League, Revolut et SoundCloud. Cette année seule, nous avons lancé la protection des appareils pour la sécurité de la chaîne d’approvisionnement, Infinite pour les tests de pénétration d’IA et un partenariat avec Lovable pour la sécurité intégrée dans les flux de travail de codage vibe. Maintenir une qualité élevée sur l’ensemble de la plate-forme tout en bougeant si vite est le défi constant. Mais c’est un bon problème à avoir.

À mesure que le développement natif de l’IA devient la norme, à quoi ressemble l’avenir de la sécurité des logiciels au cours des prochaines années ?

La réponse honnête est que les flux de travail de sécurité traditionnels luttent déjà pour suivre. Les examens périodiques, les tests de pénétration planifiés, l’analyse après coup, tout cela suppose un rythme de développement qui n’existe plus vraiment. Le code généré par l’IA et les agents autonomes introduisent des changements plus rapidement que ces processus ne peuvent les valider.

Nous pensons que la sécurité doit devenir une boucle de rétroaction continue intégrée directement dans la façon dont les logiciels sont développés. Nous appelons cela le logiciel auto-sécurisant. Chaque changement de code est testé pour des chemins d’attaque réels, les résultats sont validés pour une exploitabilité réelle, les correctifs sont générés et rétestés, le tout sans attendre qu’un humain le planifie. Les premières versions de cela existent déjà aujourd’hui, et nous nous dirigeons vers cela à travers le code, le cloud, le runtime et la chaîne d’approvisionnement.

L’étape suivante au-delà de cela est le logiciel auto-entretenu, où la sécurité ne consiste pas seulement à détecter et à corriger les problèmes, mais également à maintenir activement la santé de la base de code au fil du temps. C’est plus loin, mais les fondations sont posées maintenant. La seule chose qui est certaine est que la barrière pour exécuter des attaques sophistiquées a déjà disparu grâce à l’IA, donc le côté défensif doit bouger à la même vitesse.

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