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

Willem Delbare, medgrundare och VD för Aikido, är serieentreprenör inom SaaS och teknisk grundare med gedigen erfarenhet av att bygga programvaruföretag för utvecklare. Innan han startade Aikido 2022 var han med och grundade HR-plattformen Officient, hållbarhetsinitiativet FutureproofedCities och CRM-företaget Teamleader. Där var han CTO och bidrog till att utveckla företaget till en av Belgiens uppmärksammade SaaS-framgångar. Under karriären har han fokuserat på att förenkla komplexa tekniska utmaningar inom molninfrastruktur, SaaS-skalbarhet och cybersäkerhet. Under hans ledning har Aikido snabbt blivit ett av Europas snabbast växande cybersäkerhetsstartupbolag, med praktiska säkerhetslösningar för moderna utvecklingsteam.

Aikido är ett cybersäkerhetsföretag med bas i Belgien som hjälper utvecklare och ingenjörsteam att skydda applikationer och molnmiljöer med en gemensam plattform. Den samlar kodskanning, beroendeanalys, hantering av molnets säkerhetsläge, skydd under körning och AI-stödda tester i ett förenklat system. Målet är att minska komplexitet och falsklarm samt slippa hantera splittrade säkerhetslösningar från flera leverantörer. Med utvecklarnas behov i centrum betonar Aikido automatisering, kontinuerlig övervakning och enkla flöden för rättningar, så att säkerheten kan byggas direkt in i programvarans utvecklingslivscykel.

Vilka erfarenheter av att bygga och utveckla företag som Teamleader och Officient fick dig att grunda Aikido Security 2022? Hur formade din tekniska bakgrund som grundare visionen om en mer utvecklarvänlig cybersäkerhet?

Under det senaste årtiondet har jag hittat mitt kall inom B2B SaaS. Jag har varit teknisk medgrundare och CTO i tre startupbolag och gjort tre exits inom HR-teknik, faktureringsteknik och koldioxidredovisning. Helt olika världar, men med samma drivkraft: att bygga programvara som inte får människor att vilja kasta sin bärbara dator genom fönstret.

Men i varje företag höll säkerheten mig vaken om nätterna. Rädslan för ett dataintrång var verklig, och verktygen som skulle hjälpa såg ut som cockpiten i en F-16: dyra, överväldigande och byggda för någon med en doktorsexamen i datavetenskap, inte för ett team som vill leverera snabbt.

Vi grundade Aikido Security för att lösa just det problemet. Aikido erbjuder organisationer i alla storlekar en samlad plattform för programvarusäkerhet med utvecklarna i centrum. Den samlar de viktigaste funktionerna för kod, moln och körning på ett ställe, så att utvecklare lättare kan leverera säkert.

Sedan dess har AI gjort programvaruleveranserna ännu snabbare och angreppsytan större. Nästa steg är att hjälpa organisationer hålla jämna steg genom programvara som skyddar sig själv.

I februari lanserade vi Aikido Infinite, vår lösning för kontinuerliga AI-penetrationstester. Den kontrollerar om sårbarheter faktiskt kan utnyttjas och sluter kretsen kring rättningarna innan koden når produktion.

Utvecklarmiljöer beskrivs nu som en av säkerhetens största blinda fläckar. Vad har förändrats på senare tid och gjort frågan så kritisk?

Utvecklarnas datorer har alltid varit värdefulla mål. De innehåller inloggningsuppgifter till molnet, SSH-nycklar, npm-publiceringstoken, Kubernetes-konfigurationer och direktåtkomst till källkod. Under de senaste 6 till 12 månaderna har angripare däremot upptäckt hur lätt datorerna kan komprometteras genom verktyg som utvecklarna redan litar på. Vi har följt det under hela året: Trivy, TanStack, Bitwarden CLI, VS Code-tillägget Nx Console och nu GitHub. Alla har drabbats av intrång genom utvecklarverktyg, och enheten har varit målet i samtliga fall.

Problemet är att de flesta säkerhetsteam inte ser vad som faktiskt körs på datorerna. EDR övervakar applikationerna, men inte paketen, tilläggen och AI-verktygen inuti dem. Samtidigt hämtar utvecklare dagligen nya paket, tillägg och AI-verktyg med mycket få kontroller. LLM:er har också gjort det lättare att skapa övertygande skadlig kod och sänkt tröskeln för angripare generellt. Alla dessa attacker utnyttjar glappet mellan innehållet på utvecklardatorerna och det säkerhetsteamen faktiskt kan se.

Vi ser en kraftig ökning av leveranskedjeattacker samtidigt som AI får bred spridning. Hur förändrar AI balansen mellan angripare och försvarare?

AI har gjort det mycket lättare att skapa skadlig kod för leveranskedjeattacker. Att bygga övertygande attacklaster, dölja kod och förstå paketregister tillräckligt väl för att missbruka dem krävde tidigare verklig teknisk skicklighet. Nu räcker ett LLM-abonnemang. Vi har sett det direkt hos TeamPCP, som ligger bakom de flesta stora attacker i år, däribland det senaste intrånget hos GitHub. Gruppen är inte särskilt tekniskt avancerad, men har utfört många attacker. AI spelar en stor roll i hur den har kunnat utöka verksamheten. För ett år sedan hanterade vi intrång i enskilda paket. Nu ser vi självreplikerande maskar som Shai-Hulud och sammanlänkade kampanjer som rör sig mellan register och använder inloggningsuppgifter stulna vid ett intrång för att möjliggöra nästa.

AI hjälper också försvaret, men på andra sätt. Säkerhetsteam kan genomföra kontinuerliga penetrationstester av hela kodbaser med agenter som testar hundratals angreppsvägar parallellt. Det frigör tid för beslut som fortfarande kräver mänskligt omdöme. På enhetsnivå hjälper AI också till att upptäcka skadliga paket tidigare genom att analysera det som ska installeras innan det når utvecklarens dator. Men sanningen är att angriparna just nu tjänar mer på AI än försvararna. Tröskeln för att skapa skadlig kod har sjunkit snabbare än tröskeln för att upptäcka den.

Aikido talar om att flytta säkerheten tidigare i utvecklingskedjan. Vad betyder det konkret för team som bygger och levererar programvara i dag?

En stor del av branschen har i åratal flyttat säkerheten åt vänster, alltså till tidigare steg i CI/CD-pipelinen. Angreppsytan har dock flyttats ännu längre bakåt, till utvecklarens egen dator. Intrånget hos GitHub är ett bra exempel. Det var inte osäker kod som nådde produktion, utan ett komprometterat VS Code-tillägg på en utvecklares laptop som förde ut inloggningsuppgifter innan någon skrev en rad kod.

I praktiken måste säkerheten fungera kontinuerligt där koden skrivs och verktygen installeras. Man måste kontrollera vad som körs på utvecklarnas enheter, fånga skadliga paket och tillägg innan de når fram och automatiskt testa risker som kan utnyttjas när koden ändras, i stället för att vänta på en planerad granskning. Målet är ett slutet kretslopp där upptäckt, validering och rättning ingår i utvecklingsarbetet, inte i en separat process efteråt.

När AI-agenter automatiskt hämtar beroenden och verktyg, hur bör företag tänka om kring förtroendet för öppen källkod och tredjepartskod?

AI-agenter hämtar som standard beroenden och verktyg automatiskt med mycket lite mänsklig tillsyn. Det förändrar förtroendemodellen i grunden: kod som ingen uttryckligen valt att installera körs på utvecklarnas datorer.

Intrånget hos Vercel visar hur det kan gå fel. Vercel hackades inte direkt. Ett legitimt AI-tillägg hade OAuth-åtkomst till en anställds Google-konto och hade komprometterats tidigare i kedjan genom en informationsstjälare hos leverantören. Det är samma återkommande mönster inom öppen källkod: betrodd tredjepartskod blir ingången. Risken förstärks eftersom en komprometterad utvecklararbetsstation ger angriparen samma åtkomst som en betrodd ingenjör. Angriparen kan ändra kod, lägga in skadliga beroenden eller publicera manipulerade versioner av legitim programvara. Byggpipelines tar upp ändringarna, som sprids vidare genom betrodda uppdateringar.

Företag måste se allt som körs på en utvecklares dator som en del av sin angreppsyta: AI-agenterna, verktygen de installerar, tilläggen de är beroende av, allt. Om man bara ser kända paket med öppen källkod missar man de lager där attackerna faktiskt sker.

Idén om självskyddande programvara är tilltalande. Vilka kärnfunktioner behövs för att det ska fungera i stor skala?

Det kräver ett slutet kretslopp. Vid varje kodändring måste systemet testa verkliga angreppsvägar, bekräfta att ett problem kan utnyttjas eller avfärda fyndet om det inte kan det, och skapa och tillämpa rättningar i utvecklingsarbetet. Därefter måste det testa igen för att bekräfta att rättningen fungerar. Hela cykeln ska köras kontinuerligt utan att någon först måste schemalägga den. Det handlar inte om att ta bort människor från säkerheten, utan om att hantera det löpande arbetet så att teamen kan fokusera på beslut som verkligen kräver omdöme.

Utvecklare kämpar ofta med för många varningar och falsklarm från säkerhetsverktyg. Hur hjälper Aikido teamen att fokusera på det väsentliga?

Två tredjedelar av säkerhetsansvariga i vår undersökning State of AI in Security & Development uppgav att deras team hade kringgått säkerhetsprocesser, ignorerat fynd eller skjutit upp rättningar på grund av falsklarm. Det är den verkliga kostnaden för verktyg med för mycket brus. De slösar inte bara tid, utan försämrar aktivt säkerheten när människor slutar lita på varningarna.

Hos Aikido använder vi nåbarhetsanalys och automatisk triage. I stället för att flagga varje sårbarhet och låta säkerhetsteamet bedöma vikten analyserar vi om den faktiskt kan nås i er kod och utnyttjas i er miljö. Om inte får teamet aldrig se den. Det minskar antalet varningar drastiskt och gör dem som ändå kommer fram värda att agera på.

Er plattform förenar säkerhet för kod, moln och körning med automatiserade penetrationstester. Varför är en samlad metod effektivare än flera fristående verktyg?

Vår undersökning State of AI in Security & Development gav ett oväntat resultat: team som hade drabbats av incidenter använde fler leverantörsverktyg än team utan incidenter. Fler verktyg betydde inte bättre säkerhet, utan mer brus, dubbla fynd och mer tid åt att jämföra varningar mellan kontrollpaneler i stället för att åtgärda problemen.

Därför byggde vi Aikido som en plattform för kod, moln, körning, beroenden och pipelines. När signalerna samlas kan man ta bort dubbla fynd, förstå om en sårbarhet i koden faktiskt kan nås i molnmiljön och prioritera efter verklig risk i stället för att behandla alla skannerresultat som lika brådskande. Teamen lägger mindre tid på triage mellan verktyg och mer på viktiga rättningar. Men varje funktion måste också hålla måttet på egen hand. En plattform som är medelmåttig på allt samlar bara problemet på ett ställe. Varje del måste vara minst lika bra som det fristående alternativet, annars håller inte argumentet för konsolidering.

Aikido har vuxit snabbt och fått starkt fäste på kort tid. Vilka har varit de största utmaningarna med att bygga och utveckla ett cybersäkerhetsföretag i den takten?

Den uppenbara är att vara ett cybersäkerhetsföretag från Belgien. Branschen har traditionellt vuxit fram i Tel Aviv och Silicon Valley, och i början var många tveksamma till om en säkerhetsplattform i världsklass kunde komma någon annanstans ifrån. Men avståndet blev en fördel. Vi upprepade inte samma arbetssätt. Vi utgick från utvecklarnas behov och en samlad produkt som teamen själva kunde ta i bruk. Så blev vi i det tysta den dominerande utvecklarsäkerhetsplattformen för små och medelstora företag.

Den större utmaningen är takten. Vi nådde enhörningsstatus i januari 2026 med vår serie B, intäkterna femdubblades förra året och nu litar över 100 000 team på oss, däribland Premier League, Revolut och SoundCloud. Bara i år har vi lanserat Device Protection för leveranskedjesäkerhet, Infinite för AI-penetrationstester och ett partnerskap med Lovable för inbyggd säkerhet i vibe coding-flöden. Att gå så snabbt fram och hålla hög kvalitet i varje del av plattformen är den ständiga utmaningen. Men det är ett bra problem att ha.

När utveckling med AI som utgångspunkt blir standard, hur ser programvarusäkerheten ut under de kommande åren?

Det ärliga svaret är att traditionella säkerhetsarbetsflöden redan har svårt att hinna med. Periodiska granskningar, schemalagda penetrationstester och skanning i efterhand förutsätter en utvecklingstakt som egentligen inte finns längre. AI-genererad kod och autonoma agenter inför ändringar snabbare än de processerna kan kontrollera dem.

Vi tror att säkerhet måste bli en kontinuerlig återkoppling direkt inbyggd i programvaruutvecklingen. Vi kallar det självskyddande programvara. Varje kodändring testas mot verkliga angreppsvägar, fynd valideras för faktisk möjlighet att utnyttja dem och rättningar skapas och testas igen utan att en människa behöver schemalägga det. Tidiga former finns redan i dag, och vi bygger vidare mot det för kod, moln, körning och leveranskedjan.

Nästa steg är självunderhållande programvara: säkerheten ska inte bara hitta och rätta problem utan aktivt hålla kodbasen frisk över tid. Det ligger längre fram, men grunden läggs nu. Säkert är att AI redan har fått tröskeln för avancerade attacker att kollapsa. Försvaret måste därför gå framåt i samma takt.

Tack för den givande intervjun. Läsare som vill veta mer kan besöka Aikido.