L'open source ha un problema di cybersecurity e di affidabilità? In parte questa affermazione è sempre vera, perchè la gran parte dei progetti open source è manutenuta da poche persone - a volte anche una sola - e questo li rende automaticamente più vulnerabili. Meno maintainer sono attivi su un progetto, meno possibilità ci sono di scoprire vulnerabilità del codice e risolverle.

La cronaca della cybersecurity ha già ampiamente dimostrato che questo è un problema, peraltro noto e poco affrontato anche da chi sull'open source manutenuto da altri ha costruito il proprio business commerciale. Ecco quindi perchè, quantomeno, sarebbe opportuno semplificare il lavoro dai maintainer e non complicarlo ulteriormente.

In queste settimane il mondo dell'open source sta affrontando la questione di quelli che sono stati definiti gli "slop security report". Letteralmente, i report di sicurezza "minestrone" che sempre più maintainer stanno ricevendo e che vengono generati da tool di sicurezza cyber basati su AI ma, evidentemente, non efficaci.

A quanto sembra, sta aumentando il numero dei ricercatori più o meno esperti di sicurezza che si affidano all'AI per valutare la qualità del codice dei progetti open source con cui hanno in vario modo a che fare. Quando questi tool identificano una vulnerabilità, generano un report di sicurezza che chi ha avviato l'esame del codice invia ai maintainer del progetto in causa.

Il problema è che queste analisi sono spesso sbagliate - la vulnerabilità identificata non esiste - e i report che vengono generati sono una lunga sbrodolata di testo (da cui il termine "slop") che non contiene informazioni davvero utili per identificare e replicare la potenziale vulnerabilità. Capita anche che contenga invece vere e proprie allucinazioni tipiche dell'AI generativa.

Slop report: i casi di rilievo

I casi clou di questi giorni, che hanno dato rilevanza al problema anche al di fuori della stretta cerchia degli addetti ai lavori, hanno riguardato progetti molto noti come CPython, curl, pip e urllib3. E i loro maintainer hanno ritenuto opportuno stigmatizzare la questione, perché quello che accade ai progetti più importanti è un indicatore di quanto può succedere all'open source in generale.

Il caso relativo al progetto curl è sintomatico, perchè non solo la segnalazione del problema - lo ha dettagliato Daniel Stenberg, maintainer del progetto - appare certamente generata da un LLM, ma lo sono anche le risposte del dialogo seguente. Segno che chi ha riportato la potenziale vulnerabilità non ha un vero interesse ad affrontare il problema ma solo ad aumentare il suo numero di report.

Seth Larson, maintainer di vari progetti che fanno capo alla Python Software Foundation, ha chiarito bene perché gli slop report sono un problema: sembrano affidabili anche quando non lo sono, richiedono tempo per essere esaminati in dettaglio, quando si scopre che non sono validi il disappunto è notevole.

"I report di sicurezza che fanno perdere tempo ai maintainer - spiega Larson - generano confusione, stress, frustrazione e, per finire, un senso di isolamento... Tutto questo può contribuire al burnout di collaboratori probabilmente molto fidati di progetti open source. Per molti versi, questi report di bassa qualità dovrebbero essere trattati come se fossero malevoli. Anche se non è questo il loro scopo, il risultato è che i maintainer sono esausti e più restii a svolgere un vero lavoro di cybersecurity".

Va poi ricordato che la gestione dei security report è in effetti una dinamica a tre: i maintainer del progetto, la piattaforma che lo ospita, il security reporter. Questi ultimi due sono incentivati ad aumentare il numero di security report: il reporter appare come un membro attivo e meritevole della community, la piattaforma vede aumentare il suo appeal lato sicurezza. In teoria anche i maintainer ne guadagnano, ma non se i report aumentano esageratamente di numero e perdono di valore.

Risolvere, o quantomeno affrontare, il problema degli slop report richiede quindi la collaborazione di tutti. Anche le piattaforme come GitHub devono assumere un ruolo più critico nei confronti dei reporter che si rivelano inaffidabili o proprio "ostili", permettendo di segnalarli ed eliminando gli incentivi allo spam di report inaffidabili. Meglio affrontare la questione sul nascere che vederla esplodere: il tasso di adozione dell'AI nell'esame del codice è certamente superiore a quello del miglioramento della sua qualità di analisi.