Non fidarsi è meglio

In tema di scandalo NSA, più che le intercettazioni dei politici interessano le notizie sui cataloghi di vulnerabilità dei dispositivi di uso comune, o quelle sugli elite hacker team a disposizione della National Security Agency.
Quel che stupisce è come raramente ci si domandi quanta responsabilità abbiamo noi programmatori e/o sistemisti per questa totale débâcle sul fronte della sicurezza informatica. Non tutti hanno le capacità o le risorse per produrre analisi raffinatissime su come proteggersi da attacchi che sono al confine dell’esoterico (eppure assolutamente reali), ma è altrettanto chiaro che è finito il tempo in cui il problema della sicurezza era solo una scocciatura da delegare il prima possibile al security team della propria azienda, ammesso che ce ne fosse uno.
Il minimo sindacale per uno sviluppatore è che produca codice scevro da grossolane vulnerabilità. SQL injection, Buffer Overflow, Cross-site Scripting (XSS) e altri classici errori sono facilmente evitabili usando i giusti linguaggi di programmazione o i giusti framework. Ma probabilmente questo non basta. Ken Thompson nel 1984 scriveva:

Non ci si può fidare di codice che non abbiamo interamente creato da soli. (Specialmente codice prodotto da aziende dove lavora gente come me). Non c’è grado di verifica o scrutinio a livello di sorgente che ci proteggerà dall’uso di codice non fidato.

A differenza del 1984, adesso è estremamente facile incorporare migliaia di righe di codice scritte da altri anche per progetti piccoli, e pensare di ispezionare tutto il codice è abbastanza irrealistico. Uno sviluppatore scrupoloso deve però essere il più diffidente possibile.
Prima di tutto usate, quando se ne presenta l’occasione, componenti open source. Se siete fortunati, la comunità degli sviluppatori che contribuisce al codice lo avrà ispezionato per voi, e se non è così potete sempre farlo in prima persona.
Non fidatevi degli artefatti che scaricate e magari includete come dipendenze nel vostro progetto. Si parla troppo poco di cross-build injection ma il rischio è reale. Scrive Mike Perry, uno degli autori di Tor:

Dato il numero di dipendenze presente nei grandi progetti, è impossibile che un qualsiasi quantitativo di sorveglianza globale, censura di rete, isolamento delle macchine o firewalling possa tutelare lo sviluppo di software ampiamente diffuso al punto da prevenire la penetrazione – attraverso una dipendenza – di malware combinato a iniezione di codice, capace di aprirsi la strada nei sistemi di produzione di software critico per il funzionamento dell’economia mondiale. Potrebbe anche essere malware molto semplice: scatta un timer e il computer infettato diventa inservibile.

Per cercare di difendersi da questo tipo di attacco gli sviluppatori di Tor stanno lavorando a un sistema per verificare l’idempotenza delle build, ma nel frattempo quello che tutti possiamo fare è iniziare ad utilizzare le funzionalità di verifica di firma digitale presenti nei tool che usiamo quotidianamente, come Maven, RubyGems o pip.
Lo scandalo NSA sta dimostrando come l’idea dell’esistenza di una grossa organizzazione che ci controlla e invade la nostra privacy non si fondi su una suggestione paranoide ma su basi concrete, e che è giunto il momento di imbracciare le tastiere e rispondere agli attacchi prendendo le dovute precauzioni.