David Mytton, CEO di Arcjet – Serie di interviste

David Mytton, fondatore e CEO di Arcjet, guida la startup di sicurezza per sviluppatori che aiuta le squadre a integrare protezioni robuste come la rilevazione di bot, la limitazione della velocità, la convalida dell’e-mail, la mitigazione degli attacchi e la riduzione dei dati direttamente nel codice dell’applicazione, dopo aver assunto la guida nel giugno 2023. Ha anche co-fondato Console, un noto newsletter e podcast di strumenti di sviluppo, ha ricoperto ruoli di consulenza come Esperto in residenza presso Seedcamp e in precedenza ha diretto l’ingegneria del prodotto presso StackPath dopo che la sua società di monitoraggio cloud era stata acquisita, mantenendo un forte interesse per il calcolo sostenibile e scrivendo attivamente su argomenti tecnici.

Arcjet è costruito attorno a una filosofia di “sicurezza come codice” che consente agli sviluppatori di proteggere le applicazioni con semplici integrazioni di SDK, posizionando la logica di sicurezza accanto alla logica aziendale per decisioni a bassa latenza e consapevoli del contesto, eliminando la necessità di infrastrutture separate; la piattaforma supporta protezioni come il blocco dei bot, i limiti di velocità e la filtrazione dei dati sensibili e continua a evolversi con funzionalità come un modello di sicurezza locale AI e un supporto di framework esteso, riflettendo la sua missione di rendere la sicurezza nel codice la norma per le app moderne. (fly.io)

Hai fondato Server Density in un momento in cui eseguire infrastrutture su larga scala era molto meno standardizzato di oggi e alla fine hai cresciuto e venduto l’azienda. Guardando indietro, quali sono state le lezioni più importanti che hai imparato sulla costruzione di strumenti per gli sviluppatori e sulla gestione di sistemi di produzione, e come quell’esperienza ha plasmato il tuo modo di pensare al software oggi?

La maggior parte degli strumenti per gli sviluppatori vince la demo e perde la produzione. Ottenere che uno sviluppatore installi qualcosa di nuovo è difficile, quindi “avvio rapido” deve essere senza attrito – ma questo è solo il minimo. Il vero modo in cui si verifica il fallimento è ciò che accade dopo “funziona”: il prodotto diventa vincolato e le squadre serie si frustrano rapidamente e lo rimuovono.

Per questo motivo, la sicurezza delle applicazioni di Arcjet è progettata per due realtà: hai bisogno di una soluzione immediata per lo spam di registrazione, la frode di account, gli attacchi di bot, l’abuso di API, ecc., e hai anche bisogno di una via di uscita per controlli avanzati – quote per utente, regole basate sul rischio, decisioni consapevoli del contesto – senza riscrivere tutto.

Il prodotto non è l’interfaccia utente. Il prodotto è il comportamento in fase di esecuzione, i casi limite, gli esempi e la documentazione di riferimento che gli sviluppatori possono fidarsi.

Uscendo da quell’esperienza, cosa ti ha portato a fondare Arcjet, e perché hai sentito che il prossimo grande cambiamento nella sicurezza delle applicazioni doveva verificarsi all’interno del codice stesso e non al livello di rete o infrastruttura?

La sicurezza perimetrale ottimizza la cosa sbagliata. Gli sviluppatori costruiscono e spediscono codice, non dashboard – e gli agenti di codifica AI non “navigano” in una console di sicurezza per proteggere un’app.

Se la tua protezione non può essere espressa come codice, esaminata in una richiesta di pull, testata in CI e distribuita insieme all’applicazione, non è “sicurezza prima degli sviluppatori”.

Arcjet esiste perché la sicurezza appartiene al livello dell’applicazione: sotto controllo di versione, testabile, osservabile e vicino alla logica aziendale dove vive effettivamente l’intento.

Arcjet incorpora la rilevazione di minacce basata su AI direttamente nei gestori di richieste dell’applicazione. Dal punto di vista tecnico, quali vantaggi offre questo approccio locale e nel codice rispetto agli strumenti di sicurezza tradizionali basati sul perimetro?

All’interno di un gestore di richieste hai l’identità, lo stato della sessione, la cronologia degli acquisti, l’età dell’account, le flag delle funzionalità, la verità del database. Puoi prendere una decisione come: “Questo sembra strano, ma è un cliente fedele – aumenta la verifica invece di bloccare”. Un proxy di rete non può farlo perché non ha idea di cosa sia un “cliente”.

L’obiettivo non è il blocco massimo. L’obiettivo è minimizzare i falsi positivi con la sicurezza consapevole del contesto perché l’errore di sicurezza più costoso è il blocco di un checkout legittimo o il blocco di un utente reale.

L’AI ha cambiato drasticamente l’economia degli abusi, dalle scraping dei bot e dalle iscrizioni spam ai sfruttamenti automatizzati delle API. Quali tipi di attacchi stai vedendo più spesso in produzione oggi e come stanno evolvendo man mano che gli aggressori adottano sistemi AI più avanzati?

I guadagni di produttività dell’AI stanno aiutando anche gli aggressori! Il grande cambiamento è la quantità e la velocità di iterazione: più tentativi di accesso con credenziali, più spam di iscrizione automatizzato, più scraping di bot, più sondaggi di API e “armamento” più rapido di vulnerabilità fresche.

Stiamo anche vedendo gli aggressori eseguire cicli di feedback più stretti: testano le difese, adattano i prompt e i payload, ruotano le infrastrutture e continuano fino a quando non riescono a entrare. Attualmente è tutto questione di velocità piuttosto che di sofisticazione.

Ci sono ancora troppo poche persone che seguono le best practice come l’uso di un gestore di password, la distribuzione dell’autenticazione a due fattori con credenziali resistenti alle truffe come le passkey o le chiavi hardware e l’aggiornamento delle dipendenze. Con il volume degli attacchi in aumento, ciò diventerà sempre più importante.

Una delle maggiori tensioni nella sicurezza è proteggere le applicazioni senza rallentare lo sviluppo. Come sono riuscite le squadre che utilizzano Arcjet a integrare la sicurezza nei loro flussi di lavoro mantenendo cicli di rilascio rapidi?

Arcjet funziona in qualsiasi ambiente, compreso l’ambiente di codifica su un laptop. Ciò significa che gli sviluppatori possono testarlo senza doverlo neanche distribuire in produzione. Questo è un vantaggio significativo perché possono convalidarlo e dimostrare l’integrazione senza aver bisogno di autorizzazioni speciali e senza rischiare di influenzare la produzione. Ciò risolve il classico problema delle squadre di sicurezza che costringono gli sviluppatori ad adottare strumenti che ostacolano la loro capacità di svolgere il loro lavoro.

Arcjet ha guadagnato una prima trazione con prodotti nativi AI e piattaforme di e-commerce. Cosa rende questi ambienti particolarmente vulnerabili agli attacchi automatizzati moderni e perché le difese legacy tendono a non funzionare?

Queste due categorie condividono una somiglianza in cui ogni richiesta abusiva ha un costo diretto.

I prodotti AI pagano per token e inferenza – gli aggressori trasformano il tuo margine nel loro parco giochi attraverso lo scraping, l’automazione e la coltivazione della fascia gratuita. L’e-commerce paga per la frode, le controversie, l’abuso di inventario e l’acquisizione di account. E entrambi sono ipersensibili ai falsi positivi perché il blocco di utenti reali è letteralmente una perdita di entrate.

Le difese legacy proteggono principalmente la larghezza di banda e l’infrastruttura. Gli aggressori moderni prendono di mira la logica aziendale: flussi di iscrizione, flussi di checkout, logica di promo, recupero di account e endpoint API. È per questo che i controlli generici perimetrali e “risolvere con un CAPTCHA” diventano sempre più insufficienti.

Costruire software di sicurezza comporta scelte molto diverse rispetto alla visibilità o al monitoraggio. Cosa ti ha sorpreso di più nello sviluppare un prodotto di sicurezza rispetto alla tua precedente esperienza con gli strumenti di infrastruttura?

Con la visibilità, i clienti si fidano di te per essere disponibile. Con la sicurezza, i clienti si fidano di te per essere sicuri e per non diventare il loro nuovo exploit della catena di fornitura.

Costruire un prodotto di sicurezza significa gestire un’azienda di sicurezza. Utilizziamo framework come SOC 2, minimizziamo le nostre dipendenze da terze parti e trattiamo i laptop degli sviluppatori e l’accesso agli strumenti come asset di produzione. Ciò significa molto monitoraggio e risposte rapide a potenziali problemi.

Man mano che le applicazioni si affidano sempre più ad agenti AI che agiscono per conto degli utenti, come gli sviluppatori dovrebbero ripensare idee come identità, intento e fiducia al livello dell’applicazione?

Gli agenti AI agiscono per gli utenti, l’identità cessa di essere uno stato di login binario e diventa un problema di delega: chi agisce, per conto di chi, con quali autorizzazioni, per quanto tempo e con quali vincoli.

Gli sviluppatori dovrebbero passare alla verifica continua: trattare ogni richiesta come se avesse bisogno di una decisione di fiducia fresca basata sul contesto – storia dell’utente, segnali del dispositivo, comportamento della sessione e rischio dell’azione. “Intento” è dedotto dal comportamento nel tempo, non affermato negli header.

Ciò significa costruire momenti di aumento (verifica, limiti di velocità, attrito) intorno ad azioni ad alto rischio come il reset della password, il checkout e la creazione di token – e rendere quei controlli vivi nel codice, dove l’applicazione può distinguere un cliente fedele da un bot con un cookie rubato.

Guardando avanti, come vedi l’evoluzione della sicurezza consapevole del contesto e nel codice negli anni a venire, man mano che il traffico generato dall’AI continua a crescere?

Gli strumenti perimetrali non scompariranno – ma saranno il filtro grossolano per le cose meglio gestite a livello di rete come gli attacchi DDoS. Le decisioni precise avverranno all’interno dell’app, utilizzando il contesto reale.

Se la sicurezza incorporata diventa il modello standard per le applicazioni moderne, cosa significa ciò per il modo in cui gli sviluppatori testano, distribuiscono e ragionano sulla sicurezza nei sistemi di produzione?

Se la sicurezza incorporata diventa standard, le squadre testeranno gli abusi allo stesso modo in cui testano la correttezza: test di sicurezza dell’unità, simulazioni di attacchi riproducibili e controlli di CI per endpoint a rischio.

Il cambiamento più grande è che gli agenti di codifica AI implementeranno la sicurezza come codice, non come configurazione della dashboard. Gli agenti possono solo proporre, esaminare e convalidare protezioni quando i controlli vivono nel repository: politiche, regole, test e strumentazione. Se il “livello di sicurezza” è un’interfaccia utente web, l’agente non può testare i cambiamenti per spedire in modo sicuro.

Questo è il vero motivo per cui la “sicurezza nel codice” vince – si adatta a come il software moderno (e lo sviluppo assistito da AI) viene effettivamente costruito.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Arcjet.