Willem Delbare, medgrunnlegger og administrerende direktør i Aikido – Intervjuserie

Willem Delbare, medgrunnlegger og administrerende direktør i Aikido, er seriegründer innen SaaS og teknisk grunnlegger med solid erfaring i å bygge programvareselskaper for utviklere. Før han startet Aikido i 2022, var han med på å grunnlegge HR-plattformen Officient, bærekraftsinitiativet FutureproofedCities og CRM-selskapet Teamleader. Der var han CTO og bidro til å utvikle selskapet til en av Belgias bemerkelsesverdige SaaS-suksesser. Gjennom karrieren har han konsentrert seg om å forenkle komplekse tekniske utfordringer innen skyinfrastruktur, SaaS-skalerbarhet og cybersikkerhet. Under hans ledelse har Aikido raskt blitt et av Europas raskest voksende cybersikkerhetsoppstartsselskaper, med praktiske sikkerhetsløsninger for moderne utviklingsteam.

Aikido er et cybersikkerhetsselskap med base i Belgia som hjelper utviklere og ingeniørteam med å sikre applikasjoner og skymiljøer gjennom én samlet plattform. Den kombinerer kodeskanning, avhengighetsanalyse, styring av skymiljøets sikkerhetstilstand, beskyttelse under kjøring og KI-støttede tester i ett enkelt system. Målet er å redusere kompleksitet og falske positiver og spare organisasjoner for å håndtere fragmenterte sikkerhetsløsninger fra flere leverandører. Med utviklernes behov i sentrum legger Aikido vekt på automatisering, kontinuerlig overvåking og enkle arbeidsflyter for rettinger, slik at sikkerhet kan inngå direkte i programvarens utviklingslivssyklus.

Hvilke erfaringer med å bygge og utvikle selskaper som Teamleader og Officient førte til at du grunnla Aikido Security i 2022? Hvordan formet din tekniske bakgrunn som grunnlegger visjonen om en mer utviklervennlig tilnærming til cybersikkerhet?

Det siste tiåret har jeg funnet mitt kall innen B2B SaaS. Jeg har vært teknisk medgrunnlegger og CTO i tre oppstartsselskaper og hatt tre exiter innen HR-teknologi, faktureringsteknologi og karbonregnskap. Helt ulike verdener, men med samme drivkraft: å bygge programvare som ikke gir folk lyst til å kaste den bærbare datamaskinen ut av vinduet.

Men i hvert selskap holdt sikkerheten meg våken om natten. Frykten for et datainnbrudd var reell, og verktøyene som skulle hjelpe, lignet cockpiten i en F-16: dyre, overveldende og laget for noen med doktorgrad i informatikk, ikke et utviklingsteam som vil levere raskt.

Vi grunnla Aikido Security for å løse nettopp dette problemet. Aikido tilbyr organisasjoner i alle størrelser en samlet plattform for programvaresikkerhet med utviklerne i sentrum. Den samler de viktigste sikkerhetsfunksjonene for kode, sky og kjøring på ett sted, slik at utviklere lettere kan levere sikkert.

Siden da har KI gjort programvareleveranser enda raskere og angrepsflaten større. Neste steg er å hjelpe organisasjoner med å holde tritt gjennom programvare som sikrer seg selv.

I februar lanserte vi Aikido Infinite, løsningen vår for kontinuerlige KI-baserte penetrasjonstester. Den kontrollerer om sårbarheter faktisk kan utnyttes, og fullfører rettingsløpet før koden kommer i produksjon.

Utviklermiljøer omtales nå som en av sikkerhetens største blindsoner. Hva har endret seg i det siste og gjort dette så kritisk?

Utviklernes datamaskiner har alltid vært verdifulle mål. De inneholder skytilgangsopplysninger, SSH-nøkler, npm-publiseringstokener, Kubernetes-konfigurasjoner og direkte tilgang til kildekode. De siste 6 til 12 månedene har angriperne imidlertid oppdaget hvor lett maskinene kan kompromitteres gjennom verktøy utviklerne allerede stoler på. Vi har fulgt dette hele året: Trivy, TanStack, Bitwarden CLI, VS Code-utvidelsen Nx Console og nå GitHub. Alle ble kompromittert gjennom utviklerverktøy, og enheten var målet i samtlige tilfeller.

Problemet er at de fleste sikkerhetsteam ikke ser hva som faktisk kjører på maskinene. EDR overvåker applikasjonene, men ikke pakkene, utvidelsene eller KI-verktøyene inne i dem. Samtidig henter utviklere daglig nye pakker, utvidelser og KI-verktøy med svært få kontroller. LLM-er har også gjort det enklere å lage overbevisende skadevare og dermed senket terskelen for angripere generelt. Alle disse angrepene utnytter gapet mellom innholdet på utviklernes maskiner og det sikkerhetsteamene faktisk kan se.

Vi ser en kraftig økning i leverandørkjedeangrep samtidig som KI blir utbredt. Hvordan endrer KI balansen mellom angripere og forsvarere?

KI har gjort det langt enklere å lage skadevare til leverandørkjedeangrep. Overbevisende angrepslaster, tilsløring av kode og god nok forståelse av pakkeregistre til å misbruke dem krevde tidligere reelle tekniske ferdigheter. Nå er et LLM-abonnement nok. Vi har sett dette direkte hos TeamPCP, som har stått bak de fleste større angrep i år, inkludert det siste innbruddet hos GitHub. Gruppen er ikke spesielt teknisk avansert, men har gjennomført mange angrep. KI har vært viktig for at den har kunnet utvide aktiviteten. For et år siden håndterte vi kompromittering av enkeltpakker. Nå ser vi selvreplikerende ormer som Shai-Hulud og sammenkjedede kampanjer som flytter mellom registre og bruker tilgangsopplysninger stjålet i ett innbrudd til å muliggjøre det neste.

KI hjelper også forsvaret, men på andre måter. Sikkerhetsteam kan gjennomføre kontinuerlige penetrasjonstester av hele kodebaser med agenter som tester hundrevis av angrepsveier parallelt. Det frigjør tid til beslutninger som fortsatt krever menneskelig skjønn. På enhetsnivå hjelper KI også med å finne skadelige pakker tidligere ved å analysere det som skal installeres, før det når utviklerens maskin. Men sannheten er at angriperne for tiden får mer ut av KI enn forsvarerne. Terskelen for å lage skadevare har falt raskere enn terskelen for å oppdage den.

Aikido snakker om å flytte sikkerheten tidligere inn i utviklingsløpet. Hva betyr det konkret for team som bygger og leverer programvare i dag?

En stor del av bransjen har i årevis flyttet sikkerheten mot venstre, til tidligere steg i CI/CD-pipelinen. Angrepsflaten har imidlertid flyttet seg enda lenger bakover, til selve utviklerens maskin. Innbruddet hos GitHub er et godt eksempel. Det var ikke usikker kode som nådde produksjon, men en kompromittert VS Code-utvidelse på én utviklers bærbare maskin som sendte tilgangsopplysninger ut, før noen skrev en linje kode.

I praksis må sikkerheten fungere kontinuerlig der koden skrives og verktøyene installeres. Man må kontrollere hva som kjører på utviklernes enheter, fange skadelige pakker og utvidelser før de når frem, og automatisk teste risikoer som kan utnyttes når koden endres, uten å vente på en planlagt gjennomgang. Målet er et lukket kretsløp der oppdagelse, validering og retting inngår i utviklingsarbeidet, ikke i en egen prosess i etterkant.

Når KI-agenter automatisk laster ned avhengigheter og verktøy, hvordan bør selskaper revurdere tilliten til åpen kildekode og tredjepartskode?

KI-agenter henter som standard avhengigheter og verktøy automatisk med svært lite menneskelig tilsyn. Det endrer tillitsmodellen grunnleggende: På utviklernes maskiner kjører kode som ingen uttrykkelig har valgt å installere.

Innbruddet hos Vercel viser hvordan dette kan gå galt. Vercel ble ikke hacket direkte. En legitim KI-utvidelse hadde OAuth-tilgang til Google-kontoen til en ansatt, og utvidelsen ble kompromittert tidligere i kjeden gjennom en informasjonsstjeler hos leverandøren. Det er det samme mønsteret vi stadig ser i åpen kildekode: betrodd tredjepartskode blir inngangen. Risikoen forsterkes fordi en kompromittert utviklerarbeidsstasjon gir angriperen samme tilgang som en betrodd ingeniør. Angriperen kan endre kode, sette inn skadelige avhengigheter eller publisere manipulerte versjoner av legitim programvare. Byggpipelinene tar opp endringene, som spres videre gjennom betrodde oppdateringer.

Selskaper må betrakte alt som kjører på en utviklers maskin som en del av angrepsflaten: KI-agentene, verktøyene de installerer, utvidelsene de er avhengige av, alt. Hvis man bare ser kjente pakker med åpen kildekode, overser man lagene der disse angrepene faktisk skjer.

Ideen om programvare som sikrer seg selv er overbevisende. Hvilke kjernefunksjoner kreves for å få dette til i stor skala?

Det krever et lukket kretsløp. Ved hver kodeendring må systemet teste reelle angrepsveier, bekrefte om et problem faktisk kan utnyttes eller forkaste funnet hvis det ikke kan det, og generere og bruke rettinger i utviklingsarbeidet. Deretter må det teste på nytt for å bekrefte at rettingen virker. Hele syklusen skal kjøre kontinuerlig uten å vente på at noen planlegger den. Det handler ikke om å fjerne mennesker fra sikkerheten, men om å håndtere det løpende arbeidet slik at teamene kan fokusere på beslutninger som virkelig krever skjønn.

Utviklere sliter ofte med for mange varsler og falske positiver fra sikkerhetsverktøy. Hvordan hjelper Aikido teamene med å fokusere på det vesentlige?

To tredjedeler av sikkerhetslederne i vår undersøkelse State of AI in Security & Development sa at teamene deres hadde omgått sikkerhetsprosesser, ignorert funn eller utsatt rettinger på grunn av falske positiver. Det er den reelle kostnaden ved verktøy med for mye støy. De sløser ikke bare bort tid, men svekker aktivt sikkerheten fordi folk slutter å stole på varslene.

Hos Aikido bruker vi analyse av nåbarhet og automatisk triage. I stedet for å flagge alle sårbarheter og la sikkerhetsteamet avgjøre betydningen undersøker vi om sårbarheten faktisk kan nås i koden deres og utnyttes i miljøet deres. Hvis ikke, får teamet den aldri å se. Det reduserer antallet varsler kraftig og gjør de som kommer gjennom, verdt å reagere på.

Plattformen deres kombinerer sikkerhet for kode, sky og kjøring med automatiserte penetrasjonstester. Hvorfor er en samlet tilnærming mer effektiv enn flere frittstående verktøy?

Undersøkelsen vår State of AI in Security & Development ga et uventet resultat: team som hadde opplevd hendelser, brukte flere leverandørverktøy enn team uten hendelser. Flere verktøy betydde ikke bedre sikkerhet, men mer støy, doble funn og mer tid på å sammenholde varsler mellom kontrollpaneler i stedet for å rette problemene.

Derfor bygde vi Aikido som én plattform for kode, sky, kjøring, avhengigheter og pipelines. Når alle signalene samles, kan man fjerne doble funn, forstå om en sårbarhet i koden faktisk kan nås i skymiljøet og prioritere etter reell risiko fremfor å behandle alle skannerresultater som like akutte. Teamene bruker mindre tid på triage på tvers av verktøy og mer på viktige rettinger. Men hver funksjon må også stå støtt alene. En plattform som er middelmådig til alt, samler bare problemet på ett sted. Hver del må være minst like god som det frittstående alternativet, ellers holder ikke argumentet for konsolidering.

Aikido har vokst raskt og fått solid fotfeste på kort tid. Hva har vært de største utfordringene med å bygge og utvikle et cybersikkerhetsselskap i dette tempoet?

Den åpenbare er å være et cybersikkerhetsselskap fra Belgia. Bransjen har tradisjonelt vokst frem i Tel Aviv og Silicon Valley, og i starten var det skepsis til om en sikkerhetsplattform i verdensklasse kunne komme andre steder fra. Men avstanden ble en fordel. Vi gjentok ikke de samme fremgangsmåtene. Vi startet med utviklernes behov og et samlet produkt som teamene selv kunne ta i bruk. Slik ble vi i det stille den dominerende utviklersikkerhetsplattformen for små og mellomstore bedrifter.

Den større utfordringen er tempoet. Vi nådde enhjørningstatus i januar 2026 med serie B-runden, omsetningen ble femdoblet i fjor, og nå stoler over 100 000 team på oss, inkludert Premier League, Revolut og SoundCloud. Bare i år har vi lansert Device Protection for leverandørkjedesikkerhet, Infinite for KI-penetrasjonstester og et samarbeid med Lovable om innebygd sikkerhet i vibe coding-arbeidsflyter. Å bevege seg så raskt og opprettholde høy kvalitet i alle deler av plattformen er den stadige utfordringen. Men det er et godt problem å ha.

Når utvikling med KI som utgangspunkt blir standard, hvordan ser programvaresikkerheten ut de neste årene?

Det ærlige svaret er at tradisjonelle sikkerhetsarbeidsflyter allerede sliter med å holde tritt. Periodiske gjennomganger, planlagte penetrasjonstester og skanning i etterkant forutsetter en utviklingstakt som egentlig ikke finnes lenger. KI-generert kode og autonome agenter innfører endringer raskere enn disse prosessene kan kontrollere dem.

Vi tror sikkerheten må bli et kontinuerlig tilbakemeldingskretsløp direkte integrert i programvareutviklingen. Vi kaller det programvare som sikrer seg selv. Hver kodeendring testes mot reelle angrepsveier, funn kontrolleres for faktisk utnyttbarhet, og rettinger genereres og testes på nytt uten å vente på at et menneske planlegger det. Tidlige former finnes allerede i dag, og vi bygger videre mot dette for kode, sky, kjøring og leverandørkjeden.

Neste steg er programvare som vedlikeholder seg selv: Sikkerheten skal ikke bare finne og rette problemer, men aktivt holde kodebasen sunn over tid. Det ligger lenger frem, men grunnlaget legges nå. Sikkert er det at KI allerede har fått terskelen for avanserte angrep til å kollapse. Forsvaret må derfor bevege seg like raskt.

Takk for det gode intervjuet. Lesere som vil vite mer, kan besøke Aikido.