Dopo Mythos: perché i bug bounty hanno bisogno di prove più solide

Qualche settimana fa ho scritto di Anthropic Mythos e Project Glasswing. Allora il punto era soprattutto la linea di fondo: se i modelli diventano davvero migliori nel trovare vecchie vulnerabilità, combinare percorsi di exploit e capire intere codebase, il vulnerability research cambia.

Il nuovo articolo di Sophos sui bug bounty nell’era Mythos mostra ora il lato operativo di tutto questo.

Non si tratta più solo di chiedersi se l’IA trovi vulnerabilità migliori. Si tratta di capire se programmi di bug bounty, team di security e organizzazioni engineering riescano ancora a distinguere abbastanza in fretta tra rumore, affermazioni plausibili e problemi di sicurezza reali.

Il vero problema non è solo lo slop dell’IA

Quando oggi si parla di IA e bug bounty, si pensa subito allo slop: report generati automaticamente, messaggi di errore capiti a metà, catene di exploit inventate, affermazioni non riproducibili e molto testo con poca sostanza.

È reale. Ed è estremamente fastidioso per maintainer, product security team e persone che fanno triage.

Ma è solo un lato.

L’altro è più pericoloso: buoni ricercatori possono usare gli stessi modelli per trovare vulnerabilità reali più rapidamente, testare ipotesi su codebase più grandi e analizzare in modo sistematico varianti di uno stesso pattern. Ciò che prima richiedeva giorni o settimane di lavoro manuale potrà finire in coda nel giro di poche ore.

Il problema quindi si sposta. Prima la domanda era spesso: riceviamo abbastanza finding esterni validi? Oggi diventa piuttosto: sappiamo riconoscere, validare, prioritizzare e trasformare in fix i finding reali abbastanza velocemente, mentre il rumore aumenta?

Perché Sophos è una fonte interessante

L’articolo di Sophos non è un commento generico sull’IA. Sophos guarda al proprio programma di bug bounty e cita numeri concreti.

Secondo Sophos, il programma pubblico è attivo su Bugcrowd da dicembre 2017. Sophos scrive che fino al momento dell’articolo sono state ricompensate 1.343 vulnerabilità, su 7.091 submission totali, per 599.695 dollari di payout complessivo.

Per il 2025 Sophos cita, tra le altre cose:

• 59.400 dollari di payout per più di 52 report
• circa 420 ricercatori coinvolti
• fino a 80.000 dollari per Intercept X Endpoint in determinate condizioni
• fino a 50.000 dollari per Sophos Central
• fino a 50.000 dollari per Sophos Firewall
• 13 bug validi in Sophos Firewall nel 2025, con 21.500 dollari di payout totale
• 13 bug validi in Sophos Central nel 2025, con 11.650 dollari di payout totale

Non sono numeri astronomici, e proprio per questo sono interessanti. Mostrano quanto lavoro di selezione ci sia dietro un programma relativamente maturo. Migliaia di submission non significano automaticamente migliaia di problemi di sicurezza rilevanti. E l’IA probabilmente non renderà questo rapporto più semplice.

Lo renderà più duro.

La riproducibilità diventa il biglietto d’ingresso

La conseguenza più importante, secondo me, è banale ma scomoda: un security report senza una riproducibilità pulita perderà valore.

Non perché i team di triage siano pigri. Ma perché il loro tempo diventerà più scarso.

Se un report sostiene di mostrare una remote code execution, un bypass di autenticazione o una fuga critica di dati, deve documentare in modo pulito:

• quale versione è interessata
• quale configurazione è necessaria
• quali privilegi servono all’attaccante
• quali passaggi portano in modo riproducibile al risultato
• quali log, request, trace o screenshot supportano l’affermazione
• quale impatto è stato effettivamente dimostrato
• dove passa il confine tra ipotesi e prova

Sembra severo. Lo è. Ma sarà necessario se i security team non vogliono annegare in testi plausibili.

Un report generato dall’IA può sembrare linguisticamente molto convincente. Può citare codice, scrivere come una CVE e fingere una struttura ordinata. Questo non lo rende vero. Al contrario, un report breve e asciutto con un buon proof of concept può essere estremamente prezioso.

La nuova valuta non è la formulazione. La nuova valuta è la prova.

L’IA rende particolarmente scomodi i bug di autorizzazione

Un punto dell’articolo di Sophos mi sembra particolarmente pratico: l’IA può aiutare a scalare un bypass di autorizzazione trovato su superfici di scope più ampie.

È coerente con quello che si vede spesso negli ambienti SaaS reali. L’autorizzazione raramente è un singolo interruttore. Vive in ruoli, tenant, object ID, sottodomini, versioni API, superfici admin, endpoint mobili, rotte legacy e funzionalità migrate a metà.

Quando un ricercatore trova un pattern, l’IA può aiutare a controllarne sistematicamente le variazioni:

• Il bypass vale solo per un endpoint o per un’intera famiglia di endpoint?
• Funziona solo in un tenant o anche tra tenant diversi?
• La stessa logica esiste nelle API vecchie e nuove?
• I ruoli admin e user sono davvero separati ovunque?
• Un oggetto può essere caricato tramite ID diretto anche se la UI non lo mostrerebbe?

È esattamente qui che l’IA diventa pericolosamente utile. Non come hacker magico, ma come acceleratore di verifiche noiose, ampie e sistematiche.

Ed è un problema per le organizzazioni la cui sicurezza dipende in gran parte dal fatto che nessuno abbia abbastanza tempo per provare tutte le varianti noiose.

Un bug bounty non è una casella PR

Molte aziende trattano ancora i bug bounty quasi come un tema d’immagine: abbiamo un programma, quindi siamo aperti, moderni e attenti alla sicurezza.

Non basta più.

Un programma di bug bounty è un sistema di produzione. Ha bisogno di regole chiare, buon triage, riproduzione tecnica, vicinanza al prodotto, responsabilità engineering e collegamento con l’incident response. Altrimenti diventa solo una casella pubblica in cui ricercatori esterni, slop dell’IA e attaccanti reali usano lo stesso ingresso.

Sophos mette insieme due punti scomodi:

Primo: i buoni ricercatori aiutano. Uno sguardo esterno, altri modelli mentali e pressione continua hanno valore.

Secondo: un sistema con denaro e fiducia può anche essere abusato. Sophos fa riferimento a esperienze legate a Pacific Rim, Asnarök e Personal Panda, in cui la vicinanza temporale tra sfruttamento attivo e successivi report di bug bounty ha sollevato almeno delle domande. Sophos non dice esplicitamente che ogni report del genere fosse malevolo. Ma il punto operativo resta: un programma di bug bounty non può essere costruito in modo ingenuo.

In concreto significa:

• I report vanno correlati con la telemetria.
• Un nuovo finding dovrebbe poter attivare anche threat hunt retroattive.
• Il triage deve sapere se tentativi di exploit simili erano già visibili.
• La reputazione del ricercatore aiuta, ma non sostituisce la verifica tecnica.
• Il safe harbor è importante, ma non sostituisce il rilevamento degli abusi.

Questa è la realtà sobria: i bug bounty fanno parte del Secure by Design, non lo sostituiscono.

Prove più dure significano anche responsabilità più dure

C’è una tensione che non si può moderare via.

Storicamente ai ricercatori si dice spesso: fermatevi abbastanza presto. Mostrate il bug, ma non andate troppo in profondità. Non toccate dati dei clienti. Nessun movimento laterale. Nessuna azione distruttiva.

È corretto.

Allo stesso tempo, l’onere della prova aumenterà. Se l’IA genera in massa report plausibili ma falsi, i programmi chiederanno più evidenza. Nasce quindi una domanda difficile: come può un ricercatore dimostrare meglio l’impatto senza scivolare in comportamenti pericolosi?

La risposta non può essere: “fate semplicemente di più”. La risposta deve diventare più controllata:

• rules of engagement più chiare
• ambienti di test dedicati
• percorsi di riproduzione sicuri
• limiti concordati per le prove di impatto
• sistemi sandbox e lab migliori
• replay automatizzati dei proof of concept

Per i produttori più grandi diventerà quasi obbligatorio. Chi paga bounty elevati dovrebbe avere anche l’infrastruttura per validare i report in modo pulito e rapido.

Per i progetti più piccoli è più amaro. Ricevono la stessa ondata di slop, ma non le stesse risorse. Proprio per questo alcuni progetti ridurranno i bug bounty finanziari o li spegneranno del tutto. Non perché non prendano sul serio la sicurezza, ma perché gestire il programma diventa di per sé un peso.

Cosa possono imparare admin e MSP

Si potrebbe dire: riguarda solo vendor e programmi Bugcrowd.

Non credo.

Lo stesso meccanismo colpisce anche MSP, team IT interni e responsabili security. Ovunque si debbano valutare finding esterni o interni, la pressione aumenta:

• Gli scanner producono più finding.
• Gli assistenti IA spiegano i finding in modo più convincente.
• Gli sviluppatori portano note di sicurezza generate dall’IA.
• I clienti chiedono delle CVE prima di conoscere il contesto.
• Il management vuole sapere se un rischio è reale o solo rumoroso.

La risposta pratica non è ignorare tutto. È un processo di validazione più duro.

Per me servono almeno queste domande:

1. Il problema è riproducibile?
2. Lo scope interessato è chiaro?
3. Esiste un percorso d’attacco realistico?
4. L’impatto è provato tecnicamente o solo dichiarato?
5. Ci sono log o telemetria che potrebbero mostrare uno sfruttamento?
6. Il fix è una patch, una configurazione, un workaround o solo un cerotto?
7. Serve cercare retroattivamente se è già stato sfruttato?

Sembra più lavoro. Lo è. Ma è lavoro migliore che reagire freneticamente a ogni report scritto bene.

Perché questo si collega bene a Mythos

Il punto decisivo di Mythos, per me, non è mai stato solo: “wow, un modello trova bug”.

Il punto era: se queste capacità diventano più reali, si riduce il tempo tra trovare, capire, riprodurre e sfruttare. È proprio lì che i programmi di bug bounty vengono colpiti. Stanno all’intersezione tra ricerca, potenziale offensivo, engineering e responsabilità.

Sophos lo formula in modo simile nel proprio articolo: la domanda non è come fermare le submission IA. La domanda è come mantenere fiducia e segnale quando sia la buona ricerca sia il rumore possono essere prodotti alla velocità delle macchine.

Per me è la sintesi più pulita del problema.

Non ogni organizzazione ha bisogno di un grande programma di bug bounty. Ma ogni organizzazione ha bisogno di meccanismi migliori per verificare affermazioni tecniche. Perché il flusso di informazioni di sicurezza non diminuirà. Diventerà più rapido, più rumoroso e scritto meglio.

La mia lettura

Considero l’articolo di Sophos un follow-up utile a Mythos, perché sposta il dibattito dalla stanza dei modelli alla stanza operativa.

Mythos è il segnale spettacolare. Il triage dei bug bounty è il banco di lavoro su cui si vede se i processi di security riescono a tenere il passo.

La mia tesi è semplice:

• Chi raccoglie solo più report perderà.
• Chi pretende evidenza riproducibile prioritizzerà meglio.
• Chi collega bug bounty, telemetria, engineering e incident response reagirà più rapidamente.
• Chi vede l’IA solo come generatore di testo ne sottovaluta il valore per il lavoro di security sistematico.
• Chi non filtra lo slop dell’IA brucia il tempo delle persone che dovrebbero risolvere problemi reali.

Suona meno glamour di un modello frontier che trova zero-day. Ma è proprio lì che si decide se il guadagno di sicurezza arriva ai difensori o se tutti affondano in altro rumore.

Alla prossima,
Joe