Willem Delbare, Co-Fondatore e Amministratore Delegato di Aikido – Serie di Interviste

Willem Delbare, cofondatore e amministratore delegato di Aikido, è un imprenditore seriale nel SaaS e un fondatore di formazione tecnica, con una solida esperienza nella creazione di aziende software rivolte agli sviluppatori. Prima di avviare Aikido nel 2022, ha cofondato la piattaforma HR Officient, l’iniziativa per la sostenibilità FutureproofedCities e l’azienda CRM Teamleader. Qui ha ricoperto il ruolo di CTO, contribuendo a trasformarla in uno dei casi di successo SaaS più importanti del Belgio. Nel corso della carriera si è concentrato sulla semplificazione di sfide tecniche complesse relative a infrastrutture cloud, scalabilità SaaS e cybersicurezza. Sotto la sua guida, Aikido è diventata rapidamente una delle startup di cybersicurezza in più forte crescita in Europa, puntando su soluzioni pratiche per i moderni team di sviluppo.

Aikido è un’azienda di cybersicurezza con sede in Belgio che aiuta sviluppatori e team di ingegneria a proteggere applicazioni e ambienti cloud attraverso un’unica piattaforma. Riunisce scansione del codice, analisi delle dipendenze, gestione della postura di sicurezza cloud, protezione in fase di esecuzione e test assistiti dall’IA in un sistema semplificato. L’obiettivo è ridurre complessità e falsi positivi, evitando alle organizzazioni di gestire strumenti di sicurezza frammentati di diversi fornitori. Progettata mettendo al primo posto gli sviluppatori, Aikido privilegia automazione, monitoraggio continuo e procedure di correzione semplificate, per integrare la sicurezza direttamente nel ciclo di sviluppo del software.

Quali esperienze nella creazione e nella crescita di aziende come Teamleader e Officient l’hanno portata a fondare Aikido Security nel 2022? In che modo il suo profilo di fondatore tecnico ha plasmato la visione di una cybersicurezza più adatta agli sviluppatori?

Negli ultimi dieci anni ho trovato la mia vocazione nel SaaS B2B. Sono stato cofondatore tecnico e CTO di tre startup, con tre operazioni di exit nei settori delle tecnologie HR, della fatturazione e della contabilizzazione delle emissioni di carbonio. Mondi molto diversi, ma con la stessa ossessione: creare software che non faccia venire voglia di lanciare il portatile dalla finestra.

In ciascuna di quelle aziende, però, la sicurezza mi teneva sveglio la notte. La paura di una violazione dei dati era concreta, e gli strumenti che avrebbero dovuto aiutarci sembravano la cabina di pilotaggio di un F-16: costosi, complicati e progettati per chi ha un dottorato in informatica, non per un team che vuole pubblicare software rapidamente.

Abbiamo fondato Aikido Security proprio per risolvere questo problema. Offriamo alle organizzazioni di ogni dimensione una piattaforma unificata di sicurezza software, pensata prima di tutto per gli sviluppatori. Riunisce in un solo luogo le funzioni essenziali per codice, cloud e runtime, facilitando il rilascio sicuro del software.

Da allora, l’IA ha accelerato ancora la distribuzione del software e ampliato la superficie di attacco. Il prossimo passo è consentire alle organizzazioni di tenere il ritmo grazie a software capace di proteggersi da solo.

A febbraio abbiamo lanciato Aikido Infinite, la nostra soluzione di penetration testing continuo basata sull’IA. Verifica se le vulnerabilità sono realmente sfruttabili e completa il ciclo di correzione prima che il codice arrivi in produzione.

Gli ambienti degli sviluppatori sono ora descritti come uno dei maggiori punti ciechi della sicurezza. Che cosa è cambiato di recente, rendendo questo problema così critico?

I computer degli sviluppatori sono sempre stati obiettivi preziosi. Contengono credenziali cloud, chiavi SSH, token di pubblicazione npm, configurazioni Kubernetes e accesso diretto al codice sorgente. Negli ultimi 6–12 mesi, però, gli aggressori hanno capito quanto sia facile comprometterli tramite strumenti di cui gli sviluppatori si fidano già. Lo abbiamo seguito durante tutto l’anno: Trivy, TanStack, Bitwarden CLI, l’estensione Nx Console per VS Code e ora GitHub. In tutti i casi la compromissione è passata dagli strumenti di sviluppo e il dispositivo era il bersaglio.

Il problema è che la maggior parte dei team di sicurezza non vede ciò che viene realmente eseguito su quei computer. L’EDR monitora le applicazioni, ma non i pacchetti, le estensioni o gli strumenti di IA che funzionano al loro interno. Nel frattempo, gli sviluppatori introducono ogni giorno nuovi pacchetti, estensioni e strumenti di IA con pochissime verifiche. Gli LLM hanno anche facilitato la creazione di malware convincente, abbassando la barriera d’ingresso per gli aggressori in generale. Tutti questi attacchi sfruttano il divario tra ciò che si trova sui computer degli sviluppatori e ciò che i team di sicurezza riescono a vedere.

Gli attacchi alla catena di fornitura aumentano mentre l’IA viene adottata su vasta scala. Come cambia l’equilibrio tra aggressori e difensori?

L’IA ha reso molto più semplice creare malware per attaccare la catena di fornitura. Preparare payload convincenti, offuscare il codice e comprendere i registri dei pacchetti abbastanza da abusarne richiedeva vere competenze tecniche. Ora basta un abbonamento a un LLM. Lo abbiamo osservato direttamente con TeamPCP, responsabile della maggior parte dei grandi attacchi di quest’anno, compresa la recente violazione di GitHub. Non è un gruppo particolarmente avanzato, ma è stato molto prolifico e l’IA ha avuto un ruolo importante nell’espansione delle sue attività. Un anno fa affrontavamo compromissioni di singoli pacchetti. Oggi vediamo worm autoreplicanti come Shai-Hulud e campagne concatenate che passano da un registro all’altro, usando le credenziali rubate in una compromissione per alimentare quella successiva.

L’IA aiuta anche la difesa, ma in modi diversi. I team possono eseguire penetration test continui su intere basi di codice con agenti che verificano centinaia di percorsi di attacco in parallelo. Questo libera tempo per le decisioni che richiedono ancora giudizio umano. Sui dispositivi, aiuta anche a individuare prima i pacchetti dannosi, analizzando ciò che sta per essere installato prima che raggiunga il computer dello sviluppatore. La realtà, però, è che al momento gli aggressori beneficiano dell’IA più dei difensori. La barriera per creare malware è scesa più rapidamente di quella per rilevarlo.

Aikido parla di spostare la sicurezza a monte. Che cosa significa concretamente per i team che oggi sviluppano e distribuiscono software?

Gran parte del settore ha passato anni a spostare la sicurezza a sinistra, cioè nelle fasi precedenti della pipeline CI/CD. Ma la superficie di attacco si è spostata ancora più a monte, sul computer dello sviluppatore stesso. La violazione di GitHub è un buon esempio: non era codice insicuro arrivato in produzione, ma un’estensione VS Code compromessa sul portatile di uno sviluppatore che sottraeva credenziali prima ancora che qualcuno scrivesse una riga di codice.

In pratica, la sicurezza deve operare continuamente dove il codice viene scritto e gli strumenti vengono installati. Bisogna verificare ciò che viene eseguito sui dispositivi degli sviluppatori, intercettare pacchetti ed estensioni dannosi prima che arrivino e testare automaticamente i rischi sfruttabili a ogni modifica del codice, senza aspettare una revisione programmata. L’obiettivo è un ciclo chiuso di rilevamento, verifica e correzione integrato nel lavoro di sviluppo, non un processo separato eseguito a posteriori.

Con gli agenti di IA che scaricano automaticamente dipendenze e strumenti, come dovrebbero le aziende ripensare la fiducia nel codice open source e di terze parti?

Per impostazione predefinita, gli agenti di IA scaricano dipendenze e strumenti automaticamente, con pochissima supervisione umana. Questo cambia radicalmente il modello di fiducia: sui computer degli sviluppatori viene eseguito codice che nessuno ha scelto esplicitamente di installare.

La violazione di Vercel mostra bene che cosa può andare storto. Vercel non è stata violata direttamente. Un’estensione di IA legittima aveva accesso OAuth all’account Google di un dipendente ed era stata compromessa a monte tramite un infostealer presso il fornitore. È lo stesso schema ricorrente nell’open source: codice di terze parti considerato affidabile diventa il punto di ingresso. Il rischio si moltiplica perché una postazione di sviluppo compromessa dà all’aggressore lo stesso accesso di un ingegnere fidato. Può modificare codice, inserire dipendenze dannose o pubblicare versioni alterate di software legittimo. Le pipeline di compilazione incorporano queste modifiche, che si diffondono a valle attraverso aggiornamenti ritenuti affidabili.

Le aziende devono considerare tutto ciò che viene eseguito sul computer di uno sviluppatore parte della propria superficie di attacco: agenti di IA, strumenti che installano, estensioni da cui dipendono, tutto. Una visibilità limitata ai pacchetti open source noti lascia fuori proprio i livelli in cui si verificano questi attacchi.

L’idea di un software che si protegge da solo è convincente. Quali capacità fondamentali servono per realizzarla su larga scala?

Serve un ciclo chiuso. A ogni modifica del codice, il sistema deve testare percorsi di attacco reali, confermare la sfruttabilità di un problema o scartare la segnalazione se non è sfruttabile, poi generare e applicare correzioni nel lavoro di sviluppo e ripetere i test per verificarne l’efficacia. L’intero ciclo deve funzionare continuamente, senza aspettare che qualcuno lo programmi. Non si tratta di eliminare le persone dalla sicurezza, ma di gestire il lavoro costante affinché i team possano concentrarsi sulle decisioni che richiedono davvero giudizio umano.

Gli sviluppatori spesso faticano a gestire troppe segnalazioni e falsi positivi degli strumenti di sicurezza. Come aiuta Aikido a concentrarsi su ciò che conta davvero?

Due terzi dei responsabili della sicurezza nel nostro sondaggio State of AI in Security & Development hanno dichiarato che i loro team avevano aggirato procedure, ignorato segnalazioni o ritardato correzioni a causa dei falsi positivi. Questo è il vero costo degli strumenti troppo rumorosi. Non fanno soltanto perdere tempo: peggiorano attivamente la sicurezza perché le persone smettono di fidarsi degli avvisi.

In Aikido usiamo l’analisi della raggiungibilità e il triage automatico. Invece di segnalare ogni vulnerabilità e lasciare al team il compito di stabilire che cosa conta, verifichiamo se è davvero raggiungibile nel vostro codice e sfruttabile nel vostro ambiente. Se non lo è, il vostro team non la vede mai. Questo riduce drasticamente gli avvisi e rende quelli che arrivano meritevoli di intervento.

La vostra piattaforma unisce sicurezza del codice, del cloud e del runtime a penetration test automatizzati. Perché un approccio unificato è più efficace di diversi strumenti indipendenti?

La nostra ricerca State of AI in Security & Development ha rilevato qualcosa di controintuitivo: i team che avevano subito incidenti usavano più strumenti di fornitori rispetto a quelli senza incidenti. Più strumenti non significavano maggiore sicurezza, ma più rumore, segnalazioni duplicate e tempo dedicato a correlare avvisi tra dashboard invece di correggere i problemi.

Per questo abbiamo costruito Aikido come un’unica piattaforma per codice, cloud, runtime, dipendenze e pipeline. Riunire tutti i segnali consente di eliminare duplicati, capire se una vulnerabilità del codice è davvero raggiungibile nel cloud e stabilire priorità in base al rischio reale, invece di considerare ugualmente urgente ogni risultato di ogni scanner. I team dedicano meno tempo al triage tra strumenti e più alle correzioni importanti. Ma ciascuna capacità deve essere valida anche da sola. Una piattaforma mediocre in tutto si limita a riunire il problema in un luogo. Ogni componente deve eguagliare o superare l’alternativa indipendente, altrimenti l’argomento a favore del consolidamento non regge.

Aikido è cresciuta rapidamente e ha ottenuto una forte diffusione in poco tempo. Quali sono state le maggiori sfide nel costruire e far crescere un’azienda di cybersicurezza a questo ritmo?

La più evidente è essere un’azienda di cybersicurezza del Belgio. Il settore si è sviluppato tradizionalmente a Tel Aviv e nella Silicon Valley, e inizialmente c’era scetticismo sulla possibilità che una piattaforma di livello mondiale nascesse altrove. Ma quella distanza è diventata un vantaggio. Non ripetevamo le stesse formule: siamo partiti dalle esigenze degli sviluppatori e da un prodotto integrato che i team potevano adottare autonomamente. Così siamo diventati, senza clamore, la piattaforma dominante di sicurezza per sviluppatori nelle PMI.

La sfida maggiore è il ritmo. Abbiamo raggiunto lo status di unicorno a gennaio 2026 con la serie B, i ricavi sono quintuplicati l’anno scorso e oggi oltre 100.000 team si fidano di noi, tra cui Premier League, Revolut e SoundCloud. Solo quest’anno abbiamo lanciato Device Protection per la sicurezza della catena di fornitura, Infinite per i penetration test con IA e una partnership con Lovable per integrare la sicurezza nei processi di vibe coding. Procedere così velocemente mantenendo alta la qualità di ogni parte della piattaforma è una sfida costante. Ma è un buon problema da avere.

Man mano che lo sviluppo basato fin dall’inizio sull’IA diventa la norma, come sarà la sicurezza del software nei prossimi anni?

La risposta sincera è che i processi tradizionali di sicurezza faticano già a tenere il passo. Revisioni periodiche, penetration test programmati e scansioni a posteriori presuppongono un ritmo di sviluppo che non esiste più davvero. Il codice generato dall’IA e gli agenti autonomi introducono modifiche più rapidamente di quanto quei processi riescano a verificarle.

Pensiamo che la sicurezza debba diventare un ciclo continuo di feedback integrato direttamente nello sviluppo del software. Lo chiamiamo software che si protegge da solo. Ogni modifica del codice viene testata rispetto a percorsi di attacco reali, le segnalazioni vengono verificate per la sfruttabilità effettiva e le correzioni vengono generate e ritestate senza aspettare che una persona lo programmi. Esistono già versioni iniziali, e stiamo realizzando questo approccio per codice, cloud, runtime e catena di fornitura.

Il passo successivo è un software capace di provvedere alla propria manutenzione: la sicurezza non si limita a rilevare e correggere problemi, ma mantiene attivamente sana la base di codice nel tempo. È un traguardo più lontano, ma le fondamenta si stanno gettando ora. La certezza è che l’IA ha già abbattuto la barriera per eseguire attacchi sofisticati: la difesa deve quindi avanzare alla stessa velocità.

Grazie per questa interessante intervista. I lettori che desiderano saperne di più possono visitare Aikido.