I soldi del bounty comprano spazzatura da IA

Stenberg ha tolto i soldi, non le macchine

Daniel Stenberg ha chiuso il bug bounty di curl per ciò che il denaro attirava, non per ciò che scriveva le segnalazioni. Il 31 gennaio 2026 ha posto fine a un programma attivo dall'aprile 2019, che aveva confermato 87 vulnerabilità reali e pagato oltre 100.000 dollari. Il motivo è stato il crollo del tasso di successo. Prima del 2024 più del 15 per cento degli invii si rivelava un problema di sicurezza autentico. Nel corso del 2025 quella quota è scesa sotto il 5 per cento, il che, per usare le sue parole, significava che nemmeno uno su venti era reale. Una squadra di sette volontari passava ore a smontare ciascuna segnalazione, un lavoro che egli ha descritto come un logorio mentale serio.

La sua spiegazione merita una lettura attenta. L'obiettivo principale della chiusura, ha scritto, era togliere l'incentivo a mandare materiale scadente e mal documentato. Vale la pena notare ciò che quella frase non dice. Non nomina alcuna tecnologia e non propone di riconoscerne una. Individua in un pagamento ciò che premiava il lavoro fatto male, e abolisce il pagamento. Il suo criterio per chi segnala è altrettanto indipendente dallo strumento: non si dovrebbe mai segnalare una vulnerabilità se non la si capisce davvero e non la si sa riprodurre.

Il volume è raddoppiato e il tasso di successo è triplicato

Il risultato è andato nella direzione opposta alla previsione ovvia. Smettere di pagare non ha svuotato la coda. Ad aprile 2026, dopo il ritorno di curl alla segnalazione non retribuita, gli invii arrivavano a un ritmo circa doppio rispetto al 2025, e tra il 15 e il 16 per cento veniva confermato come vulnerabilità reale. Il numero di scoperte confermate ha superato il livello del 2024, cioè quello precedente all'ondata.

Il dettaglio più importante suona come una contraddizione. Quasi ogni segnalazione sembrava ancora assistita dall'IA. Ciò che era cambiato è che la maggior parte ormai era buona. La spazzatura non era più un problema, ha riferito Stenberg ad aprile. Lo strumento non è uscito dalla coda. È uscita la spazzatura.

Letto come un problema di controllo, il bounty era un filtro puntato sul bersaglio sbagliato. Un premio in denaro per una scoperta accettata si incassa in funzione del volume di invii moltiplicato per la fortuna, e quindi premia chi manda in fretta e con speranza anziché verificare prima. Quella pressione esisteva già prima dei modelli generativi ed era semplicemente sopportabile; la generazione a basso costo l'ha resa letale. La dimensione del fenomeno si vede anche altrove. Da Bugcrowd il volume delle segnalazioni si è più che quadruplicato in tre settimane a marzo. HackerOne ha registrato fino a marzo un aumento del 76 per cento su base annua degli invii, sebbene su quella piattaforma la quota che segnalava vulnerabilità reali sia rimasta stabile intorno al 25 per cento, il che ridimensiona l'idea che tutte le code siano crollate insieme.

In realtà nessuno ha vietato nulla

L'unico censimento che ha contato davvero ha trovato zero divieti assoluti. Uno studio integrale di 53 programmi di divulgazione, che copriva quattro piattaforme di coordinamento, 20 produttori e 29 progetti open source, è stato consultato il 28 luglio 2026. Nemmeno uno vieta senza condizioni i report di bug scritti con IA. L'affermazione tanto ripetuta secondo cui il settore li avrebbe vietati descrive una regola che nessun programma del campione ha mai messo per iscritto.

La distribuzione reale è meno drammatica e più utile. Trentasei programmi, il 67,9 per cento, non dicono nulla sull'IA nelle policy pubblicate. Sedici, il 30,2 per cento, la disciplinano con condizioni. Di questi sedici, tredici pretendono la verifica umana della scoperta, undici pretendono una riproduzione funzionante, otto rifiutano gli invii puramente autonomi pur continuando ad ammettere l'assistenza dell'IA, e tre pretendono che l'uso dell'IA sia dichiarato: Intigriti, Django e FFmpeg. La verifica umana, non il divieto, è lo standard verso cui tutti convergono.

Il censimento ha trovato anche un difetto da annotare. Tre programmi hanno pubblicato le proprie regole sull'IA in un punto diverso dalla pagina principale della policy. Una condizione che chi segnala non ha mai visto e non ha mai accettato non è opponibile, il che riduce una regola scritta a semplice decorazione. Nemmeno i programmi che hanno cambiato stato hanno vietato alcunché: curl ha chiuso il suo bounty a gennaio 2026, Nextcloud ha sospeso i premi in denaro ad aprile, e l'Internet Bug Bounty ha messo in pausa gli invii.

Apple e GitHub hanno preso di mira la persona

Le linee guida di Apple legano ormai la sanzione alla reputazione di chi segnala, non alla segnalazione. Apple afferma senza giri di parole di ricevere molte segnalazioni che dichiarano di riguardare gravi problemi di sicurezza o riservatezza ma che sono generate da modelli linguistici e inviate senza la prova richiesta né una validazione da parte di una persona. Il rimedio è una sospensione. Se qualcuno invia ripetutamente segnalazioni non ammissibili, comprese quelle irrealizzabili su questioni teoriche o quelle scoperte dall'IA senza adeguata validazione, Apple può sospendere per 180 giorni la lavorazione delle sue segnalazioni. Con più di due periodi di sospensione, quella persona può essere rimossa in modo permanente dal programma.

La seconda metà di quella sanzione è la più tagliente. Durante la sospensione la persona interessata è esclusa non solo dal pagamento ma anche dalla menzione negli avvisi di sicurezza, e per un ricercatore professionista il riconoscimento pubblico è la moneta che dura. I termini di servizio di Apple arrivano allo stesso punto da un'altra strada, vietando uno schema costante, ripetuto o ad alto volume di affermazioni false, come le segnalazioni generate con l'assistenza dell'IA e non validate da una revisione umana. Ciò che conta è quest'ultima parte. La clausola non vieta l'assistenza, vieta di consegnare il risultato senza controllarlo.

GitHub ha scelto l'altra via dell'identità, dividendo il programma in due livelli con effetto dal 27 luglio 2026. I premi pubblici sono scesi a 250 dollari per una scoperta di gravità bassa, 2.000 per una media, 5.000 per una alta e 10.000 per una critica, contro i precedenti 500-1.000, 5.000, 20.000 e 30.000. Gli importi vecchi vivono ora in un livello accessibile su invito che paga 1.000, 7.500, 20.000 e 30.000 dollari o più. Per entrarvi serve una storia dimostrata: una scoperta critica accettata, oppure due alte, oppure quattro medie, oppure sette basse. Chi segnala per la prima volta nel programma pubblico incontra un requisito di segnale con un massimo di quattro invii iniziali per dimostrare il proprio valore. L'obiettivo dichiarato dall'ingegnera della sicurezza di prodotto Catherine Cassell è ridurre il rumore perché la squadra possa concentrarsi sul segnale.

Chi viene frenato può essere proprio chi conta

Il filtro reputazionale ha un costo che nessuno di questi annunci quantifica. Tutti questi meccanismi premiano una storia pregressa, il che è un modo sensato di ordinare chi segnala spesso. Ma la persona che trova un solo difetto critico nel vostro prodotto e non ha mai presentato una segnalazione da nessuna parte è per definizione il profilo del tutto privo di storia, ed è proprio la segnalazione che meno vi conviene frenare. La risposta di GitHub sono quattro invii per accreditare il segnale, quella di Apple è uno stato che può restare congelato per sei mesi. Entrambe sono difendibili, nessuna è gratuita, e il costo ricade esattamente su chi trova qualcosa una volta sola e la cui unica segnalazione potrebbe essere la più preziosa dell'anno.

Per un produttore europeo la questione smette di essere filosofica l'11 settembre 2026, quando iniziano ad applicarsi gli obblighi di notifica del Regolamento sulla ciberresilienza. Il produttore che viene a conoscenza del fatto che una vulnerabilità del suo prodotto è sfruttata attivamente deve avvisare ENISA e il CSIRT nazionale competente entro 24 ore, fornire una valutazione più completa entro 72 ore e presentare una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva. In Italia il riferimento è il CSIRT Italia, presso l'Agenzia per la cybersicurezza nazionale. Il Regolamento richiede inoltre una policy di divulgazione coordinata delle vulnerabilità, cioè una via ordinata attraverso cui qualcuno possa avvertirvi prima che i dettagli diventino pubblici. A leggere con attenzione il termine, il problema della casella di posta diventa un problema di conformità. L'orologio parte dalla conoscenza, e una coda sepolta sotto segnalazioni non validate è una macchina per ritardare proprio quella conoscenza.

Da qui discendono tre conseguenze per chi gestisce quella ricezione. Pretendete una riproduzione funzionante e scrivetelo nella pagina che chi segnala accetta, perché una riproduzione è dimostrabile mentre un'affermazione su quale strumento abbia scritto il testo non lo è. Sistemate l'incentivo prima di scrivere una regola, dato che la coda di curl è migliorata quando è sparito il pagamento, non quando è cambiata una policy. E misurate il tasso di scoperte confermate anziché il numero di segnalazioni, perché il volume è esattamente il dato che è salito nell'unico caso in cui tutto è migliorato. Nulla nel Regolamento sulla ciberresilienza vi obbliga a pagare qualcuno. Vi obbliga a essere raggiungibili e a saper distinguere una segnalazione vera da una plausibile abbastanza in fretta da far partire l'orologio in tempo.

Da leggere ora: Siri AI ha avuto un prezzo prima di una data UE  |  I servizi di Apple sono calati da un trimestre all'altro