Willem Delbare, medstifter og administrerende direktør for Aikido – Interviewserie

Willem Delbare, medstifter og administrerende direktør for Aikido, er serieiværksætter inden for SaaS og teknisk grundlægger med stor erfaring i at opbygge softwarevirksomheder for udviklere. Før han lancerede Aikido i 2022, var han med til at stifte HR-platformen Officient, bæredygtighedsinitiativet FutureproofedCities og CRM-virksomheden Teamleader. Her var han CTO og hjalp virksomheden med at vokse til en af Belgiens bemærkelsesværdige SaaS-succeser. Gennem karrieren har han arbejdet med at forenkle komplekse tekniske udfordringer inden for cloudinfrastruktur, SaaS-skalerbarhed og cybersikkerhed. Under hans ledelse er Aikido hurtigt blevet en af Europas hurtigst voksende cybersikkerhedsstartups med praktiske sikkerhedsløsninger til moderne udviklingsteams.

Aikido er en cybersikkerhedsvirksomhed med base i Belgien, der hjælper udviklere og ingeniørteams med at beskytte applikationer og cloudmiljøer gennem én samlet platform. Den kombinerer kodescanning, afhængighedsanalyse, styring af cloudmiljøets sikkerhedstilstand, runtimebeskyttelse og AI-understøttede tests i ét enkelt system. Målet er at mindske kompleksitet og falske positiver og spare organisationer for at administrere fragmenterede sikkerhedsløsninger fra flere leverandører. Med udviklernes behov i centrum lægger Aikido vægt på automatisering, løbende overvågning og forenklede arbejdsgange til rettelser, så sikkerhed kan indgå direkte i softwareudviklingens livscyklus.

Hvilke erfaringer fra at opbygge og udvikle virksomheder som Teamleader og Officient førte til, at du stiftede Aikido Security i 2022? Hvordan prægede din tekniske baggrund som grundlægger din vision om en mere udviklervenlig tilgang til cybersikkerhed?

I det seneste årti har jeg fundet mit kald i B2B SaaS. Jeg har været teknisk medstifter og CTO i tre startups og har haft tre exits inden for HR-teknologi, faktureringsteknologi og CO₂-regnskaber. Meget forskellige verdener, men med samme drivkraft: at bygge software, som ikke giver folk lyst til at smide deres bærbare computer ud ad vinduet.

Men i hver virksomhed holdt sikkerheden mig vågen om natten. Frygten for et databrud var reel, og værktøjerne, der skulle hjælpe, lignede cockpittet i en F-16: dyre, overvældende og lavet til en person med en ph.d. i datalogi, ikke til et udviklingsteam, der vil udgive hurtigt.

Vi stiftede Aikido Security for at løse netop det problem. Aikido tilbyder organisationer i alle størrelser en samlet softwaresikkerhedsplatform med udviklerne i centrum. Den samler de væsentlige sikkerhedsfunktioner for kode, cloud og runtime, så udviklere lettere kan udgive sikkert.

Siden da har AI gjort softwareleverancer endnu hurtigere og angrebsfladen større. Næste skridt er at hjælpe organisationer med at følge med gennem software, der sikrer sig selv.

I februar lancerede vi Aikido Infinite, vores løsning til løbende AI-penetrationstest. Den kontrollerer, om sårbarheder faktisk kan udnyttes, og afslutter hele rettelsesforløbet, før koden kommer i produktion.

Udviklermiljøer beskrives nu som en af sikkerhedens største blinde vinkler. Hvad har ændret sig for nylig og gjort emnet så kritisk?

Udviklernes computere har altid været værdifulde mål. De rummer cloudadgangsoplysninger, SSH-nøgler, npm-publiceringstokens, Kubernetes-konfigurationer og direkte adgang til kildekode. I de seneste 6 til 12 måneder har angriberne imidlertid opdaget, hvor let de kan kompromitteres gennem værktøjer, udviklerne allerede stoler på. Vi har fulgt det hele året: Trivy, TanStack, Bitwarden CLI, VS Code-udvidelsen Nx Console og nu GitHub. Alle er blevet kompromitteret gennem udviklerværktøjer, og i alle tilfælde var enheden målet.

Problemet er, at de fleste sikkerhedsteams ikke kan se, hvad der faktisk kører på computerne. EDR overvåger applikationer, men ser ikke pakker, udvidelser og AI-værktøjer inde i dem. Imens henter udviklere dagligt nye pakker, udvidelser og AI-værktøjer med meget få kontroller. LLM’er har også gjort det lettere at skabe overbevisende malware og sænket adgangsbarrieren for angribere generelt. Alle disse angreb rammer kløften mellem indholdet på udviklernes computere og det, sikkerhedsteams faktisk kan se.

Vi ser en bølge af forsyningskædeangreb på samme tid, som AI bliver bredt anvendt. Hvordan ændrer AI balancen mellem angribere og forsvarere?

AI har gjort det betydeligt lettere at skabe malware til forsyningskædeangreb. Overbevisende angrebspayloads, sløring af kode og tilstrækkelig forståelse af pakkeregistre til at misbruge dem krævede tidligere reelle tekniske færdigheder. Nu er et LLM-abonnement nok. Vi har set det direkte med TeamPCP, der har stået bag de fleste større angreb i år, herunder det seneste brud hos GitHub. Gruppen er ikke særligt teknisk avanceret, men har udført mange angreb, og AI er en væsentlig grund til, at den har kunnet udvide sin aktivitet. For et år siden håndterede vi kompromittering af enkelte pakker. Nu ser vi selvkopierende orme som Shai-Hulud og sammenkædede kampagner, der bevæger sig mellem registre og bruger adgangsoplysninger stjålet ved ét indbrud til at muliggøre det næste.

AI hjælper også forsvaret, men på andre måder. Sikkerhedsteams kan gennemføre løbende penetrationstest af hele kodebaser med AI-agenter, der tester hundredvis af angrebsveje parallelt. Det frigør tid til beslutninger, der stadig kræver menneskelig dømmekraft. På enhedsniveau hjælper AI også med at opdage skadelige pakker tidligere ved at analysere det, der skal installeres, før det når udviklerens computer. Men sandheden er, at angriberne i øjeblikket får mere ud af AI end forsvarerne. Barrieren for at skabe malware er faldet hurtigere end barrieren for at opdage den.

Aikido taler om at flytte sikkerheden længere frem i udviklingsforløbet. Hvad betyder det konkret for teams, der bygger og udgiver software i dag?

En stor del af branchen har i årevis flyttet sikkerheden mod venstre, altså til tidligere trin i CI/CD-pipelinen. Men angrebsfladen er rykket endnu længere frem, til selve udviklerens computer. Bruddet hos GitHub er et godt eksempel. Det var ikke usikker kode, der kom i produktion, men en kompromitteret VS Code-udvidelse på én udviklers bærbare computer, som sendte adgangsoplysninger ud, før nogen skrev en linje kode.

I praksis skal sikkerheden fungere løbende dér, hvor koden skrives, og værktøjer installeres. Man skal kontrollere det, der kører på udviklernes enheder, opdage skadelige pakker og udvidelser, før de når frem, og automatisk teste for udnyttelige risici, når koden ændres, i stedet for at vente på en planlagt gennemgang. Målet er et lukket kredsløb, hvor opdagelse, validering og rettelser indgår i udviklingsarbejdet frem for i en særskilt efterfølgende proces.

Når AI-agenter automatisk downloader afhængigheder og værktøjer, hvordan bør virksomheder gentænke tilliden til open source og tredjepartskode?

AI-agenter henter som udgangspunkt afhængigheder og værktøjer automatisk med meget lidt menneskeligt tilsyn. Det ændrer tillidsmodellen grundlæggende: På udviklernes computere kører kode, som ingen udtrykkeligt har valgt at installere.

Bruddet hos Vercel viser, hvordan det kan gå galt. Vercel blev ikke hacket direkte. En legitim AI-udvidelse havde OAuth-adgang til en medarbejders Google-konto, og udvidelsen blev kompromitteret tidligere i kæden via en infostealer hos leverandøren. Det er det samme tilbagevendende mønster i open source, hvor betroet tredjepartskode bliver indgangen. Risikoen vokser, fordi en kompromitteret udviklerarbejdsstation giver angriberen samme adgang som en betroet ingeniør. Angriberen kan ændre kode, indsætte skadelige afhængigheder eller udgive manipulerede versioner af legitim software. Buildpipelines overtager ændringerne, som spredes videre gennem betroede opdateringer.

Virksomheder skal regne alt, der kører på en udviklers computer, som en del af angrebsfladen: AI-agenter, de værktøjer, de installerer, de udvidelser, de afhænger af, det hele. Hvis man kun har indblik i kendte open source-pakker, overser man de lag, hvor angrebene faktisk finder sted.

Idéen om software, der sikrer sig selv, er overbevisende. Hvilke kernefunktioner kræves for at få det til at fungere i stor skala?

Det kræver et lukket kredsløb. Systemet skal teste virkelige angrebsveje, hver gang koden ændres, bekræfte om et problem faktisk kan udnyttes eller afvise fundet, hvis det ikke kan, og generere og anvende rettelser i udviklingsarbejdet. Derefter skal det teste igen og kontrollere, at rettelsen virker. Hele forløbet skal køre kontinuerligt uden at vente på, at nogen planlægger det. Det handler ikke om at fjerne mennesker fra sikkerheden, men om at håndtere det løbende arbejde, så teams kan fokusere på beslutninger, der virkelig kræver dømmekraft.

Udviklere kæmper ofte med for mange advarsler og falske positiver fra sikkerhedsværktøjer. Hvordan hjælper Aikido teams med at fokusere på det væsentlige?

To tredjedele af sikkerhedslederne i vores undersøgelse State of AI in Security & Development sagde, at deres teams havde omgået sikkerhedsprocesser, ignoreret fund eller udsat rettelser på grund af falske positiver. Det er den reelle pris for værktøjer med for meget støj. De spilder ikke kun tid, men svækker aktivt sikkerheden, fordi folk holder op med at stole på advarslerne.

Hos Aikido bruger vi analyse af nåbarhed og automatisk triage. I stedet for at markere alle sårbarheder og lade sikkerhedsteamet afgøre betydningen undersøger vi, om en sårbarhed faktisk kan nås i jeres kode og udnyttes i jeres miljø. Hvis ikke, ser teamet den slet ikke. Det reducerer antallet af advarsler drastisk og gør de advarsler, der kommer igennem, værd at reagere på.

Jeres platform kombinerer kode-, cloud- og runtimesikkerhed med automatiserede penetrationstest. Hvorfor er en samlet tilgang mere effektiv end flere selvstændige værktøjer?

Vores undersøgelse State of AI in Security & Development viste noget overraskende: Sikkerhedsteams, der havde oplevet hændelser, brugte flere leverandørværktøjer end dem uden hændelser. Flere værktøjer betød ikke bedre sikkerhed, men mere støj, flere dobbeltfund og mere tid brugt på at sammenholde advarsler mellem dashboards i stedet for at rette problemerne.

Derfor byggede vi Aikido som én platform for kode, cloud, runtime, afhængigheder og pipelines. Når alle signaler samles, kan man fjerne dobbeltfund, forstå om en sårbarhed i koden reelt kan nås i cloudmiljøet og prioritere efter faktisk risiko frem for at betragte alle scannerresultater som lige hastende. Teams bruger mindre tid på triage på tværs af værktøjer og mere på vigtige rettelser. Men hver funktion skal også kunne stå alene. En platform, der er middelmådig til alt, samler blot problemet ét sted. Hver del skal være mindst lige så god som det selvstændige alternativ, ellers holder argumentet for konsolidering ikke.

Aikido er vokset hurtigt og har fået solidt fodfæste på kort tid. Hvad har været de største udfordringer ved at bygge og udvikle en cybersikkerhedsvirksomhed i det tempo?

Den oplagte udfordring er at være en cybersikkerhedsvirksomhed fra Belgien. Branchen er traditionelt vokset frem i Tel Aviv og Silicon Valley, og i begyndelsen var der skepsis over for, om en sikkerhedsplatform i verdensklasse kunne komme andre steder fra. Men afstanden blev en fordel. Vi gentog ikke de samme fremgangsmåder. Vi startede med udviklernes behov og et samlet produkt, som teams selv kunne tage i brug. Sådan blev vi i det stille den dominerende udviklersikkerhedsplatform for små og mellemstore virksomheder.

Den større udfordring er tempoet. Vi nåede unicornstatus i januar 2026 med vores serie B, omsætningen blev femdoblet sidste år, og nu stoler over 100.000 teams på os, herunder Premier League, Revolut og SoundCloud. Alene i år har vi lanceret Device Protection til forsyningskædesikkerhed, Infinite til AI-penetrationstest og et samarbejde med Lovable om indbygget sikkerhed i vibe coding-arbejdsgange. At bevæge sig så hurtigt og bevare høj kvalitet i hver del af platformen er den konstante udfordring. Men det er et godt problem at have.

Når udvikling med AI som udgangspunkt bliver normen, hvordan ser fremtiden for softwaresikkerhed så ud i de kommende år?

Det ærlige svar er, at traditionelle sikkerhedsarbejdsgange allerede har svært ved at følge med. Periodiske gennemgange, planlagte penetrationstest og efterfølgende scanning forudsætter en udviklingstakt, der reelt ikke længere findes. AI-genereret kode og autonome agenter indfører ændringer hurtigere, end de processer kan kontrollere dem.

Vi mener, at sikkerhed skal være et kontinuerligt feedbackkredsløb indbygget direkte i softwareudviklingen. Vi kalder det software, der sikrer sig selv. Hver kodeændring testes mod virkelige angrebsveje, fund kontrolleres for faktisk udnyttelighed, og rettelser genereres og testes igen uden at vente på, at et menneske planlægger det. Tidlige versioner findes allerede, og vi bygger videre mod det på tværs af kode, cloud, runtime og forsyningskæden.

Næste skridt er software, der vedligeholder sig selv. Sikkerheden skal da ikke kun opdage og rette problemer, men aktivt holde kodebasen sund over tid. Det ligger længere ude, men fundamentet lægges nu. Sikkert er det, at AI allerede har fået barrieren for avancerede angreb til at kollapse. Forsvaret må derfor bevæge sig lige så hurtigt.

Tak for det gode interview. Læsere, der vil vide mere, kan besøge Aikido.