Willem Delbare, mede-oprichter en CEO van Aikido – Interviewreeks

Willem Delbare, medeoprichter en CEO van Aikido, is een serieondernemer in SaaS en technisch oprichter met ruime ervaring in softwarebedrijven voor ontwikkelaars. Voordat hij Aikido in 2022 startte, richtte hij samen met anderen HR-platform Officient, duurzaamheidsinitiatief FutureproofedCities en CRM-bedrijf Teamleader op. Bij Teamleader was hij CTO en hielp hij het bedrijf uitgroeien tot een van de opmerkelijke Belgische SaaS-succesverhalen. Hij richtte zich tijdens zijn loopbaan op het vereenvoudigen van complexe technische uitdagingen rond cloudinfrastructuur, SaaS-schaalbaarheid en cybersecurity. Onder zijn leiding groeide Aikido snel uit tot een van de snelst opkomende cybersecuritystartups van Europa, met praktische beveiligingsoplossingen voor moderne ontwikkelteams.

Aikido is een in België gevestigd cybersecuritybedrijf dat ontwikkelaars en engineeringteams helpt toepassingen en cloudomgevingen met één geïntegreerd platform te beveiligen. Het bundelt codescans, afhankelijkheidsanalyse, beheer van de cloudbeveiligingsstatus, runtimebescherming en AI-ondersteunde tests in één overzichtelijk systeem. De aanpak moet complexiteit en foutpositieve meldingen verminderen en organisaties het beheer van versnipperde beveiligingsoplossingen van verschillende leveranciers besparen. Vanuit de behoeften van ontwikkelaars zet Aikido in op automatisering, continue bewaking en eenvoudige herstelprocessen, zodat beveiliging direct deel wordt van de softwareontwikkelingscyclus.

Welke ervaringen met het opbouwen en laten groeien van bedrijven als Teamleader en Officient brachten u ertoe in 2022 Aikido Security op te richten? Hoe vormde uw technische achtergrond als oprichter de visie op een ontwikkelaarsvriendelijkere aanpak van cybersecurity?

In de afgelopen tien jaar heb ik mijn roeping gevonden in B2B SaaS. Ik was technisch medeoprichter en CTO van drie startups, met drie exits in HR-technologie, facturatietechnologie en CO₂-boekhouding. Heel verschillende werelden, maar steeds dezelfde gedrevenheid: software bouwen waarbij mensen hun laptop niet uit het raam willen gooien.

Bij elk van die bedrijven hield beveiliging me echter ’s nachts wakker. De angst voor een datalek was reëel en de hulpmiddelen die moesten helpen leken op de cockpit van een F-16: duur, overweldigend en gemaakt voor iemand met een doctoraat in informatica, niet voor een ontwikkelteam dat snel software wil uitbrengen.

We richtten Aikido Security op om precies dat probleem op te lossen. Aikido biedt organisaties van elke omvang een geïntegreerd softwarebeveiligingsplatform dat ontwikkelaars centraal stelt. Het brengt de essentiële beveiliging voor code, cloud en runtime samen, zodat ontwikkelaars gemakkelijker veilig software kunnen uitbrengen.

Sindsdien heeft AI het leveren van software verder versneld en het aanvalsoppervlak vergroot. Onze volgende stap is organisaties te helpen dat tempo bij te houden met software die zichzelf beveiligt.

In februari lanceerden we Aikido Infinite, onze oplossing voor continue AI-penetratietests. Die controleert of kwetsbaarheden daadwerkelijk te misbruiken zijn en rondt de herstelcyclus af voordat de code in productie komt.

Ontwikkelaarsomgevingen worden nu een van de grootste blinde vlekken in de beveiliging genoemd. Wat is er onlangs veranderd waardoor dit zo’n kritiek probleem is geworden?

Ontwikkelaarscomputers waren altijd al waardevolle doelwitten. Ze bevatten cloudinloggegevens, SSH-sleutels, npm-publicatietokens, Kubernetes-configuraties en directe toegang tot broncode. In de afgelopen 6 tot 12 maanden hebben aanvallers echter ontdekt hoe eenvoudig ze deze computers kunnen binnendringen via hulpmiddelen die ontwikkelaars al vertrouwen. We volgen dit het hele jaar: Trivy, TanStack, Bitwarden CLI, de VS Code-extensie Nx Console en nu GitHub. Bij al deze inbraken liep de route via ontwikkelaarstools en was het apparaat het doelwit.

De meeste beveiligingsteams zien niet wat er werkelijk op die computers draait. EDR bewaakt applicaties, maar niet de pakketten, extensies en AI-hulpmiddelen daarbinnen. Ontwikkelaars halen ondertussen dagelijks nieuwe pakketten, extensies en AI-tools binnen met nauwelijks controles. LLM’s maken het ook eenvoudiger overtuigende malware te bouwen, waardoor de drempel voor aanvallers in het algemeen daalt. Al deze aanvallen benutten de kloof tussen wat op ontwikkelaarscomputers staat en wat beveiligingsteams daadwerkelijk kunnen zien.

We zien een toename van aanvallen op de toeleveringsketen op hetzelfde moment dat AI breed wordt geadopteerd. Hoe verandert AI de balans tussen aanvallers en verdedigers?

AI heeft het veel eenvoudiger gemaakt malware voor aanvallen op de toeleveringsketen te bouwen. Overtuigende aanvalspayloads maken, code verhullen en pakketregisters goed genoeg begrijpen om ze te misbruiken, vergde vroeger echte technische vaardigheden. Nu volstaat een LLM-abonnement. We zagen dit rechtstreeks bij TeamPCP, dat achter de meeste grote aanvallen van dit jaar zit, waaronder de recente inbraak bij GitHub. De groep is technisch niet bijzonder geavanceerd, maar heeft veel aanvallen uitgevoerd. AI speelt een grote rol in de uitbreiding van haar activiteiten. Een jaar geleden ging het om compromittering van losse pakketten. Nu zien we zelfreplicerende wormen zoals Shai-Hulud en aaneengeschakelde campagnes die van register naar register gaan en gestolen inloggegevens uit de ene inbraak inzetten voor de volgende.

AI helpt ook de verdediging, maar op andere manieren. Beveiligingsteams kunnen AI-agents continu penetratietests op hele codebases laten uitvoeren. Die onderzoeken honderden aanvalspaden parallel. Zo komt tijd vrij voor beslissingen die nog menselijk oordeel vereisen. Op apparaatniveau helpt AI ook eerder kwaadaardige pakketten te ontdekken door te analyseren wat wordt geïnstalleerd voordat het de ontwikkelaarscomputer bereikt. Eerlijk gezegd profiteren aanvallers momenteel meer van AI dan verdedigers. De drempel om malware te maken is sneller gedaald dan de drempel om die te ontdekken.

Aikido spreekt over beveiliging eerder in het ontwikkelproces inzetten. Wat betekent dat praktisch voor teams die nu software bouwen en uitbrengen?

Een groot deel van de sector heeft jarenlang beveiliging naar links verschoven, naar eerdere stappen in de CI/CD-pijplijn. Het aanvalsoppervlak is echter nog verder naar voren geschoven: naar de ontwikkelaarscomputer zelf. De inbraak bij GitHub is een goed voorbeeld. Het ging niet om onveilige code die in productie kwam, maar om een gehackte VS Code-extensie op de laptop van één ontwikkelaar die inloggegevens wegsluisde voordat iemand een regel code schreef.

Praktisch moet beveiliging continu werken waar code wordt geschreven en hulpmiddelen worden geïnstalleerd. Je moet controleren wat op ontwikkelaarsapparaten draait, kwaadaardige pakketten en extensies onderscheppen voordat ze aankomen en bij codewijzigingen automatisch op misbruikbare risico’s testen, zonder een geplande beoordeling af te wachten. Het doel is een gesloten cyclus waarin detectie, validatie en herstel deel zijn van het ontwikkelwerk, niet van een los proces achteraf.

Hoe moeten bedrijven hun vertrouwen in opensourcecode en code van derden heroverwegen als AI-agents automatisch afhankelijkheden en hulpmiddelen downloaden?

AI-agents downloaden standaard automatisch afhankelijkheden en hulpmiddelen, met heel weinig menselijk toezicht. Dat verandert het vertrouwensmodel fundamenteel: op ontwikkelaarscomputers draait code die niemand uitdrukkelijk heeft gekozen te installeren.

De inbraak bij Vercel laat goed zien hoe dit mis kan gaan. Vercel werd niet rechtstreeks gehackt. Een legitieme AI-extensie had via OAuth toegang tot het Google-account van een medewerker. Die extensie was eerder in de keten gecompromitteerd door een infostealer bij de leverancier. Het is hetzelfde terugkerende patroon bij open source: vertrouwde code van derden wordt de ingang. Het risico stapelt zich op, omdat een gehackt ontwikkelwerkstation de aanvaller dezelfde toegang geeft als een vertrouwde engineer. Hij kan code veranderen, kwaadaardige afhankelijkheden toevoegen of gemanipuleerde versies van legitieme software publiceren. Buildpijplijnen nemen die wijzigingen over, waarna ze via vertrouwde updates verder in de keten verspreid worden.

Bedrijven moeten alles op de computer van een ontwikkelaar tot hun aanvalsoppervlak rekenen: AI-agents, de hulpmiddelen die ze installeren, de extensies waarvan ze afhankelijk zijn, alles. Wie alleen bekende opensourcepakketten kan zien, mist de lagen waar deze aanvallen werkelijk plaatsvinden.

Het concept van zelfbeveiligende software is overtuigend. Wat zijn de kernfunctionaliteiten die nodig zijn om die visie op schaal te laten werken?

Daarvoor is een gesloten cyclus nodig. Bij elke codewijziging moet het systeem echte aanvalspaden testen, daadwerkelijke misbruikbaarheid bevestigen of een bevinding afwijzen als die niet misbruikbaar is. Het moet binnen het ontwikkelwerk reparaties genereren en toepassen, en opnieuw testen of die werken. Die hele cyclus moet voortdurend draaien zonder te wachten tot iemand hem inplant. Het gaat niet om mensen uit beveiliging te verwijderen, maar om het voortdurende werk af te handelen, zodat teams zich kunnen richten op beslissingen die echt menselijk oordeel vragen.

Ontwikkelaars hebben vaak te maken met te veel waarschuwingen en valse positieven van beveiligingstools. Hoe helpt Aikido teams zich te concentreren op wat er echt toe doet?

Twee derde van de beveiligingsverantwoordelijken in onze State of AI in Security & Development-enquête zei dat hun teams vanwege foutpositieve meldingen beveiligingsprocessen omzeilden, bevindingen negeerden of reparaties uitstelden. Dat is de werkelijke prijs van hulpmiddelen met te veel ruis. Ze verspillen niet alleen tijd, maar verzwakken actief de beveiliging doordat mensen de waarschuwingen niet meer vertrouwen.

Bij Aikido gebruiken we bereikbaarheidsanalyse en automatische triage. In plaats van elke kwetsbaarheid te melden en het team te laten bepalen wat belangrijk is, analyseren we of die echt bereikbaar is in uw code en misbruikt kan worden in uw omgeving. Zo niet, dan krijgt uw team haar nooit te zien. Dat verlaagt het aantal waarschuwingen drastisch en maakt de meldingen die wel doorkomen de moeite van ingrijpen waard.

Uw platform combineert code-, cloud-, runtimebeveiliging en geautomatiseerde pentesting. Waarom is een geïntegreerde aanpak effectiever dan het gebruik van meerdere losse tools?

Ons onderzoek State of AI in Security & Development leverde een onverwachte uitkomst op: teams die incidenten hadden meegemaakt gebruikten meer leveranciershulpmiddelen dan teams zonder incidenten. Meer tools betekenden geen betere beveiliging, maar meer ruis, dubbele bevindingen en tijd om waarschuwingen tussen dashboards te vergelijken in plaats van problemen op te lossen.

Daarom bouwden we Aikido als één platform voor code, cloud, runtime, afhankelijkheden en pijplijnen. Als alle signalen samenkomen, kunt u dubbele bevindingen verwijderen, nagaan of een codekwetsbaarheid echt bereikbaar is in de cloudomgeving en prioriteren op werkelijk risico, in plaats van elke scanneruitkomst even urgent te vinden. Teams besteden minder tijd aan triage tussen tools en meer aan belangrijke reparaties. Elke functie moet ook afzonderlijk goed zijn. Een platform dat overal middelmatig in is, brengt alleen het probleem bijeen. Elk onderdeel moet minstens zo goed zijn als het losse alternatief, anders houdt het argument voor consolidatie geen stand.

Aikido groeide snel en kreeg in korte tijd stevig voet aan de grond. Wat waren de grootste uitdagingen bij het opbouwen en laten groeien van een cybersecuritybedrijf in dit tempo?

Het meest voor de hand liggende is dat we een Belgisch cybersecuritybedrijf zijn. De sector groeide traditioneel vanuit Tel Aviv en Silicon Valley, en aanvankelijk was er twijfel of een beveiligingsplatform van wereldklasse ook elders kon ontstaan. Maar de afstand werd een voordeel. We herhaalden niet dezelfde aanpak. We begonnen vanuit de behoeften van ontwikkelaars met een gebundeld product dat teams zelfstandig konden invoeren. Zo werden we in alle stilte het dominante ontwikkelaarsbeveiligingsplatform voor het mkb.

De grotere uitdaging is het tempo. We bereikten de unicornstatus in januari 2026 met onze Series B, de omzet vervijfvoudigde vorig jaar en inmiddels vertrouwen meer dan 100.000 teams ons, waaronder de Premier League, Revolut en SoundCloud. Alleen al dit jaar lanceerden we Device Protection voor ketenbeveiliging, Infinite voor AI-penetratietests en een samenwerking met Lovable om beveiliging in vibe-codingprocessen in te bouwen. Zo snel vooruitgaan en de kwaliteit van elk onderdeel hoog houden, blijft de voortdurende uitdaging. Maar het is een prettig probleem.

Naarmate AI-native-ontwikkeling de standaard wordt, hoe ziet de toekomst van softwarebeveiliging eruit over de komende jaren?

Het eerlijke antwoord is dat traditionele beveiligingsprocessen nu al moeite hebben het tempo bij te houden. Periodieke beoordelingen, geplande pentests en scans achteraf veronderstellen een ontwikkeltempo dat eigenlijk niet meer bestaat. AI-gegenereerde code en autonome agents voeren veranderingen sneller in dan die processen ze kunnen controleren.

We denken dat beveiliging een continue terugkoppeling moet worden die direct in softwareontwikkeling is ingebouwd. Dat noemen we zelfbeveiligende software. Elke codewijziging wordt op echte aanvalspaden getest, bevindingen worden op daadwerkelijke misbruikbaarheid gecontroleerd en reparaties worden gegenereerd en opnieuw getest, zonder te wachten tot een mens het inplant. Er bestaan al vroege vormen, en we werken hieraan voor code, cloud, runtime en de toeleveringsketen.

De volgende stap is zelfonderhoudende software. Beveiliging zou dan niet alleen problemen vinden en oplossen, maar de codebase ook actief gezond houden in de loop van de tijd. Dat ligt verder weg, maar de fundamenten worden nu gelegd. Zeker is dat AI de drempel voor geavanceerde aanvallen al heeft laten instorten. De verdediging moet dus even snel vooruit.

Bedankt voor het waardevolle interview. Lezers die meer willen weten, kunnen Aikido bezoeken.