È da parecchio che affrontiamo la questione relativa ai CVE “dubbiosi” o quantomeno sovrastimati con cui i maintainer dei progetti open-source devono combattere. Un esempio di cui spesso abbiamo raccontato è quello di curl, il cui sviluppatore Daniel Stenberg ha da sempre denunciato i CVE con severity insensate relative ai bug che creano allarmismi inutili ed il cui cammino è culminato nel far diventare il progetto curl una CVE Numbering Authority, così come lo è il progetto Linux stesso.

Ma il problema in questione non è chiaramente limitato ai progetti citati, tutti i maintainer di progetti open-source, prima o dopo, rischiano di doversi scontrare con segnalazioni non veritiere le quali, se i progetti non sono CVE Numbering Authority, rischiano di compromettere la sopravvivenza stessa del progetto.

È il caso di quanto raccontato da Bleeping Computer a proposito del progetto node-ip, conosciuto dagli sviluppatori Node.js semplicemente come “ip” ed scaricato diciassette milioni di volte ogni mese.

Ripetiamo, ogni mese questo progetto, gestito da una singola persona, è scaricato diciassette milioni di volte.

Ora, il suo sviluppatore ed autore, Fedor Indutny, si è trovato costretto ad archiviare il progetto in GitHub in seguito alla pioggia di segnalazioni dovute all’apertura di una CVE, la CVE-2023-42282, giudicata da subito “dubbiosa”.

Il problema è che la semplice esistenza di questa CVE ha provocato uno tsunami, poiché tutti quanti gli sviluppatori Node.js che utilizzano il tool npm audit, il cui scopo è evidenziare se nelle miriadi di dipendenze auto-generate dai pacchetti npm ed incluse nel prezzo ci sono delle problematiche di sicurezza, si sono visti segnalare node-ip come una potenziale minaccia.

Da qui la pioggia di segnalazioni nel repository GitHub del progetto https://github.com/indutny/node-ip ed il messaggio dell’autore su Mastodon che ne annuncia l’archiviazione:

Certo, qualcuno potrebbe giudicare il gesto extrema ratio, ma non va dimenticato come si sta parlando di una singola persona, che dedica il proprio tempo alla gestione di un pacchetto usato ovunque, la quale magari non ha tempo per chiudere decine di segnalazioni inutili ogni giorno.

La speranza è che anche questa storia faccia riflettere e consenta di revisionare le modalità con cui una CVE possa essere considerata CRITICAL (questa era 9.8, praticamente l’apocalisse), senza in effetti esserlo.

Anche perché, per quanto piccolo sia il progetto in questione, si ritorna sempre qui:

E chissà quanti altri sono nella stessa condizione.