Se pensavate che l’unico rischio nel fare build di una nuova libreria fosse un crash improvviso di Python o un conflitto di dipendenze che vi tiene svegli fino alle tre di notte, beh, devo comunicarti una brutta notizia.
서서 (Sospesa) tra un caffè e un glitch di sistema, la notizia che arriva da Ars Technica è una vera mazzata per chiunque viva di codice condiviso: un gruppo di hacker chiamato TeamPCP sta lanciando una campagna di inquinamento del codice open source a una scala che non abbiamo mai visto prima. Non si tratta del solito script kiddie che cerca di rompere il server di qualcuno per noia; qui parliamo di attacchi alla software supply chain che hanno colpito direttamente GitHub.
In pratica, stanno facendo ‘poisoning’ del codice. Immaginate di stare lavorando al vostro progetto preferito su Godot, scaricando una dipendenza che sembra innocua, solo per scoprire che dentro c’è un payload che trasforma il vostro PC in un zombie per una botnet. È come se qualcuno entrasse nel vostro laboratorio, scambiasse i vostri fili di rame con fili di plastica scadente e sperasse che il vostro nuovo CNC non prenda fuoco durante la prima lavorazione.
Il problema non è solo la sicurezza, è la fiducia. L’intero ecosistema su cui si regge il mondo moderno — dai server cloud alle macchine che controllano i bracci robotici — si basa sull’idea che se una libreria è popolare e testata, allora è sicura. TeamPCP sta usando questa fiducia contro di noi. È l’ennesima dimostrazione di come la centralizzazione della gestione del codice (grazie mille, GitHub) possa diventare un unico, enorme punto di fallimento.
Per noi che amiamo smanettare, che scarichiamo pacchetti senza leggere ogni singola riga di codice (perché, diciamocelo, chi ha tempo?), questa è una chiamata alle armi. Non significa che dobbiamo smettere di usare l’open source — sarebbe come dire di smettere di usare i componenti elettronici perché qualcuno potrebbe venderti un transistor truccato — ma significa che dobbiamo tornare alle vecchie buone abitudini della vera cultura hacker.
Dobbiamo imparare a fare auditing più severo, a monitorare le checksum come se fossero il tesoro più prezioso e, quando possibile, a isolare i processi critici in sandbox che non abbiano accesso diretto alla vostra rete locale. La comodità delle dipendenze automatiche sta diventando un boomerang. È un momento triste per l’entusiasmo senza filtri, ma è anche un promemoria: nel mondo del software, come nel modellismo 3D, se non controlli la qualità della materia prima, il risultato finale sarà un disastro.
Tenete gli occhi aperti, verificate i commit e, se vedete qualcosa di troppo strano nei vostri repository, non ignoratelo. Il prossimo aggiornamento potrebbe non essere solo un fix per un bug, ma un cavallo di Troia.
Source: A hacker group is poisoning open source code at an unprecedented scale