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

Willem Delbare, mede-oprichter en CEO van Aikido, is een serie-ondernemer in SaaS en een technisch oprichter met een sterke achtergrond in het opbouwen van developer-georiënteerde softwarebedrijven. Voordat hij Aikido in 2022 lanceerde, was hij mede-oprichter van het HR-platform Officient, het duurzaamheidsinitiatief FutureproofedCities en het CRM-bedrijf Teamleader, waar hij als CTO diende en hielp het bedrijf te schalen tot een van de meest succesvolle SaaS-verhalen in België. Gedurende zijn carrière heeft Delbare zich gericht op het vereenvoudigen van complexe technische uitdagingen op het gebied van cloud-infrastructuur, SaaS-schaalbaarheid en cybersecurity. Onder zijn leiderschap is Aikido snel uitgegroeid tot een van de snelst groeiende cybersecurity-startups in Europa door praktische beveiligingsoplossingen te bieden die zijn ontworpen voor moderne ontwikkelteams.
Aikido is een Belgische cybersecurity-onderneming die ontwikkelaars en engineersteams helpt bij het beveiligen van toepassingen en cloud-omgevingen via een enkel, geïntegreerd platform. Het bedrijf combineert meerdere beveiligingsfuncties, zoals code-scanning, afhankelijkheidsanalyse, cloud-beveiligingsposture-management, runtime-bescherming en AI-geassisteerde testing, in één gestroomlijnd systeem. De aanpak is ontworpen om complexiteit te verminderen, valse positieven te minimaliseren en de noodzaak voor organisaties om gefragmenteerde beveiligingsstacks over meerdere leveranciers te beheren, te elimineren. Met een developer-first-filosofie benadrukt Aikido automatisering, continue monitoring en vereenvoudigde herstelwerkstromen om bedrijven te helpen beveiliging rechtstreeks in de software-ontwikkelingscyclus te integreren.
Welke ervaringen uit het opbouwen en schalen van bedrijven als Teamleader en Officient hebben u ertoe gebracht om Aikido Security in 2022 op te richten, en hoe heeft uw achtergrond als technisch oprichter uw visie beïnvloed om een meer developer-vriendelijke aanpak voor cybersecurity te creëren?
In de afgelopen tien jaar heb ik mijn roeping gevonden in B2B SaaS. Met drie startups als technisch mede-oprichter en CTO en drie exits in HR-tech, factuurtech en koolstofboekhouding. Allemaal heel verschillende werelden, maar met dezelfde obsessie om software te bouwen die mensen niet het gevoel gaf dat ze hun laptop uit het raam wilden gooien.
Maar bij elk van die bedrijven hield beveiliging me ‘s nachts wakker. De angst voor een datalek was echt, en de tools die zouden moeten helpen, zagen eruit als de binnenkant van een F-16-cockpit. Duur, overweldigend en ontworpen voor iemand met een PhD in computerwetenschappen, niet voor een ontwikkelteam dat snel wilde schepen.
We hebben Aikido Security opgericht om deze uitdaging rechtstreeks aan te pakken. Aikido biedt een geïntegreerd, developer-first softwarebeveiligingsplatform voor organisaties van alle maten dat de essentiële beveiligingsfuncties over code, cloud en runtime op één plek samenbrengt, waardoor het voor ontwikkelaars gemakkelijker wordt om veilig en beveiligd te schepen.
Sindsdien heeft AI de softwarelevering nog sneller gemaakt en het aanvalsoppervlak groter. Ons volgende hoofdstuk is om organisaties in staat te stellen om bij te blijven met zelfbeveiligende software.
In februari hebben we Aikido Infinite gelanceerd, onze continue AI-penetratietestoplossing die valideert of een kwetsbaarheid kan worden uitgebuit en de herstellus sluit voordat de code in productie gaat.
Ontwikkelaarsomgevingen worden nu beschreven als een van de grootste beveiligingsblindspots. Wat is er onlangs veranderd om dit zo’n kritiek probleem te maken?
Ontwikkelaarsmachines zijn altijd waardevolle doelen geweest. Ze bevatten cloud-referenties, SSH-sleutels, npm-publicatietokens, Kubernetes-configuraties, directe toegang tot broncode. Maar wat er in de afgelopen 6 tot 12 maanden is veranderd, is dat aanvallers hebben ontdekt hoe gemakkelijk ze te compromitteren zijn via de tooling die ontwikkelaars al vertrouwen. We hebben dit gevolgd over het hele jaar. Trivy, TanStack, Bitwarden CLI, de Nx Console VS Code-extensie en nu GitHub, allemaal gehackt via ontwikkelaarstooling, allemaal gericht op het apparaat.
Het probleem is dat de meeste beveiligingsteams geen zicht hebben op wat er daadwerkelijk op die machines draait. EDR bewaakt op applicatieniveau, maar ziet niet de pakketten, extensies of AI-hulpmiddelen die binnen die applicaties draaien. Ondertussen halen ontwikkelaars elke dag nieuwe pakketten, extensies en AI-hulpmiddelen op met heel weinig menselijke toezicht. LLM’s hebben het ook gemakkelijker gemaakt om overtuigende malware te creëren, waardoor de drempel voor aanvallers overal is verlaagd. Die kloof tussen wat er op ontwikkelaarsmachines draait en wat beveiligingsteams daadwerkelijk kunnen zien, is waar al deze aanvallen plaatsvinden.
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 aanzienlijk gemakkelijker gemaakt om malware voor de toeleveringsketen te creëren. Het bouwen van overtuigende payloads, het verhullen van code en het begrijpen van hoe pakketregistries werken, vereiste vroeger echte technische vaardigheden. Nu vereist het alleen een LLM-abonnement. We hebben dit rechtstreeks gezien met TeamPCP, die achter de meeste grote aanvallen op de toeleveringsketen van dit jaar zitten, waaronder de recente GitHub-breach. Ze zijn geen bijzonder geavanceerde groep, maar ze hebben zich dankzij AI geschaald. Een jaar geleden hadden we te maken met enkele pakketcompromissen. Nu zien we zelfreplicerende wormen als Shai-Hulud en gekoppelde campagnes die zich over registries verplaatsen, referenties stelen van de ene compromittering om de volgende te voeden.
Aan de verdedigingskant helpt AI ook, maar op andere manieren. Beveiligingsteams kunnen nu continue penetratietests uitvoeren over hele codebases met AI-agents die honderden aanvalsPaden parallel testen. Dat vrijwaart tijd voor de oordelen die nog steeds een mens nodig hebben. Op apparaatniveau helpt AI ook om kwaadaardige pakketten eerder te detecteren door te analyseren wat wordt geïnstalleerd voordat het de ontwikkelaarsmachine bereikt. Maar de eerlijke realiteit is dat aanvallers momenteel meer profiteren van AI dan verdedigers. De drempel voor het creëren van malware is sneller gedaald dan de drempel voor het detecteren ervan.
Aikido spreekt over het verplaatsen van beveiliging stroomopwaarts. Wat betekent dat in praktische zin voor teams die software bouwen en uitgeven?
De meeste industrie heeft jarenlang beveiliging naar links verplaatst in de CI/CD-pijplijn. Het probleem is dat het aanvalsoppervlak nog verder naar links is verplaatst, naar de ontwikkelaarsmachine zelf. De GitHub-breach is een goed voorbeeld. Dat was geen onveilig code dat in productie kwam. Dat was een gecompromitteerde VS Code-extensie op de laptop van een ontwikkelaar die referenties uitbracht voordat iemand een regel code schreef.
In praktische zin betekent het verplaatsen van beveiliging stroomopwaarts dat beveiliging continu moet werken waar de code daadwerkelijk wordt geschreven en waar tooling wordt geïnstalleerd. Dat betekent het valideren van wat er op ontwikkelaarsapparaten draait, het detecteren van kwaadaardige pakketten en extensies voordat ze landen, en het automatisch testen op uitbuitbare risico’s bij elke codewijziging, in plaats van te wachten op een geplande review. Het doel is een gesloten lus waarin detectie, validatie en herstel plaatsvinden als onderdeel van de ontwikkelingsworkflow, in plaats van als een apart proces dat na afloop plaatsvindt.
Met AI-agents die automatisch afhankelijkheden en tools downloaden, hoe moeten bedrijven hun vertrouwen in open source- en derdensoftware heroverwegen?
De standaard voor AI-agents is dat ze afhankelijkheden en tools automatisch downloaden met heel weinig menselijke toezicht. Dat verandert het vertrouwensmodel fundamenteel, omdat u code op ontwikkelaarsmachines hebt draaien die niemand expliciet heeft gekozen om te installeren. (GOOGL )
De Vercel-breach is een goed voorbeeld van waar dit misgaat. Vercel werd niet rechtstreeks gehackt. Een legitieme AI-extensie had OAuth-toegang tot het Google-account van een medewerker, en die extensie was upstream gecompromitteerd via een infostealer op de leverancierszijde. Dit is hetzelfde patroon dat we blijven zien in open source, waar vertrouwde derdensoftware het ingangspunt wordt. Het risico wordt verergerd omdat een gecompromitteerde ontwikkelaarswerkstation een aanvaller hetzelfde niveau van toegang geeft als een vertrouwd ingenieur. Ze kunnen code wijzigen, kwaadaardige afhankelijkheden invoegen of getamperde versies van legitieme software publiceren, en die wijzigingen worden opgepikt door build-pipelines en verspreid via vertrouwde updates downstream.
Bedrijven moeten beginnen met het behandelen van alles wat op een ontwikkelaarsmachine draait als onderdeel van hun aanvalsoppervlak. Dat omvat AI-agents, de tools die ze installeren, de extensies waarvan ze afhankelijk zijn, alles. Als u alleen zicht heeft op bekende open source-pakketten, mist u de lagen waarop deze aanvallen daadwerkelijk plaatsvinden.
Het concept van zelfbeveiligende software is overtuigend. Wat zijn de kernfunctionaliteiten die nodig zijn om die visie op schaal te laten werken?
Om zelfbeveiligende software op schaal te laten werken, hebt u een gesloten lus nodig. Het systeem moet in staat zijn om echte aanvalsPaden te testen bij elke codewijziging, te bevestigen of iets daadwerkelijk uitbuitbaar is of het afwijzen als het niet is, en fixes te genereren en toe te passen binnen de ontwikkelingsworkflow, en vervolgens opnieuw te testen om te bevestigen dat de fix werkte. Die hele cyclus moet continu draaien zonder te wachten op iemand die het moet plannen. Het belangrijke is dat dit niet gaat over het verwijderen van mensen uit beveiliging. Het gaat over het afhandelen van het constante werk, zodat beveiligingsteams zich kunnen concentreren op de beslissingen die daadwerkelijk oordeel nodig hebben.
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 beveiligingsleiders in onze State of AI in Security & Development-enquête zei dat hun teams beveiligingsprocessen hebben omzeild, bevindingen hebben genegeerd of herstel hebben vertraagd vanwege valse positieven. Dat is de echte kosten van lawaaierige tooling. Het verspilt niet alleen tijd, maar degradeert beveiliging ook actief omdat mensen stoppen met het vertrouwen op de waarschuwingen.
De manier waarop we dit bij Aikido aanpakken, is via bereikbaarheidsanalyse en autotriage. In plaats van elke kwetsbaarheid te markeren en het aan het beveiligingsteam over te laten om te bepalen wat belangrijk is, analyseren we of een kwetsbaarheid daadwerkelijk bereikbaar is in uw code en kan worden uitgebuit in uw omgeving. Als dat niet het geval is, ziet uw team het niet. Dat vermindert drastisch het volume van waarschuwingen en betekent dat wanneer er iets doorheen komt, het de moeite waard is om actie te ondernemen.
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 naar de staat van AI in beveiliging en ontwikkeling toonde iets tegenstrijdigs aan: beveiligingsteams die incidenten meemaakten, gebruikten daadwerkelijk meer vendor-tools dan diegenen die dat niet deden. Meer tools betekenden niet betere beveiliging. Het betekende meer lawaai, meer dubbele bevindingen en meer tijd besteed aan het correleren van waarschuwingen over dashboards, in plaats van daadwerkelijk dingen te fixen.
Daarom hebben we Aikido gebouwd als een enkel platform over code, cloud, runtime, afhankelijkheden en pipelines. Wanneer al die signalen op één plek zitten, kunt u dubbele bevindingen elimineren, begrijpen of een kwetsbaarheid in uw code daadwerkelijk bereikbaar is in uw cloud-omgeving, en prioriteren op basis van echt risico, in plaats van elke scanneruitvoer als even urgent te behandelen. Teams besteden minder tijd aan triage over tools en meer tijd aan het herstellen van wat er echt toe doet. En elk van die mogelijkheden moet op zichzelf staan. Een geïntegreerd platform dat matig is in alles, is alleen maar het probleem aan het consolideren. Elk onderdeel van het platform moet zo goed zijn als of beter zijn dan de losse alternatieven, anders valt het consolidatieargument uit elkaar.
Aikido is snel gegroeid en heeft in korte tijd aanzienlijke traction bereikt. Wat zijn de grootste uitdagingen geweest bij het opbouwen en laten groeien van een cybersecurity-bedrijf in dit tempo?
De voor de hand liggende uitdaging is dat we een cybersecurity-bedrijf uit België zijn. De industrie is traditioneel opgebouwd uit Tel Aviv en Silicon Valley, en er was aanvankelijk scepsis over of een wereldklasse-beveiligingsplatform uit een andere plek kon komen. Maar die afstand bleek een voordeel te zijn. We recycleerden niet dezelfde playbooks. We begonnen met een developer-first-aanpak en een gebundeld product dat het voor teams gemakkelijk maakte om zelf aan boord te komen, en dat is hoe we stil werden de dominante developer-beveiligingsplatform voor SMB’s.
De grotere uitdaging is gewoon het tempo. We hebben unicorn-status bereikt in januari 2026 met onze Series B, de omzet is vijfvoudig gestegen vorig jaar, en we worden nu vertrouwd door meer dan 100.000 teams, waaronder de Premier League, Revolut en SoundCloud. Alleen al dit jaar hebben we Device Protection voor toeleveringsketenbeveiliging gelanceerd, Infinite voor AI-penetratietesten en een partnership met Lovable voor ingebedde beveiliging in vibe-coding-workflows. Zo snel bewegen en tegelijkertijd de kwaliteit hoog houden over elk onderdeel van het platform, is de constante uitdaging. Maar het is een goed probleem om te hebben.
Naarmate AI-native-ontwikkeling de standaard wordt, hoe ziet de toekomst van softwarebeveiliging eruit over de komende jaren?
Het eerlijke antwoord is dat traditionele beveiligingsworkflows al worstelen om bij te blijven. Periodieke reviews, geplande pentests, achteraf scannen, al die dingen gaan ervan uit dat de ontwikkelingssnelheid niet zo snel is als die nu is. AI-gegenereerde code en autonome agents introduceren veranderingen sneller dan die processen kunnen valideren.
We denken dat beveiliging een continue feedbacklus moet worden die rechtstreeks in de manier van softwareontwikkeling is geïntegreerd. We noemen dit zelfbeveiligende software. Elke codewijziging wordt getest op echte aanvalsPaden, bevindingen worden geverifieerd op daadwerkelijke uitbuitbaarheid, fixes worden gegenereerd en opnieuw getest, alles zonder te wachten op een mens die het moet plannen. Vroege versies hiervan bestaan al vandaag, en we werken ernaartoe over code, cloud, runtime en toeleveringsketen.
De volgende stap daarna is zelfonderhoudende software, waarbij beveiliging niet alleen het detecteren en fixen van problemen is, maar ook actief het onderhoud van de gezondheid van de codebase in de loop van de tijd. Dat is verder weg, maar de fundamenten worden nu gelegd. Het enige dat zeker is, is dat de drempel voor het uitvoeren van geavanceerde aanvallen al is ingestort dankzij AI, dus de verdedigingskant moet met hetzelfde tempo bewegen.
Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Aikido bezoeken.












