High Sierra e IOS11, i due nuovi sistemi operativi di Apple, si portano dietro un pesante carico di incompatibilità con il parco software esistente. Adobe e Microsoft hanno già dichiarato che alcuni loro prodotti devono essere aggiornati, mentre altri (Microsoft Office 2011 per Mac) non verranno resi compatibili con il nuovo sistema operativo. Destino analogo riguarda tantissimi altri programmi che dovranno essere dismessi o acquistati nella loro versione “compatibile” con la “nuova versione”.
Dunque, per gli utenti, la scelta è chiara: continuare ad usare una piattaforma resa artificialmente”vecchia” (e non essere costretti a spendere tempo e soldi per l’upgrade) e trovarsi progressivamente “tagliato fuori”, o mettere mano al portafogli ed “essere protagonista dell’innovazione”.
Fino a quando questa politica – non solo di Apple, per carità – riguarda il mondo della produttività, i danni sono relativamente contenuti. Alla fin fine, si tratta solo di spendere soldi e ore della propria vita dietro download, formattazioni, installazioni, crash, riconfigurazioni e attese per qualche patch.
Ma quando la gestione del ciclo di vita di un software impatta su quello della sicurezza, le cose cambiano drasticamente.
Prendete una struttura minimamente complessa, come potrebbe essere quella di una pubblica amministrazione o a una banca che hanno centinaia di migliaia di apparati, ciascuno con i rispettivi software da configurare, gestire e aggiornare. Vogliamo veramente sostenere che è possibile tenere aggiornata all’ultima patch tutta l’infrastruttura ICT? Al di la del problema delle competenze dei soggetti che si occupano della cosa, è pensabile che in un solo anno si riesca a fare tutto questo? E anche se ci si riuscisse, come si può essere certi che gli aggiornamenti di un sistema operativo o di un software siano più “sicuri” dei predecessori?
La verità è che il “lifecycle management” orientato alla sicurezza ha dei tempi totalmente incompatibili con quelli dell’equivalente gestito da logiche commerciali.
Una gestione orientata alla sicurezza richiederebbe code reviewing, verifica di (in)compatibilità, controllo dell’interazione fra il nuovo “pezzo di codice”, quelli esistenti e lo hardware che li fa funzionare. Ma no ho quasi mai visto nessuno fare sul serio una cosa del genere, anche in contesti industriali.
Mi domando se il Ministero dei trasporti omologherebbe una vettura con una scheda tecnica tipo: “Il mezzo ha le ruote e il motore. I freni li aggiungeremo fra qualche mese, mentre cinture di sicurezza e airbag saranno presenti nel prossimo modello. Nel frattempo, potremmo decidere – ma non lo garantiamo – di ritirare questa versione e sostuirla con una nella quale abbiamo inserito il piantone dello sterzo collassabile e un roll-bar. Ma non prendiamo alcun impegno di installare tutto questo – a nostre spese – sui modelli già venduti.“