Dal 1° ottobre Google ha sospeso le segnalazioni di “Product Vulnerability” nel suo Open Source Software Vulnerability Reward Program. Il motivo riportato è concreto: troppe segnalazioni automatiche non valide stavano consumando il tempo del team di triage. Per chi gestisce plugin WordPress, applicazioni web o automazioni, il punto non è decidere se usare l’AI. È stabilire dove l’automazione deve fermarsi e dove deve iniziare la verifica umana.

Il confronto utile è quindi fra due modelli operativi. Nel primo, l’AI analizza il codice, formula l’ipotesi di vulnerabilità e prepara direttamente la segnalazione. Nel secondo, l’AI trova candidati e raccoglie evidenze, ma una persona riproduce il problema, valuta l’impatto e autorizza l’invio. Il criterio è semplice: quanta sicurezza reale produce ogni ora spesa dal team, non quanti alert riesce a generare.

Perché il volume non misura la sicurezza

Il caso Google rende visibile un costo che nei flussi automatici resta spesso nascosto. Una segnalazione falsa non è gratuita: qualcuno deve leggerla, ricostruire l’ambiente, cercare il percorso di esecuzione e verificare se l’attacco è plausibile. Se l’AI moltiplica i report più velocemente della capacità di verifica, il collo di bottiglia si sposta sul manutentore.

Google aveva già aggiornato le regole dell’OSS VRP il 19 marzo 2026 dopo un aumento di report generati con informazioni errate, allucinazioni o difetti presenti in percorsi non raggiungibili. Per i progetti più critici, una segnalazione di corruzione della memoria deve includere una riproduzione esatta tramite OSS-Fuzz oppure una patch già integrata. L’aggiornamento successivo ha escluso ricompense e riconoscimenti per alcune classi di segnalazione nei progetti di fascia inferiore. La regola ufficiale di Google Bug Hunters premia quindi l’evidenza, non il volume.

Secondo la ricostruzione di Tom’s Hardware, la sospensione del 1° ottobre non riguarda le segnalazioni già inviate né i report sulla supply chain. Google ha indicato che fornirà un aggiornamento entro il primo trimestre del 2027. Non è un rifiuto dell’AI nella sicurezza. È il rifiuto di una pipeline che scarica il proprio costo di verifica sul destinatario.

Approccio A: l’AI produce e invia il report

Il modello AI-first parte da un vantaggio reale: una macchina può analizzare molti file, confrontare pattern, generare input di test e lavorare senza attendere una finestra manuale. In un’agenzia web può controllare ogni notte il codice custom, le dipendenze Composer e npm o le modifiche a un plugin. La copertura cresce e il costo marginale di ogni nuova analisi scende.

Il problema arriva quando l’output dello scanner diventa automaticamente una vulnerabilità. Un crash non dimostra da solo un impatto di sicurezza. Una funzione sospetta può non essere raggiungibile da un utente esterno. Un proof of concept può compilare soltanto nell’ambiente artificiale creato dal modello. Se l’automazione non conosce il modello di minaccia, tende a trattare ogni anomalia come urgente.

  • Pro: grande copertura, esecuzione continua, costo basso per candidato.
  • Contro: falsi positivi, priorità distorte, report duplicati e carico trasferito al triage.
  • Punto di rottura: la coda cresce più velocemente della capacità di riprodurre i casi.

Approccio B: l’AI trova, una persona verifica

Nel modello human-gated l’AI resta dentro la pipeline, ma non firma la conclusione. Il flusso produce un candidato, salva versione del codice, input, log, stack trace e condizioni necessarie. Il revisore prova a riprodurre il difetto in un ambiente pulito, verifica il percorso di attacco e decide la priorità. Solo dopo prepara una disclosure o apre un ticket al manutentore.

Questo modello è più lento per singolo alert, ma riduce il lavoro sprecato a valle. Anche la documentazione di OSS-Fuzz sulla generazione di fuzz target con LLM separa produzione e misura: il target deve compilare, non deve fallire subito per un uso errato delle API e deve aumentare la copertura. Nei test pubblicati, 14 progetti su 31 hanno prodotto nuovi target compilabili con aumento di copertura; il risultato variava da zero al 31%. L’automazione funziona, ma viene giudicata con prove eseguibili.

La stessa logica vale dopo la scoperta. La guida di OSS-Fuzz alla correzione chiede di valutare la gravità rispetto al modello di minaccia del progetto. Una patch proposta dall’AI può ridurre il lavoro, ma il problema deve essere riproducibile e rilevante per il contesto reale.

  • Pro: segnalazioni riproducibili, priorità legate all’impatto, rapporto migliore con i manutentori.
  • Contro: serve competenza, ogni caso richiede tempo e il throughput apparente è più basso.
  • Punto di forza: il costo di verifica resta nel team che genera il report.

Cosa cambia per WordPress, web e automazioni

Per un sito WordPress la scelta non è teorica. Un controllo automatico può segnalare una funzione PHP pericolosa, ma la priorità dipende da chi può raggiungerla, dai nonce, dalle capability e dal percorso di input. Lo stesso vale per una dipendenza JavaScript o per un webhook: trovare il pattern è solo il primo passaggio.

La pipeline minima dovrebbe avere quattro gate. Primo: salvare commit, versione del plugin e ambiente. Secondo: produrre un caso di test ripetibile. Terzo: verificare autenticazione, privilegi richiesti e dati controllabili dall’attaccante. Quarto: far approvare a una persona impatto, severità e testo della segnalazione. Il report finale deve contenere passaggi, risultato atteso, risultato osservato e una proposta di mitigazione.

Questo evita anche due errori frequenti nelle PMI: affidarsi al WAF al posto della patch, oppure copiare segreti e log sensibili nel prompt del modello. Nel primo caso vale la stessa regola già vista per una vulnerabilità di un plugin WordPress: si corregge il codice prima di compensare a valle. Nel secondo conviene tenere le chiavi dietro un proxy, come nel flusso descritto per Codex Cloud e WordPress.

Take finale: automatizzare la scoperta, non il verdetto

La mia scelta è netta: per un team web o una PMI, l’approccio human-gated è quello sostenibile. L’AI deve ampliare la superficie controllata, proporre test e preparare le evidenze. Non deve inviare in autonomia una vulnerabilità a un progetto esterno, né decidere da sola la severità.

Il KPI corretto non è il numero di alert. È la quota di segnalazioni riprodotte, rilevanti e risolte senza rimbalzi. Se una pipeline genera cento ipotesi e nessuna supera un test pulito, non ha trovato cento problemi: ha creato una coda. Automazione AI o verifica umana? La risposta operativa è entrambe, ma in quest’ordine: macchina per cercare, persona per decidere.