Willem Delbare, medgrundare och VD för Aikido – Intervjuserie

Willem Delbare, medgrundare och VD för Aikido, är en serieentreprenör inom SaaS och teknisk grundare med en stark bakgrund inom att bygga utvecklarfokuserade programvaruföretag. Innan han lanserade Aikido 2022 var han med och grundade HR-plattformen Officient, hållbarhetsinitiativet FutureproofedCities och CRM-företaget Teamleader, där han var CTO och hjälpte till att skala upp företaget till ett av Belgiens mest framgångsrika SaaS-företag. Under sin karriär har Delbare fokuserat på att förenkla komplexa tekniska utmaningar inom molninfrastruktur, SaaS-skalbarhet och cybersäkerhet. Under hans ledning har Aikido snabbt vuxit till ett av Europas snabbast växande cybersäkerhetsföretag genom att fokusera på praktiska säkerhetslösningar utformade för moderna utvecklingsteam.

Aikido är ett belgiskt cybersäkerhetsföretag som fokuserar på att hjälpa utvecklare och ingenjörsteam att skydda applikationer och molnmiljöer genom en enda enhetlig plattform. Företaget kombinerar flera säkerhetsfunktioner, såsom kodscanning, beroendeanalys, molnsäkerhetsposturhantering, körningsskydd och AI-assisterad testning, till ett strömlinjeformat system. Dess tillvägagångssätt är utformat för att minska komplexitet, minimera falska positiva och eliminera behovet för organisationer att hantera fragmenterade säkerhetsstackar över flera leverantörer. Byggt med en utvecklarförst-filosofi betonar Aikido automatisering, kontinuerlig övervakning och förenklade åtgärdsflöden för att hjälpa företag att integrera säkerhet direkt i programvaruutvecklingslivscykeln.

Vilka erfarenheter från att bygga och skala företag som Teamleader och Officient ledde dig till att grunda Aikido Security 2022, och hur har din bakgrund som teknisk grundare format din vision för att skapa en mer utvecklarvänlig tillvägagångssätt för cybersäkerhet?

Under det senaste decenniet har jag funnit min kallelse i B2B SaaS. Med tre startups som teknisk medgrundare och CTO och tre avslut över HR-teknik, fakturateknik och koldioxidredovisning. Alla mycket olika världar, men med samma besatthet av att bygga programvara som inte får människor att vilja kasta ut sina bärbara datorer genom fönstret.

Men i var och en av dessa företag höll säkerheten mig vaken om natten. Rädslan för en dataintrång var verklig, och verktygen som skulle hjälpa till såg ut som insidan av en F-16-kockpit. Dyra, överväldigande och byggda för någon med en doktorsexamen i datavetenskap, inte för ett utvecklingsteam som försöker leverera snabbt.

Vi grundade Aikido Security för att direkt lösa denna utmaning. Aikido tillhandahåller en enhetlig, utvecklarförst programvarusäkerhetsplattform för organisationer av alla storlekar som samlar de väsentliga säkerhetsfunktionerna över kod, moln och körning på en plats för att göra det lättare för utvecklare att leverera säkert och tryggt.

Sedan dess har AI gjort programvaruleverans ännu snabbare och angreppsytan större. Vår nästa kapitel är att möjliggöra för organisationer att hålla jämna steg med självskyddande programvara.

I februari lanserade vi Aikido Infinite, vår kontinuerliga AI-penetreringstestlösning som validerar exploaterbarhet och stänger åtgärdsloopen innan koden når produktionen.

Utvecklingsmiljöer beskrivs nu som en av de största säkerhetsblinda fläckarna. Vad har förändrats nyligen för att göra detta till en så kritisk fråga?

Utvecklarmaskiner har alltid varit värdefulla mål. De innehåller molntillstånd, SSH-nycklar, npm-publicerings-token, Kubernetes-konfigurationer, direktåtkomst till källkod. Men vad som har förändrats under de senaste 6 till 12 månaderna är att angripare har förstått hur lätt de är att kompromettera genom verktygen som utvecklare redan litar på. Vi har spårat detta under hela året. Trivy, TanStack, Bitwarden CLI, Nx Console VS Code-tillägget och nu GitHub, alla inträngda genom utvecklarverktyg, alla riktade mot enheten.

Problemet är att de flesta säkerhetsteam har ingen insyn i vad som faktiskt körs på dessa maskiner. EDR övervakar på applikationsnivå, men den ser inte paket, tillägg eller AI-verktyg som körs inuti dessa applikationer. Samtidigt hämtar utvecklare in nya paket, tillägg och AI-verktyg varje dag med mycket lite mänsklig tillsyn. LLM har också gjort det lättare att skapa övertygande malware, vilket har sänkt ribban för angripare över hela linjen. Klyftan mellan vad som finns på utvecklarmaskiner och vad säkerhetsteam kan se är där alla dessa attacker landar.

Vi ser en ökning av leverantörskedjeattacker samtidigt som AI blir allmänt antagen. Hur förändrar AI balansen mellan angripare och försvarare?

AI har gjort det betydligt enklare att skapa leverantörskedjemalware. Att bygga övertygande payload, dölja kod och förstå hur paketregister fungerar tillräckligt bra för att missbruka dem alla krävde tidigare verklig teknisk skicklighet. Nu kräver det bara en LLM-prenumeration. Vi har sett detta direkt med TeamPCP, som har legat bakom de flesta stora leverantörskedjeattacker i år, inklusive den senaste GitHub-attackeren. De är inte en särskilt sofistikerad grupp, men de har varit flitiga, och AI är en stor del av hur de har skalat. För ett år sedan hanterade vi enstaka paketkringgåenden. Nu ser vi självreplikerande maskar som Shai-Hulud och kedjekampanjer som flyttar över register, stjäl autentiseringsuppgifter från ett intrång för att bränsle nästa.

På den defensiva sidan hjälper AI också, men på olika sätt. Säkerhetsteam kan nu köra kontinuerlig penetrationstestning över hela kodbasen med AI-agenter som testar hundratals angreppsvägar parallellt. Det frigör tid för de bedömningar som fortfarande behöver en människa. På enhetsnivå hjälper AI också till att fånga skadliga paket tidigare genom att analysera vad som installeras innan det når utvecklarens maskin. Men den ärliga verkligheten är att angriparna för närvarande drar nytta av AI mer än försvararna gör. Ribban för att skapa malware har sjunkit snabbare än ribban för att upptäcka det.

Aikido talar om att flytta säkerheten uppströms. Vad betyder det i praktiska termer för team som bygger och levererar programvara idag?

De flesta i branschen har tillbringat år med att flytta säkerheten vänsterut i CI/CD-pipelinen. Problemet är att angreppsytan har flyttat ännu längre vänster än så, till utvecklarens maskin själv. GitHub-attackeren är ett bra exempel. Det var inte osäker kod som nådde produktion. Det var en komprometterad VS Code-tillägg på en utvecklares laptop som exfiltrerade autentiseringsuppgifter innan någon skrev en rad kod.

I praktiska termer betyder att flytta uppströms att säkerheten måste fungera kontinuerligt där koden faktiskt skrivs och där verktyg installeras. Det betyder att validera vad som körs på utvecklarenheter, fånga skadliga paket och tillägg innan de landar och automatiskt testa för exploaterbar risk när koden ändras, snarare än att vänta på att en människa schemalägger det. Målet är en sluten loop där upptäckt, validering och åtgärd sker som en del av utvecklingsarbetsflödet snarare än som en separat process som körs efteråt.

Med AI-agenter som automatiskt hämtar beroenden och verktyg, hur bör företag omvärdera förtroendet för öppen källkod och tredjepartsprogram?

Standarden med AI-agenter är att de hämtar beroenden och verktyg automatiskt med mycket liten mänsklig tillsyn. Det förändrar förtroendemodellen fundamentalt eftersom du har kod som körs på utvecklarmaskiner som ingen uttryckligen valde att installera. (GOOGL )

Vercel-attackeren är ett bra exempel på var detta går fel. Vercel hackades inte direkt. En legitim AI-tillägg hade OAuth-åtkomst till en anställds Google-konto, och det tillägget komprometterades uppströms genom en infostealer på leverantörens sida. Detta är samma mönster vi ser i öppen källkod, där betrodd tredjepartskod blir inträdespunkten. Risken ackumuleras eftersom en komprometterad utvecklarstation ger en angripare samma åtkomstnivå som en betrodd ingenjör. De kan modifiera kod, infoga skadliga beroenden eller publicera manipulerade versioner av legitim programvara, och dessa ändringar hämtas av byggnadspipeliner och sprids genom betrodda uppdateringar nedströms.

Företag måste börja behandla allt som körs på en utvecklarmaskin som en del av deras angreppsyta. Det inkluderar AI-agenter, verktygen de installerar, tilläggen de är beroende av, allt. Om du bara har insyn i kända öppna källkods-paket missar du de lager där dessa attacker faktiskt sker.

Begreppet självskyddande programvara är övertygande. Vilka kärnförmågor krävs för att göra den visionen fungera i stor skala?

För att göra självskyddande programvara fungera i stor skala behöver du en sluten loop. Systemet måste kunna testa verkliga angreppsvägar när koden ändras, bekräfta om något är faktiskt exploaterbart eller avvisa det om det inte är, och generera och applicera korrigeringar inom utvecklingsarbetsflödet, sedan omtesta för att bekräfta att korrigeringen fungerade. Hela den cykeln måste köras kontinuerligt utan att vänta på att någon schemalägger det. Det viktiga är att detta inte handlar om att ta bort människor från säkerhet. Det handlar om att hantera det konstanta arbetet så att säkerhetsteam kan fokusera på de beslut som faktiskt behöver bedömning.

Utvecklare kämpar ofta med för många varningar och falska positiva från säkerhetsverktyg. Hur hjälper Aikido team att fokusera på vad som faktiskt är viktigt?

Två tredjedelar av säkerhetsledare i vår undersökning om AI i säkerhet och utveckling sa att deras team har förbigått säkerhetsprocesser, avvisat resultat eller försenat korrigeringar på grund av falska positiva. Det är den verkliga kostnaden för bullriga verktyg. Det slösar inte bara bort tid, det urholkar aktivt säkerheten eftersom människor slutar lita på varningarna.

Sättet vi tacklar detta på Aikido är genom räckviddsanalys och autotriage. Istället för att flagga varje sårbarhet och lämna det till säkerhetsteamet att avgöra vad som är viktigt, analyserar vi om en sårbarhet faktiskt är nåbar i er kod och kan utnyttjas i er miljö. Om den inte kan, ser ert team aldrig den. Det minskar dramatiskt volymen av varningar och betyder att när något faktiskt kommer genom, är det värt att agera på.

Er plattform kombinerar kod, moln, körningssäkerhet och automatiserad penetrationstestning. Varför är en enhetlig tillvägagångssätt mer effektivt än att använda flera fristående verktyg?

Vår undersökning om AI i säkerhet och utveckling fann något motsägelsefullt: säkerhetsteam som led av incidenter körde faktiskt fler leverantörsverktyg än de som inte gjorde det. Fler verktyg betydde inte bättre säkerhet. Det betydde mer brus, fler dubblettresultat och mer tid som tillbringades med att korrelera varningar över dashboards istället för att faktiskt åtgärda problem.

Därför byggde vi Aikido som en enda plattform över kod, moln, körning, beroenden och pipelines. När alla dessa signaler är på en plats kan du dubblettresultat, förstå om en sårbarhet i er kod faktiskt är nåbar i er molnmiljö och prioritera baserat på verklig risk snarare än att behandla varje skanners utdata som lika brådskande. Team tillbringar mindre tid med att triage över verktyg och mer tid med att åtgärda vad som faktiskt är viktigt. Och var och en av dessa funktioner måste stå på egna ben. En enhetlig plattform som är medelmåttig på allt är bara konsoliderar problemet. Varje del av plattformen måste vara lika bra eller bättre än den fristående alternativet, annars faller konsolideringsargumentet.

Aikido har skalat snabbt och nått betydande dragkraft på kort tid. Vilka har varit de största utmaningarna i att bygga och växa ett cybersäkerhetsföretag i denna takt?

Den uppenbara utmaningen är att vara ett cybersäkerhetsföretag från Belgien. Branschen har traditionellt byggts ut från Tel Aviv och Silicon Valley, och det fanns tidig skepticism om huruvida en världsklass-säkerhetsplattform kunde komma från någon annanstans. Men det avståndet visade sig vara en fördel. Vi återanvände inte samma spelböcker. Vi började med en utvecklarförst-tillvägagångssätt och en paketerad produkt som gjorde det enkelt för team att självregistrera sig, vilket är hur vi tyst blev den dominerande utvecklar-säkerhetsplattformen för SMB.

Den större utmaningen är bara takten. Vi nådde enhörningsstatus i januari 2026 med vår serie B, intäkterna växte femfaldigt förra året och vi litar nu på över 100 000 team, inklusive Premier League, Revolut och SoundCloud. I år har vi lanserat Device Protection för leverantörskedjesäkerhet, Infinite för AI-penetrationstestning och ett partnerskap med Lovable för inbäddad säkerhet i vibe-kodningsflöden. Att flytta så snabbt medan kvaliteten hålls hög över hela plattformen är den konstanta utmaningen. Men det är ett bra problem att ha.

Som AI-nativ utveckling blir standard, vad ser framtiden för programvarusäkerhet ut under de närmaste åren?

Det ärliga svaret är att traditionella säkerhetsarbetsflöden redan kämpar för att hålla jämna steg. Periodiska granskningar, schemalagda penetrationstester, efterföljande skanning, allt detta antar en utvecklingstakt som inte längre existerar. AI-genererad kod och autonoma agenter introducerar förändringar snabbare än dessa processer kan validera dem.

Vi tror att säkerhet måste bli en kontinuerlig återkopplingsloop byggd direkt in i hur programvara utvecklas. Vi kallar detta självskyddande programvara. Varje kodändring testas för verkliga angreppsvägar, resultat valideras för faktisk exploaterbarhet, korrigeringar genereras och omtestas, allt utan att vänta på att en människa schemalägger det. Tidiga versioner av detta finns redan idag och vi bygger mot det över kod, moln, körning och leverantörskedja.

Nästa steg bortom detta är självunderhållande programvara, där säkerhet inte bara handlar om att upptäcka och åtgärda problem utan aktivt underhåller hälsan hos kodbasen över tid. Det är längre bort, men grunderna läggs nu. Det enda som är säkert är att ribban för att utföra sofistikerade attacker har redan kollapsat tack vare AI, så den defensiva sidan måste flytta i samma takt.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka Aikido.