Michele PinassiSappiamo bene quanto la sicurezza di un sistema, che sia una infrastruttura o un software, dipenda dal suo “anello” più debole. Quando parliamo di software, ad esempio, le varie componenti di terze parti che ne fanno parte (le librerie) sono un elemento da considerare esattamente come tutti gli altri. Come ci ha insegnato il disastro di Log4j, la libreria di logging per Java usata in migliaia di prodotti software che soffriva di una vulnerabilità critica sfruttabile anche da remoto, il controllo e la verifica della supply chain delle librerie software è un elemento essenziale e critico per chiunque sviluppi prodotti software.
Durante la giornata di ieri a Bologna per HackInBo Winter Edition 2024, un talk di fine mattinata a cura di Denise Nanni e Gabriele D’Angelo dal titolo “Applicazioni mobile: [in]sicurezza e supply chain“, è emerso prepotente questo problema per le “app” che installiamo sui nostri smartphone. La studentessa e il suo relatore, come tesi per la triennale, hanno effettuato una analisi su svariate app disponibili sui vari store per capire quante delle librerie usate soffrano di CVE noti. I risultati sono piuttosto preoccupanti, a cui si unisce la difficoltà di effettuare una analisi certa delle dipendenze a causa delle tecniche di offuscamento introdotte dagli sviluppatori, la mancanza del codice sorgente aperto e la mancanza di un BOM delle librerie usate, completo di versioning, nei pacchetti delle app. Per l’analisi hanno adottato una soluzione empirica analizzando l’indice di similitudine tra le librerie incluse negli apk e quelle disponibili pubblicamente, con CVE noti.
La bulimia che sta investendo il mondo delle applicazioni, ognuna trascinandosi dietro le librerie e i moduli (con il risultato, magari, di avere molte applicazioni che si trascinano dietro la medesima libreria) probabilmente ha già reso esponenziale il problema.
Credo sia evidente che così non può funzionare, soprattutto in un contesto dove l’interdipendenza delle esigenze quotidiane dallo smartphone è sempre più forte (penso ai pagamenti digitali).
Sono convinto che la miopia di credere che un codice chiuso sia più sicuro sta danneggiando non solo il nostro diritto, come utenti di un servizio, di tutelare noi stessi e i nostri dati (una vulnerabilità critica di una app può comprometterli) ma, soprattutto, sta potenzialmente causando un catena di problemi (anche reputazionali) anche alle aziende che hanno commissionato applicazioni non adeguatamente mantenute nel tempo.
Ci troviamo così a utilizzare applicazioni anche critiche (o che comunque trattano informazioni personali anche particolari, come quelle relative a servizi sanitari) di cui non sappiamo con quali componenti sono realizzate, non conosciamo se ci sono criticità nelle componenti di terze parti utilizzate e, forse la cosa peggiore, non ci è data neanche la possibilità di farlo.
La trasparenza è l’unico elemento che può aiutarci a difenderci da tali criticità. Trasparenza nelle componenti di terze parti incluse in un software, complete di versione, credo sia l’unico strumento di difesa davvero efficace per scongiurare queste problematiche. Componenti di terze parti che dovrebbero essere sempre disponibili in forma open source, necessaria per togliere dalle mani degli sviluppatori l’onere di correggere le eventuali problematiche di sicurezza (riducendo la “finestra di vulnerabilità“).
Per finire, come peraltro sottolineato anche dal prof. D’Angelo, la questione non è solo tecnologica. Qualcuno potrebbe infatti giustamente chiedersi come mai gli “store” non implementano misure di analisi preventiva di queste criticità, che probabilmente da un punto di vista procedurale sarebbe più semplice di altre soluzioni. Ma essendo gli “store” una realtà commerciale, l’adozione di misure più stringenti di controllo potrebbe indurre gli sviluppatori a scegliere soluzioni meno severe, causando un danno economico. Un bilanciamento difficile, quindi, al quale temo che sono l’intervento di una realtà normativa superiore (penso alla EU e ai suoi Regolamenti) potrà risolvere.
Come utenti, l’unica strategia di difesa è tentare –quando possibile– di preferire app per le quali vi sia il codice sorgente aperto, dando quantomeno un segnale “politico” chiaro. Per alcune app, come quelle bancarie, dovrebbe essere la nostra pressione di clienti (stakeholders) a pretendere maggiore trasparenza ma, anche per questo, si torna sempre alla questione madre: quanti hanno reale consapevolezza del problema?
Hai trovato utile questo articolo?
