Willem Delbare, medgrunnlegger og CEO av Aikido – Intervju-serie

Willem Delbare, medgrunnlegger og CEO av Aikido, er en serial SaaS-entrepreneur og teknisk grunnlegger med en sterk bakgrunn i å bygge utviklerfokuserte programvarebedrifter. Før han lanserte Aikido i 2022, var han medgrunnlegger av HR-plattformen Officient, bærekraft-initiativet FutureproofedCities og CRM-selskapet Teamleader, hvor han var CTO og hjalp til å skala selskapet til å bli ett av Belgias mest kjente SaaS-suksesser. Gjennom sin karriere har Delbare fokusert på å forenkle komplekse tekniske utfordringer i sky-infrastruktur, SaaS-skalerbarhet og cybersikkerhet. Under hans ledelse har Aikido raskt vokst til å bli ett av Europas raskest voksende cybersikkerhets-selskaper ved å fokusere på praktiske sikkerhetsløsninger designet for moderne utviklingsteam.

Aikido er et belgisk cybersikkerhets-selskap som fokuserer på å hjelpe utviklere og ingeniørteam med å sikre applikasjoner og sky-miljøer gjennom en enkelt, samlet plattform. Selskapet kombinerer flere sikkerhetsfunksjoner, som kode-scanning, avhengighetsanalyse, sky-sikkerhetspostur-håndtering, kjøretidsskydd og AI-assistert testing, i ett strømlinjet system. Deres tilnærming er designet for å redusere kompleksitet, minimere falske positiver og eliminere behovet for organisasjoner å håndtere fragmenterte sikkerhets-stacker over flere leverandører. Bygget med en utvikler-foresatt filosofi, legger Aikido vekt på automatisering, kontinuerlig overvåking og forenklede reparasjons-workflows for å hjelpe selskaper med å integrere sikkerhet direkte i programvare-utviklingslivssyklusen.

Hva erfaringer fra å bygge og skala selskaper som Teamleader og Officient, ledet deg til å grunnlegge Aikido Security i 2022, og hvordan har din bakgrunn som teknisk grunnlegger formet din visjon for å skape en mer utvikler-vennlig tilnærming til cybersikkerhet?

Over de siste ti årene har jeg funnet min kalling i B2B SaaS. Med tre startups som teknisk medgrunnlegger og CTO og tre eksiter over HR-teknologi, faktura-teknologi og karbonregnskap. Alle veldig forskjellige verdener, men med samme besettelse av å bygge programvare som ikke får folk til å kaste bærbare datamaskiner ut av vinduet.

Men på hver av disse selskapene, holdt sikkerhet meg våken om natten. Frykten for et dataangrep var virkelig, og verktøyene som skulle hjelpe, så ut som inni cockpiten på et F-16-fly. Dyre, overveldende og bygget for noen med en PhD i datavitenskap, ikke for et utviklingsteam som prøver å levere raskt.

Vi grunnla Aikido Security for å løse denne utfordringen direkte. Aikido tilbyr en samlet, utvikler-foresatt programvare-sikkerhetsplattform for organisasjoner av alle størrelser som bringer sammen de essensielle sikkerhetsfunksjonene over kode, sky og kjøretid på ett sted for å gjøre det enklere for utviklere å levere trygt og sikkert.

Siden da har AI gjort programvare-levering enda raskere og angrepsflaten større. Vår neste kapittel er å enable organisasjoner å holde tritt med selv-sikker programvare.

I februar lanserte vi Aikido Infinite, vår kontinuerlige AI-penetreringstest-løsning som validerer utnyttbarhet og lukker reparasjons-løkken før kode når produksjon.

Utvikler-miljøer beskrives nå som ett av de største sikkerhets-blindpunktene. Hva har endret seg nylig for å gjøre dette til en kritisk sak?

Utvikler-maskiner har alltid vært verdifulle mål. De inneholder sky-credencialetter, SSH-nøkler, npm-publiseringstoken, Kubernetes-konfigurasjoner, direkte tilgang til kildekode. Men hva som har endret seg i løpet av de siste 6 til 12 månedene, er at angripere har funnet ut hvordan enkelt de kan kompromittere dem gjennom verktøyene utviklerne allerede stoler på. Vi har sporet dette over hele året. Trivy, TanStack, Bitwarden CLI, Nx Console VS Code-utvidelsen og nå GitHub, alle ble angrepet gjennom utvikler-verktøy, alle målrettet enheten.

Problemet er at de fleste sikkerhets-teamene har ingen visibilitet i hva som faktisk kjører på disse maskinene. EDR overvåker på applikasjonsnivå, men den ser ikke pakker, utvidelser eller AI-verktøy som kjører inne i disse applikasjonene. Samtidig trekker utviklere inn nye pakker, utvidelser og AI-verktøy hver dag med svært lite menneskelig tilsyn. LLM-er har også gjort det enklere å lage overbevisende malware, som har senket terskelen for angripere over hele linjen. Gapet mellom hva som er på utvikler-maskiner og hva sikkerhets-teamene faktisk kan se, er der alle disse angrepene lander.

Vi ser en økning i leverandør-kjede-angrep samtidig som AI blir mer utbredt. Hvordan endrer AI balansen mellom angripere og forsvarere?

AI har gjort det mye enklere å lage leverandør-kjede-malware. Bygging overbevisende payload, kamuflere kode og forstå hvordan pakke-registre fungerer godt nok til å misbruke dem, krevde tidligere ekte teknisk ferdighet. Nå krever det bare en LLM-abonnement. Vi har sett dette direkte med TeamPCP, som har stått bak de fleste større leverandør-kjede-angrepene i år, inkludert det nylige GitHub-angrepet. De er ikke en spesielt sofistikert gruppe, men de har vært prolifiske, og AI er en stor del av hvordan de har skalert. For ett år siden håndterte vi enkelt-pakke-kompromisser. Nå ser vi selv-repliserende ormer som Shai-Hulud og kjede-kampanjer som flytter over registre, stjeler credencialetter fra ett kompromiss til å drive det neste.

På den defensive siden hjelper AI også, men på forskjellige måter. Sikkerhets-teamene kan nå kjøre kontinuerlig penetreringstest over hele kodebasen ved hjelp av AI-agenter som tester hundrevis av angreps-stier i parallell. Dette frigjør tid for de dømmende avgjørelsene som fortsatt trenger en menneskelig. På enhetsnivå hjelper AI også med å fange skadelige pakker tidligere ved å analysere hva som installeres før det når utvikler-maskinen. Men den ærlige virkeligheten er at angriperne for tiden drar størst nytte av AI enn forsvarerne gjør. Terskelen for å lage malware har sunket raskere enn terskelen for å oppdage det.

Aikido snakker om å flytte sikkerhet oppstrøms. Hva betyr dette i praktisk forstand for team som bygger og leverer programvare i dag?

De fleste i industrien har brukt år på å flytte sikkerhet til venstre i CI/CD-pipeline. Problemet er at angrepsflaten har flyttet seg enda lenger til venstre enn det, til utvikler-maskinen selv. GitHub-angrepet er et godt eksempel. Det var ikke usikker kode som nådde produksjon. Det var en kompromittert VS Code-utvidelse på en utviklers laptop som eksfiltrerte credencialetter før noen skrev en linje kode.

I praktisk forstand betyr å flytte oppstrøms at sikkerhet må fungere kontinuerlig der koden faktisk skrives og der verktøy installeres. Dette betyr å validere hva som kjører på utvikler-enheter, å fange skadelige pakker og utvidelser før de lander, og å automatisk teste for utnyttbar risiko når kode endres, i stedet for å vente på at en menneskelig skal planlegge det. Målet er en lukket løkke hvor oppdaging, validering og reparasjon skjer som en del av utviklings-workflowen, i stedet for som en separat prosess som kjører etterpå.

Med AI-agenter som automatisk laster ned avhengigheter og verktøy, hvordan bør selskaper tenke om tillit til åpen kilde og tredjeparts-kode?

Standarden med AI-agenter er at de trekker inn avhengigheter og verktøy automatisk med svært lite menneskelig tilsyn. Dette endrer tillits-modellen fundamentalt fordi du har kode som kjører på utvikler-maskiner som ingen eksplisitt har valgt å installere. (GOOGL )

Vercel-angrepet er et godt eksempel på hvor dette går galt. Vercel ble ikke hakket direkte. En legitim AI-utvidelse hadde OAuth-tilgang til en ansatts Google-konto, og den utvidelsen var kompromittert oppstrøms gjennom en infostealer på leverandørens side. Dette er samme mønsteret vi ser i åpen kilde, hvor tillitsfuld tredjeparts-kode blir inngangspunktet. Risikoen akselerer fordi en kompromittert utvikler-arbeidsstasjon gir en angriper samme tilgangsnivå som en tillitsfull ingeniør. De kan modifisere kode, sette inn skadelige avhengigheter eller publisere forfalskede versjoner av legitim programvare, og disse endringene blir plukket opp av bygge-pipelines og spredt gjennom tillitsfulle oppdateringer nedstrøms.

Selskaper må begynne å behandle alt som kjører på en utvikler-maskin som en del av deres angrepsflate. Dette inkluderer AI-agenter, verktøyene de installerer, utvidelsene de avhenger av, alt. Hvis du bare har visibilitet i kjente åpen kilde-pakker, måter du de lagene hvor disse angrepene faktisk skjer.

Begrepet selv-sikker programvare er overbevisende. Hva er de nødvendige evnene som kreves for å gjøre denne visjonen fungere i stor skala?

For å gjøre selv-sikker programvare fungere i stor skala, trenger du en lukket løkke. Systemet må kunne teste virkelige angreps-stier når kode endres, bekrefte om noe er faktisk utnyttbart eller forkaste det hvis det ikke er, og generere og anvende fikser innenfor utviklings-workflowen, og så teste igjen for å bekrefte at fikset fungerte. Den hele syklusen må kjøre kontinuerlig uten å vente på at noen planlegger det. Det viktige er at dette ikke handler om å fjerne mennesker fra sikkerhet. Det handler om å håndtere det konstante arbeidet så sikkerhets-teamene kan fokusere på avgjørelsene som faktisk trenger dømmekraft.

Utviklere har ofte problemer med for mange varslinger og falske positiver fra sikkerhets-verktøy. Hvordan hjelper Aikido team med å fokusere på hva som faktisk betyr noe?

To tredjedeler av sikkerhets-ledere i vår State of AI in Security & Development-undersøkelse sa at deres team hadde bypasset sikkerhets-prosesser, forkastet funn eller forsinket fikser på grunn av falske positiver. Det er den virkelige kostnaden av støyende verktøy. Det sparer ikke bare tid, det degraderer også sikkerhet fordi folk slutter å stole på varslingene.

Måten vi takler dette på Aikido er gjennom rekkefølge-analyse og auto-atriage. I stedet for å flagge hver enkelt sårbarhet og la sikkerhets-teamet avgjøre hva som betyr noe, analyserer vi om en sårbarhet faktisk er nåbar i koden din og kan utnyttes i din miljø. Hvis den ikke kan, ser teamet ditt aldri den. Dette kutter drastisk volumet av varslinger og betyr at når noe faktisk kommer gjennom, er det verdt å handle på.

Deres plattform kombinerer kode, sky, kjøretid-sikkerhet og automatisert pentesting. Hvorfor er en samlet tilnærming mer effektiv enn å bruke flere enkelt-verktøy?

Vår State of AI in Security & Development-forskning fant noe motsigende: sikkerhets-teamene som led av hendelser, kjørte faktisk flere leverandør-verktøy enn de som ikke gjorde det. Flere verktøy betydde ikke bedre sikkerhet. Det betydde mer støy, flere duplikate funn og mer tid brukt på å korrelere varslinger over dashboards i stedet for å faktisk fikse ting.

Det er derfor vi bygde Aikido som en enkelt plattform over kode, sky, kjøretid, avhengigheter og pipelines. Når alle disse signalene er på ett sted, kan du deduplisere funn, forstå om en sårbarhet i koden din faktisk er nåbar i din sky-miljø, og prioritere basert på virkelig risiko i stedet for å behandle hver enkelt skanners utgang som like urgente. Teamene bruker mindre tid på å triage over verktøy og mer tid på å fikse hva som faktisk betyr noe. Og hver av disse evnene må stå på egne ben. En samlet plattform som er middelmådig på alt, er bare konsolidering av problemet. Hver del av plattformen må være like god eller bedre enn den enkeltstående alternativet, ellers kollapser konsoliderings-argumentet.

Aikido har skalert raskt og nådd betydelig traksi i en kort tid. Hva har vært de største utfordringene i å bygge og vokse et cybersikkerhets-selskap i denne farten?

Det åpenbare er å være et cybersikkerhets-selskap fra Belgia. Industrien har tradisjonelt vært bygget ut av Tel Aviv og Silicon Valley, og det var tidlig skeptisisme om hvorvidt en verdensklasse-sikkerhetsplattform kunne komme fra andre steder. Men den distansen endte opp med å bli en fordel. Vi ikke gjentok de samme spillbøkene. Vi startet med en utvikler-foresatt tilnærming og en bundlet produkt som gjorde det enkelt for team å selv-onboard, som er hvordan vi ble den dominante utvikler-sikkerhetsplattformen for SMB-er.

Den større utfordringen er bare farten. Vi nådde enhjørning-status i januar 2026 med vår Serie B, omsetningen vokste femdoblet i fjor, og vi er nå tillitsfulle over 100 000 team, inkludert Premier League, Revolut og SoundCloud. I år alene har vi lansert Device Protection for leverandør-kjede-sikkerhet, Infinite for AI-penetreringstest og et samarbeid med Lovable for innbygget sikkerhet i vibe-koding-workflows. Å flytte så raskt mens kvaliteten holdes høy over hele plattformen, er den konstante utfordringen. Men det er et godt problem å ha.

Som AI-nativ utvikling blir standard, hva ser fremtiden ut for programvare-sikkerhet de neste årene?

Det ærlige svaret er at tradisjonelle sikkerhets-workflows allerede sliter med å holde tritt. Periodiske gjennomganger, planlagte pentest, etterfølgende scanning, all dette antar en utviklingsfart som ikke lenger eksisterer. AI-generert kode og autonome agenter introduserer endringer raskere enn disse prosessene kan validere dem.

Vi tror sikkerhet må bli en kontinuerlig tilbakemeldings-løkke bygget direkte inn i hvordan programvare utvikles. Vi kaller dette selv-sikker programvare. Hver kode-endring blir testet for virkelige angreps-stier, funn blir validert for faktisk utnyttbarhet, fikser blir generert og testet igjen, all uten å vente på at en menneskelig skal planlegge det. Tidlige versjoner av dette eksisterer allerede i dag, og vi bygger mot det over kode, sky, kjøretid og leverandør-kjede.

Neste skritt utover det er selv-maintenert programvare, hvor sikkerhet ikke bare er å fange og fikse problemer, men også aktivt å vedlikeholde kodebasens helse over tid. Det er lengre ute, men grunnlaget legges nå. Det ene som er sikkert er at barrieren for å utføre sofistikerte angrep har allerede kollapset takket være AI, så den defensive siden må flytte i samme fart.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke Aikido.