Willem Delbare, współzałożyciel i CEO Aikido – seria wywiadów

Willem Delbare, współzałożyciel i CEO Aikido, jest seryjnym przedsiębiorcą SaaS i założycielem z zapleczem technicznym oraz bogatym doświadczeniem w budowie firm tworzących oprogramowanie dla programistów. Przed uruchomieniem Aikido w 2022 roku współtworzył platformę HR Officient, inicjatywę zrównoważonego rozwoju FutureproofedCities i firmę CRM Teamleader. W tej ostatniej był CTO i pomógł rozwinąć ją w jeden ze znaczących belgijskich sukcesów SaaS. W swojej karierze skupiał się na upraszczaniu złożonych wyzwań technicznych dotyczących infrastruktury chmurowej, skalowalności SaaS i cyberbezpieczeństwa. Pod jego kierownictwem Aikido szybko stało się jednym z najszybciej rozwijających się europejskich startupów cyberbezpieczeństwa, oferując praktyczne rozwiązania dla nowoczesnych zespołów programistycznych.

Aikido to firma cyberbezpieczeństwa z siedzibą w Belgii, która pomaga programistom i zespołom inżynierskim chronić aplikacje i środowiska chmurowe za pomocą jednej platformy. Łączy skanowanie kodu, analizę zależności, zarządzanie stanem zabezpieczeń chmury, ochronę podczas działania i testy wspomagane AI w uproszczony system. Celem jest ograniczenie złożoności i fałszywych alarmów oraz wyeliminowanie potrzeby zarządzania rozproszonymi rozwiązaniami wielu dostawców. Stawiając programistów na pierwszym miejscu, Aikido podkreśla automatyzację, stały monitoring i proste procesy naprawcze, by włączyć bezpieczeństwo bezpośrednio w cykl rozwoju oprogramowania.

Jakie doświadczenia z budowy i rozwoju firm takich jak Teamleader i Officient skłoniły Pana do założenia Aikido Security w 2022 roku? Jak techniczne zaplecze założyciela wpłynęło na wizję cyberbezpieczeństwa bardziej przyjaznego programistom?

W ostatniej dekadzie znalazłem swoje powołanie w SaaS B2B. Byłem technicznym współzałożycielem i CTO trzech startupów oraz zrealizowałem trzy exity w obszarach technologii HR, fakturowania i rachunkowości emisji dwutlenku węgla. Bardzo różne światy, ale z tą samą obsesją: tworzyć oprogramowanie, przez które ludzie nie chcą wyrzucać laptopów przez okno.

W każdej z tych firm bezpieczeństwo jednak nie dawało mi spać. Obawa przed wyciekiem danych była realna, a narzędzia, które miały pomóc, wyglądały jak kokpit F-16: drogie, przytłaczające i zaprojektowane dla kogoś z doktoratem z informatyki, nie dla zespołu, który chce szybko wydawać oprogramowanie.

Założyliśmy Aikido Security właśnie po to, by rozwiązać ten problem. Oferujemy organizacjom każdej wielkości jednolitą platformę bezpieczeństwa oprogramowania, skoncentrowaną na programistach. Gromadzi najważniejsze funkcje dla kodu, chmury i środowiska wykonawczego w jednym miejscu, ułatwiając bezpieczne wydawanie oprogramowania.

Od tego czasu AI jeszcze przyspieszyła dostarczanie oprogramowania i powiększyła powierzchnię ataku. Kolejny krok to pomóc organizacjom nadążyć za tym tempem dzięki oprogramowaniu, które samo dba o swoje bezpieczeństwo.

W lutym uruchomiliśmy Aikido Infinite, nasze rozwiązanie do ciągłych testów penetracyjnych z AI. Sprawdza, czy podatności rzeczywiście da się wykorzystać, i zamyka cykl naprawy, zanim kod trafi do produkcji.

Środowiska programistów są dziś opisywane jako jeden z największych martwych punktów bezpieczeństwa. Co ostatnio się zmieniło, że problem stał się tak istotny?

Komputery programistów zawsze były cennymi celami. Zawierają dane uwierzytelniające do chmury, klucze SSH, tokeny publikacji npm, konfiguracje Kubernetes i bezpośredni dostęp do kodu źródłowego. W ostatnich 6–12 miesiącach napastnicy odkryli jednak, jak łatwo się do nich włamać przez narzędzia, którym programiści już ufają. Śledziliśmy to przez cały rok: Trivy, TanStack, Bitwarden CLI, rozszerzenie Nx Console do VS Code i teraz GitHub. W każdym z tych przypadków doszło do włamania za pośrednictwem narzędzi programistycznych, a celem było urządzenie.

Problem polega na tym, że większość zespołów bezpieczeństwa nie widzi, co faktycznie działa na tych komputerach. EDR monitoruje aplikacje, ale nie pakiety, rozszerzenia i narzędzia AI działające wewnątrz nich. Programiści tymczasem codziennie pobierają nowe pakiety, rozszerzenia i narzędzia AI, niemal bez weryfikacji. LLM-y ułatwiły też tworzenie przekonującego złośliwego oprogramowania, obniżając ogólną barierę wejścia dla napastników. Wszystkie te ataki wykorzystują lukę między zawartością komputerów a tym, co zespoły bezpieczeństwa mogą zobaczyć.

Obserwujemy falę ataków na łańcuchy dostaw, gdy AI upowszechnia się na szeroką skalę. Jak zmienia równowagę między napastnikami a obrońcami?

AI znacznie ułatwiła tworzenie złośliwego oprogramowania do ataków na łańcuch dostaw. Budowa przekonujących ładunków ataku, zaciemnianie kodu i wystarczająca znajomość rejestrów pakietów, by je nadużywać, wymagały wcześniej rzeczywistych umiejętności technicznych. Teraz wystarczy subskrypcja LLM. Widzieliśmy to bezpośrednio u TeamPCP, grupy stojącej za większością dużych ataków w tym roku, w tym niedawnym włamaniem do GitHub. Nie jest szczególnie zaawansowana technicznie, ale przeprowadziła wiele ataków, a AI w dużej mierze umożliwiła jej zwiększenie skali. Rok temu zajmowaliśmy się włamaniami dotyczącymi pojedynczych pakietów. Teraz widzimy samoreplikujące się robaki, takie jak Shai-Hulud, i powiązane kampanie przechodzące między rejestrami, które używają danych skradzionych przy jednym włamaniu do przeprowadzenia następnego.

AI pomaga też obrońcom, ale inaczej. Zespoły bezpieczeństwa mogą prowadzić ciągłe testy penetracyjne całych baz kodu za pomocą agentów sprawdzających równolegle setki ścieżek ataku. Daje to czas na decyzje nadal wymagające ludzkiego osądu. Na urządzeniach AI pomaga także wcześniej wykrywać złośliwe pakiety, analizując instalowane elementy, zanim dotrą na komputer programisty. Uczciwie trzeba jednak powiedzieć, że obecnie napastnicy korzystają z AI bardziej niż obrońcy. Próg trudności tworzenia malware spadł szybciej niż próg jego wykrywania.

Aikido mówi o przesuwaniu bezpieczeństwa do wcześniejszych etapów rozwoju. Co oznacza to w praktyce dla zespołów tworzących i wydających dziś oprogramowanie?

Duża część branży przez lata przesuwała bezpieczeństwo w lewo, do wcześniejszych etapów potoku CI/CD. Powierzchnia ataku przesunęła się jednak jeszcze wcześniej, na sam komputer programisty. Włamanie do GitHub jest dobrym przykładem. Nie chodziło o niebezpieczny kod, który trafił do produkcji, lecz o przejęte rozszerzenie VS Code na laptopie jednego programisty, wykradające dane uwierzytelniające, zanim ktokolwiek napisał wiersz kodu.

W praktyce bezpieczeństwo musi działać stale tam, gdzie pisze się kod i instaluje narzędzia. Trzeba weryfikować, co działa na urządzeniach programistów, przechwytywać złośliwe pakiety i rozszerzenia, zanim na nie dotrą, oraz automatycznie testować możliwe do wykorzystania ryzyka przy zmianach kodu, zamiast czekać na zaplanowany przegląd. Celem jest zamknięty cykl wykrywania, weryfikacji i naprawy będący częścią programowania, nie osobnym procesem uruchamianym po fakcie.

Jak firmy powinny przemyśleć zaufanie do oprogramowania open source i kodu stron trzecich, biorąc pod uwagę, że agenci AI automatycznie pobierają zależności i narzędzia?

Agenci AI domyślnie pobierają zależności i narzędzia automatycznie, przy bardzo niewielkim nadzorze człowieka. To zasadniczo zmienia model zaufania: na komputerach programistów działa kod, którego instalacji nikt świadomie nie wybrał.

Włamanie do Vercel pokazuje, co może pójść źle. Sama Vercel nie została zhakowana bezpośrednio. Legalne rozszerzenie AI miało dostęp OAuth do konta Google pracownika i zostało przejęte na wcześniejszym etapie przez program kradnący informacje po stronie dostawcy. To powtarzający się wzorzec open source: zaufany kod strony trzeciej staje się wejściem. Ryzyko rośnie, ponieważ przejęta stacja robocza programisty daje napastnikowi taki sam dostęp jak zaufanemu inżynierowi. Może zmieniać kod, dodawać złośliwe zależności lub publikować zmanipulowane wersje legalnego oprogramowania. Potoki kompilacji przejmują te zmiany, które rozchodzą się dalej przez zaufane aktualizacje.

Firmy muszą traktować wszystko, co działa na komputerze programisty, jako część powierzchni ataku: agentów AI, instalowane przez nich narzędzia, rozszerzenia, od których zależą — wszystko. Widząc tylko znane pakiety open source, przeoczają warstwy, na których faktycznie dochodzi do ataków.

Pomysł oprogramowania, które samo dba o swoje bezpieczeństwo, jest przekonujący. Jakie kluczowe możliwości są potrzebne, by działał na dużą skalę?

Potrzebny jest zamknięty cykl. Przy każdej zmianie kodu system musi testować rzeczywiste ścieżki ataku, potwierdzać możliwość wykorzystania problemu albo odrzucać zgłoszenie, jeśli nie da się go wykorzystać. Musi generować i stosować poprawki w procesie rozwoju, a następnie ponownie testować ich skuteczność. Cały cykl powinien działać stale, bez czekania, aż ktoś go zaplanuje. Nie chodzi o usunięcie ludzi z bezpieczeństwa, lecz o obsługę ciągłej pracy, by zespoły mogły skupić się na decyzjach naprawdę wymagających osądu.

Programiści często zmagają się z nadmiarem alertów i fałszywych alarmów z narzędzi bezpieczeństwa. Jak Aikido pomaga skupić się na tym, co naprawdę ważne?

Dwie trzecie liderów bezpieczeństwa w naszym badaniu State of AI in Security & Development powiedziało, że ich zespoły omijały procedury, ignorowały ustalenia lub opóźniały poprawki z powodu fałszywych alarmów. To rzeczywisty koszt narzędzi generujących nadmiar szumu. Nie tylko marnują czas, ale osłabiają bezpieczeństwo, bo ludzie przestają ufać ostrzeżeniom.

W Aikido stosujemy analizę osiągalności i automatyczną selekcję zgłoszeń. Zamiast oznaczać każdą podatność i pozostawiać ocenę zespołowi, sprawdzamy, czy jest rzeczywiście osiągalna w Państwa kodzie i możliwa do wykorzystania w Państwa środowisku. Jeśli nie, Państwa zespół nigdy jej nie zobaczy. To radykalnie zmniejsza liczbę alertów, a te, które się pojawiają, uzasadniają działanie.

Państwa platforma łączy bezpieczeństwo kodu, chmury i środowiska wykonawczego z automatycznymi testami penetracyjnymi. Dlaczego zintegrowane podejście jest skuteczniejsze niż wiele niezależnych narzędzi?

Badanie State of AI in Security & Development pokazało coś nieintuicyjnego: zespoły, które doświadczyły incydentów, używały więcej narzędzi dostawców niż te bez incydentów. Więcej narzędzi nie oznaczało lepszego bezpieczeństwa, tylko więcej szumu, powielonych ustaleń i czasu na korelowanie ostrzeżeń między panelami zamiast naprawiania problemów.

Dlatego zbudowaliśmy Aikido jako jedną platformę dla kodu, chmury, środowiska wykonawczego, zależności i potoków. Połączenie sygnałów pozwala usuwać duplikaty, ustalić rzeczywistą osiągalność podatności kodu w chmurze i ustalać priorytety według realnego ryzyka, zamiast traktować każdy wynik każdego skanera jako równie pilny. Zespoły poświęcają mniej czasu na selekcję między narzędziami, a więcej na ważne poprawki. Każda funkcja musi jednak być dobra również samodzielnie. Platforma przeciętna we wszystkim jedynie gromadzi problem w jednym miejscu. Każdy element musi dorównywać niezależnemu odpowiednikowi lub go przewyższać, inaczej argument za konsolidacją upada.

Aikido szybko się rozwinęło i zdobyło silną pozycję w krótkim czasie. Jakie były największe wyzwania budowy i rozwoju firmy cyberbezpieczeństwa w tym tempie?

Najbardziej oczywiste jest to, że jesteśmy firmą cyberbezpieczeństwa z Belgii. Branża tradycyjnie rozwijała się w Tel Awiwie i Dolinie Krzemowej, więc początkowo wątpiono, czy światowej klasy platforma może powstać gdzie indziej. Ale odległość stała się atutem. Nie powtarzaliśmy tych samych schematów. Zaczęliśmy od potrzeb programistów i zintegrowanego produktu, który zespoły mogły samodzielnie wdrażać. Tak po cichu staliśmy się dominującą platformą bezpieczeństwa programistów dla małych i średnich firm.

Większym wyzwaniem jest tempo. W styczniu 2026 roku dzięki rundzie B uzyskaliśmy status jednorożca, przychody wzrosły w zeszłym roku pięciokrotnie, a teraz ufa nam ponad 100 000 zespołów, w tym Premier League, Revolut i SoundCloud. Tylko w tym roku uruchomiliśmy Device Protection dla bezpieczeństwa łańcucha dostaw, Infinite do testów penetracyjnych z AI i współpracę z Lovable, by integrować bezpieczeństwo z procesami vibe coding. Utrzymanie wysokiej jakości każdej części platformy przy tak szybkim rozwoju to stałe wyzwanie. Ale to dobry problem.

Jak będzie wyglądać bezpieczeństwo oprogramowania w najbliższych latach, gdy rozwój oparty od początku na AI stanie się standardem?

Szczerze mówiąc, tradycyjne procesy bezpieczeństwa już teraz mają trudności z nadążaniem. Okresowe przeglądy, planowane testy penetracyjne i późniejsze skanowanie zakładają tempo rozwoju, którego właściwie już nie ma. Kod generowany przez AI i autonomiczni agenci wprowadzają zmiany szybciej, niż te procesy mogą je zweryfikować.

Uważamy, że bezpieczeństwo musi stać się ciągłą pętlą informacji zwrotnej wbudowaną bezpośrednio w rozwój oprogramowania. Nazywamy to oprogramowaniem dbającym o własne bezpieczeństwo. Każda zmiana kodu jest testowana pod kątem realnych ścieżek ataku, ustalenia są weryfikowane pod kątem rzeczywistej możliwości wykorzystania, a poprawki generowane i ponownie testowane bez czekania na planowanie przez człowieka. Wczesne wersje już istnieją i budujemy takie podejście dla kodu, chmury, środowiska wykonawczego i łańcucha dostaw.

Kolejny krok to oprogramowanie, które samo się utrzymuje: bezpieczeństwo nie tylko wykrywa i naprawia problemy, lecz aktywnie dba o kondycję bazy kodu z upływem czasu. To dalszy cel, ale fundamenty powstają już teraz. Pewne jest, że AI zburzyła już barierę wykonywania zaawansowanych ataków, więc obrona musi działać równie szybko.

Dziękujemy za wartościowy wywiad. Czytelnicy chcący dowiedzieć się więcej mogą odwiedzić Aikido.