La trasformazione digitale, o digitalizzazione, del modo di fare business pone al centro dell’attenzione lo sviluppo di applicativi e, quindi, di software. Lo sviluppo di software è infatti uno dei maggiori fattori trainanti della digitalizzazione, dove i beni di consumo sono sempre meno prodotti materiali e sempre di più servizi usufruibili tramite applicazioni scaricabili su mobile (o comunque tramite Internet) e usufruibili da remoto.
Sviluppare, aggiornare e mantenere il software che sta dietro e che rende possibili tutti questi servizi diventa quindi cruciale. Diventa di conseguenza cruciale la sicurezza del software sviluppato. Se pensiamo, ad esempio, alla digitalizzazione della pubblica amministrazione o della sanità, per forza di cose i servizi erogati tramite applicativi dovranno anche avere accesso a dati personali e, molte volte, a dati sia personali che sensibili.
Salvaguardare dunque la sicurezza degli applicativi e del codice sviluppato vuol dire, in ultima battuta, salvaguardare i dati personali e sensibili su cui tali servizi digitali poggiano.
Come possiamo dunque proteggere il software? Che cosa devono considerare gli sviluppatori quando scrivono codice? Di seguito, vedremo tre fondamentali pilastri del così detto secure SDLC, ovvero del software development lifecycle sicuro.
L’evoluzione della minaccia informatica ci insegna come combatterla
Indice degli argomenti
Secure code analysis: strumenti di analisi della sicurezza del codice
Testare il codice è una delle pratiche base per lo sviluppo di software di qualità, dove qui il termine “qualità” viene usato in maniera volutamente generale.
Infatti, si può testare un codice per analizzarne diversi aspetti, come l’aderenza a parametri funzionali, l’operabilità, l’efficienza, la facilità con cui un utente ci interagisca e via dicendo. Per ognuno di questi aspetti, esiste un test o delle pratiche di test volte a misurare esattamente questi parametri.
La sicurezza del codice fa parte di uno di questi aspetti da testare e validare prima che il software venga messo in produzione. E le pratiche di test in questo senso vengono chiamate appunto secure code analysis, ovvero analisi della sicurezza del codice.
Due sono i tipi di secure code analysis: Static Application Security Testing (SAST) e Dynamic Application Security Testing (DAST). SAST è un tipo di analisi del codice che si effettua appunto quando questo è “statico”, ovvero non è in esecuzione.
Si tratta di un tipo di test da effettuare dunque quando si è ancora in fase di sviluppo perché richiede l’accesso al codice sorgente. SAST rientra in quelli che vengono definiti come “white box testing”, test a scatola bianca, perché il modello di attacco è quello di un hacker che ha accesso ad informazioni interne, come appunto l’intero codice sorgente di un applicativo.
Il tipo di vulnerabilità che SAST identifica sono dunque legate alle vulnerabilità introdotte durante la scrittura del codice sorgente, come SQL injections che potrebbero compromettere la disponibilità e l’integrità dell’applicativo.
Al contrario, DAST si concentra sui sistemi in esecuzione e dunque completa quanto apportato di sopra dal SAST.
In particolare, DAST è un tipo di testing che rientra nella metodologia del “black-box” ovvero a scatola nera: in questo caso il modello di attacco è di un hacker che vede l’applicativo dal di fuori, senza quindi accesso alle informazioni di uno sviluppatore.
Per questo motivo, DAST è un tipo di test da eseguire nella fase finale dello sviluppo di un applicativo, quando cioè l’ambiente in cui lo si fa eseguire è similare all’ambiente in produzione.
Le vulnerabilità che il DAST identifica sono ad esempio il cross-site scripting (XSS), che permette ad un attaccante di iniettare del codice che viene poi eseguito dalle vittime.
Esistono vari tipi di soluzioni in commercio che offrono SAST e DAST. Uno tra tutti ad esempio è Checkmarx, che ad esempio permette un’integrazione facile del secure code analysis nella CI/CD pipeline attraverso un servizio in Cloud.
Il Cross-Site Scripting non muore mai: il perché di un evergreen
Third party code tracking: gestire il codice sorgente prodotto da terzi
Una delle pratiche più comuni nel mondo dello sviluppo del software è quella di utilizzare librerie e, in generale, codice prodotti da terzi. Sono molti i motivi per cui un team di sviluppatori di applicativi ricorre a librerie terze, primo tra tutti la pressione di produrre codice il più velocemente possibile. Il risultato è che un’applicazione sviluppata in house, in case, finisce per essere molto spesso un mix di codice sviluppato internamente che integra parti sviluppate esternamente.
Una delle problematiche che l’utilizzo di codice di terzi pone è il fatto che queste librerie possono introdurre delle vulnerabilità che si ripercuotono e si ramificano poi in tutto il resto dell’applicazione. Non è detto infatti che il codice sviluppato da terzi sia stato scritto aderendo agli stessi criteri di sicurezza con cui si sviluppa del software in house. Dobbiamo quindi tenere traccia e gestire queste dipendenze in modo da poterne anche contenere le eventuali vulnerabilità.
Uno degli strumenti principali in questo senso è mantenere un Software Bill of Materials (SBOM), ovvero un inventario di tutte le dipendenze da software di terzi del nostro codice sorgente. Tale inventario contiene tutti i dati relativi alla componente di software non prodotta in house, tra cui nome della componente, nome del soggetto terzo, versione e, ovviamente, il tipo di dipendenza introdotta.
Inoltre, al fine di mitigare ulteriormente le vulnerabilità accidentalmente introdotte da software di terzi, è bene delineare dei requisiti di sicurezza minimi da imporre a possibili nuove librerie da aggiungere allo SBOM. Nel caso in cui tali requisiti non siano soddisfatti, la libreria o il codice in questione non possono pertanto essere integrati nel codice sorgente dell’applicativo.
Secret management: gestione dei segreti
Oltre ai dati personali e sensibili che potrebbero essere usati da un applicativo al fine di erogare un certo servizio all’utente, ci sono anche altri tipi di informazioni la cui diffusione potrebbe comprometterne la sicurezza.
Si tratta dei così detti segreti, come ad esempio password, chiavi e token. Sono sempre di più i “segreti” di questo tipo che vengono generati durante lo sviluppo di software, specialmente per progetti di larga scala.
Infatti, l’utilizzo di microservizi, tooling di sviluppo, container, orchestratori e connessioni API richiedono tutti la generazione e l’utilizzo di segreti, i quali quindi devono essere stoccati e trasmessi quando servono in maniera sicura.
Gli sviluppatori meno consci dei pericoli che il software da loro sviluppato possa introdurre tendono a tralasciare la gestione sicura di questi segreti, che quindi finiscono per rimanere in chiaro in script, configurazioni o addirittura nel codice sorgente.
Tali segreti, invece, dovrebbero essere salvati separatamente rispetto a dove si trova il codice sorgente, ad esempio utilizzando un così detto Vault, ed essere accessibili attraverso pratiche di gestione di accessi privilegiati.
La gestione dei segreti, inoltre, permette la così detta rotazione o refresh degli stessi. Ad esempio, le password possono essere regolarmente cambiate (nello stesso modo in cui si aggiorna la password di accesso alle proprie mail) senza bisogno di cambiare il codice sorgente in tutti i segmenti in cui la password era utilizzata.
Conclusione
I tre pilastri discussi in questo articolo vogliono servire da linee guida per lo sviluppo di software sicuro.
In alcun modo questo articolo si pone come esaustivo rispetto a tutti principi da tenere conto quando si sviluppa software.
In particolare, altri principi legati all’integrazione dell’applicativo nell’infrastruttura IT dell’organizzazione (e meno al codice sorgente in sé e per sé) sono anch’essi da considerare, come il logging and monitoring, la protezione del network e la gestione degli accessi.
