All’inizio degli anni ’80, la tecnologia sembrava aver imparato a curare. Le macchine per la radioterapia erano diventate strumenti di precisione, guidate sempre più dal software. Niente più manopole analogiche, niente più margini d’errore “umani”. Il codice era il nuovo operatore, silenzioso, invisibile, impeccabile.
Ma in quell’evoluzione silenziosa si nascose una fragilità: il Therac-25, una macchina per il trattamento di tumori con radiazioni, uccise almeno sei pazienti a causa di un bug nel software di controllo. Non era un guasto meccanico, né un errore dell’operatore, il vero problema era stato un codice scritto male, testato peggio, e creduto infallibile.
Questa è la storia di bug letali che hanno trasformato per sempre la percezione del rischio nel mondo dell’ingegneria del software.
🧱 BUG ARCHEOLOGY — EPISODIO 19
“L’inferno dei viventi non è qualcosa che sarà: se ce n’è uno, è quello che è già qui”
— Italo Calvino, Le città invisibili
👶 Introduzione per chi parte da zero
Il Therac-25 era un acceleratore lineare per radioterapia, costruito da AECL (Atomic Energy of Canada Limited). Aveva due modalità di trattamento:
- Elettroni a bassa energia, per trattare tumori superficiali
- Fasci di fotoni ad alta energia, per colpire tumori profondi
Il passaggio da una modalità all’altra era gestito dal software, senza blocchi fisici di sicurezza. Ed è proprio lì che si insinuò l’errore.
Esistevano, infatti, delle versioni precedenti chiamate Therac-6 e Therac-20 che funzionavano abbastanza bene e avevano meno problemi di sicurezza questo perché erano più “robuste” e dipendevano maggioramente da sistemi hardware di sicurezza, mentre il Therac-25, per ottimizzare costi e design, si affidava quasi esclusivamente al software, soluzione che si rivelò vulnerabile a errori fatali.
I. Il sintomo: pazienti ustionati dal nulla
Tra il 1985 e il 1987, in diversi ospedali nordamericani, alcuni pazienti ricevettero dosi di radiazione migliaia di volte superiori al normale.
I sintomi furono devastanti: ustioni interne, dolore acuto, danni neurologici, morte. Eppure, i log della macchina non mostravano anomalie. Gli operatori si fidavano della lettura: “tutto normale”.
Solo dopo mesi — e altri incidenti — emerse il pattern. La macchina non aveva sbagliato fisicamente: aveva eseguito male il software, in condizioni rare e non previste.
II. L’origine: un software riutilizzato male
Come ti ho precedentemente accennato, AECL aveva già prodotto Therac-6 e Therac-20, versioni precedenti che usavano blocchi meccanici di sicurezza per impedire emissioni errate. Il Therac-25, più moderno, rimpiazzò parte di quella sicurezza hardware con controlli software.
E qui il primo errore:
- Il codice venne riutilizzato recuperandolo dal Therac-6, dove era supportato da controlli fisici.
- Su Therac-25, quei controlli erano solo software: non era presente nessun interruttore meccanico, nessuna ridondanza.
- Il software era scritto in assembly, difficile da testare, documentato male, e sviluppato senza una metodologia formale.
III. Il bug (tecnico): race condition mortale
Una delle cause principali degli incidenti fu un race condition nel codice che gestiva i comandi dell’operatore.
Se l’operatore inseriva velocemente una sequenza di comandi (es. modificava i parametri prima che la macchina fosse pronta), il software poteva:
- Saltare controlli di sicurezza
- Emettere fasci ad alta energia senza l’attenuazione prevista
- Segnalare comunque “tutto ok” sullo schermo
Nessun errore, nessun avviso comparivano, veniva prodotta solo una dose letale di radiazione.
Che cos’è una “race condition”?
Una race condition (condizione di gara) è un errore che avviene quando due o più operazioni software accedono alle stesse risorse contemporaneamente, e il risultato finale dipende dall’ordine casuale in cui vengono eseguite.
In altre parole: il programma funziona solo se il tempo è perfetto — basta che un’operazione arrivi una frazione di secondo prima o dopo, e tutto cambia.
🧩 Esempio semplificato:
Immagina due infermieri che devono impostare una macchina per la radioterapia:
- il primo regola l’intensità del fascio;
- il secondo avvia subito il trattamento.
Se la macchina non verifica che la prima operazione sia completamente finita prima di iniziare la seconda, può partire con parametri vecchi, o peggio, senza alcuna protezione attiva.
Nel software del Therac-25, qualcosa di simile accadeva a livello di codice: se l’operatore digitava i comandi troppo velocemente, il programma “saltava” un controllo di sicurezza.
👉 Le race condition sono tra i bug più difficili da trovare, perché non si presentano sempre — solo in quelle rare e sfortunate combinazioni di tempo e azioni che, nel caso del Therac-25, fecero la differenza tra cura e catastrofe.
IV. Il contesto: fiducia cieca nel software
Negli anni ’80, il software cominciava ad assumere un ruolo centrale in dispositivi critici. Ma la mentalità era ancora:
“Se funziona, funziona.”
AECL non effettuò test formali, né verifiche indipendenti del codice. La FDA approvò il Therac-25 con minima supervisione, fidandosi della “prova di campo”.
Il risultato fu tragico: i bug non erano solo tecnici, erano organizzativi, culturali, etici.
V. La scoperta: pazienti come debugger
Molti ospedali non segnalarono subito gli incidenti. Le fatalità vennero inizialmente attribuiti ad “errore umano” o a “strane coincidenze”.
Furono familiari delle vittime, medici e un fisico clinico (Michael Swartz) a collegare i casi tra loro. Solo grazie alla loro insistenza emerse un pattern sistemico.
Il software venne infine analizzato — e risultò pieno di bug, condizioni di concorrenza, assenza di fail-safe e assunzioni sbagliate.
Linea temporale di quanto accaduto
VI. Le implicazioni morali e legali
AECL venne citata in giudizio, e risarcì le famiglie. Ma il punto più critico fu:
Chi è responsabile quando il software uccide?
Gli ingegneri non avevano malizia, avevano ignorato le buone pratiche che allora non erano ancora state standardizzate, avevano sottovalutato i test e trattato la sicurezza come un’opzione.
Il caso Therac-25 divenne caso di studio obbligatorio in molte università di ingegneria del software e medicina.
VII. I danni: vite perse, fiducia tradita
Almeno sei pazienti morirono o subirono danni permanenti. Ma i danni indiretti furono:
- Perdita di fiducia nella sicurezza del software medico
- Revisioni globali nei processi di certificazione
- Sviluppo di normative più severe per dispositivi critici (es. FDA, IEC 62304)
VIII. Contromisure: cambiare metodo, non solo codice
Dopo il caso, la comunità imparò:
Tecniche:
- Fail-safe hardware obbligatori anche se il software è affidabile
- Test di stress e di race condition
- Logging trasparente e interpretabile
Organizzative:
- Revisione incrociata del codice
- Auditing esterno
- Responsabilità legale e tracciabilità
IX. Lezioni filosofiche: il software come medicina
La storia del Therac-25 ci ricorda che il software può essere chirurgico o mortale.
La linea tra “algoritmo” e “azione fisica” si dissolve nel momento in cui un bit controlla un fascio di radiazioni.
Tre lezioni restano:
- L’invisibile può uccidere — il bug non si vede, ma ha effetti reali.
- L’etica del codice è ingegneria — scrivere software critico è come progettare un ponte.
- La fiducia va progettata, non supposta — ogni sistema critico va pensato per fallire bene, non per funzionare sempre.
X. Epilogo: l’archeologia della negligenza
Il Therac-25 è uno scheletro di silicio, lasciato in fondo alla storia come monito: non sempre chi sbaglia lo fa con dolo; ma anche la buona fede può uccidere, se non accompagnata da metodo, verifica, responsabilità.
L’archeologo del bug, scavando in questa storia, non trova solo linee di codice: trova assunzioni sbagliate, silenzi procedurali, e l’illusione che il software possa essere perfetto.
XI. Coda: il ritorno dei fantasmi digitali
Oggi i bug non vivono più solo nei laboratori o nei vecchi mainframe.
Controllano auto che si guidano da sole, impianti medici connessi alla rete, sistemi di intelligenza artificiale che prendono decisioni cliniche, finanziarie o giudiziarie.
Il fantasma del Therac-25 non è un reperto del passato: è una presenza costante che ci ricorda quanto sia fragile l’equilibrio tra fiducia e controllo.
Ogni nuova tecnologia ripropone la stessa domanda etica, solo su scala più vasta:
Chi vigila sul software che ci cura, ci trasporta, ci giudica?
La vera lezione del Therac-25 non è solo nella tragedia che generò, ma nel monito che continua a ripetersi:
finché esisterà un codice che agisce sul mondo reale, ogni bug sarà anche una questione morale.
🧰 Bug Survival Kit – Therac-25 Edition
📚 Libri consigliati
- Gli errori degli ingegneri. Paradigmi di progettazione di Henry Petroski
In questo saggio, Petroski esplora il valore educativo degli errori nel campo dell’ingegneria, sostenendo che spesso è più istruttivo studiare i fallimenti che i successi. Attraverso una selezione di casi emblematici — dai ponti crollati dell’antichità ai disastri moderni — l’autore illustra come gli errori progettuali possano rivelare debolezze sistemiche e offrire lezioni cruciali per migliorare le pratiche ingegneristiche. Pensato per un pubblico ampio, il libro è utile sia a studenti e professionisti del settore, sia a lettori curiosi di comprendere le dinamiche della progettazione tecnica. - Introduzione all’ingegneria del software. Ediz. MyLab. con Contenuto digitale per accesso online di Ian Sommerville
Un testo fondamentale che copre i principi base dell’ingegneria del software, inclusi metodi di sviluppo, gestione dei progetti e qualità del software. - Sicurezza dei computer e delle reti. Ediz. MyLab. con Contenuto digitale per accesso online di William Stallings
Un manuale completo sulla sicurezza informatica, che esplora le vulnerabilità dei sistemi e le tecniche di protezione. - Fondamenti di Cybersecurity di Giuseppe Nascè
Un testo che introduce ai concetti fondamentali della sicurezza informatica, adatto a chi inizia a esplorare il campo. - Architettura del software. Strutture e qualità di Luca Cabibbo
Esamina le strutture architetturali dei sistemi software e come queste influenzano la qualità e la manutenibilità.
Nota: I link ai libri presenti in questa sezione sono link affiliati ad Amazon. Acquistando tramite questi link ci aiuti a sostenere il progetto senza costi aggiuntivi per te!
🔧 Tool utili
- Valgrind / AddressSanitizer — per rilevare errori a basso livello.
- TLA+ / Alloy — linguaggi formali per verificare sistemi crit