Lavorare per una banca significa accettare regole più severe di quelle a cui è abituato un normale progetto software. È proprio da qui che è partita una scelta che oggi stiamo estendendo a tutto il nostro lavoro: in occasione di un progetto nell'ambito bancario abbiamo implementato una pipeline di verifica automatica della sicurezza informatica, che a ogni modifica del codice controlla il software da più angoli e produce un rapporto consultabile anche dal cliente.

Non è un controllo che si fa una volta e si archivia. È un insieme di verifiche che girano da sole, ogni volta che qualcuno tocca il codice, e che man mano stiamo portando anche sugli altri software che sviluppiamo.

Perché in banca l'asticella si alza

Un istituto di credito deve rispettare standard molto rigidi, sia su dove possono transitare i dati sia su come viene scritto e rilasciato il codice. In un contesto così, affidarsi a un controllo manuale a fine progetto non basta: le vulnerabilità nascono durante lo sviluppo, spesso da una libreria non aggiornata o da una configurazione dimenticata, e vanno intercettate nel momento in cui compaiono.

Per questo abbiamo spostato i controlli dentro il processo di sviluppo. Ogni modifica al codice attraversa una serie di stazioni di verifica prima di poter arrivare in ambiente di collaudo o in produzione, e se una stazione segnala un problema grave, il rilascio si ferma.

La pipeline è organizzata in sei fasi che si susseguono, ognuna delle quali risponde a una domanda diversa sulla salute del software.

1. Test automatici sul funzionamento

Il primo blocco verifica che il software faccia ancora quello che deve fare. Sono i cosiddetti test unitari, eseguiti separatamente sulla parte server e sull'interfaccia utente, centinaia di piccoli controlli che mettono alla prova le singole funzioni del sistema. Alla fine, la pipeline misura anche quanta parte del codice è effettivamente coperta da questi controlli, un indicatore che ci dice dove il collaudo è solido e dove va rinforzato.

Non è ancora sicurezza in senso stretto, ma è il presupposto: un software di cui non si conosce il comportamento non si può nemmeno mettere in sicurezza.

2. Analisi statica del codice, i test SAST

Qui il codice viene letto e analizzato senza mandarlo in esecuzione, come farebbe un revisore molto pignolo e molto veloce. L'obiettivo è riconoscere schemi di scrittura che notoriamente aprono la porta a un attacco, dati dell'utente usati senza controlli, gestione debole delle autenticazioni, punti in cui un'informazione riservata potrebbe uscire.

Lo stesso tipo di analisi viene applicato anche ai file che descrivono l'infrastruttura, cioè alle configurazioni con cui il software viene installato e messo online. Un permesso troppo largo o una porta aperta per errore sono problemi di sicurezza tanto quanto un errore nel codice, e questa fase li intercetta.

3. La caccia alle credenziali dimenticate

Un controllo dedicato passa al setaccio il progetto in cerca di password, chiavi di accesso e token lasciati per distrazione dentro i file. È uno degli incidenti più banali e più frequenti nello sviluppo software, e uno dei più costosi: una chiave finita per sbaglio in un archivio di codice è una porta d'ingresso già aperta. La pipeline la segnala prima che diventi un problema.

4. Le librerie di terze parti e l'inventario dei componenti

Nessun software moderno è scritto interamente da zero, ma si appoggia a decine di componenti sviluppati da altri. Sono utilissimi, ma portano con sé le loro vulnerabilità, che vengono scoperte e pubblicate nel tempo. Una libreria sicura oggi può diventare un rischio noto la settimana prossima, senza che nessuno abbia toccato una riga di codice.

La pipeline confronta quindi tutti i componenti utilizzati con gli archivi pubblici delle vulnerabilità conosciute e produce due cose: un rapporto leggibile delle criticità trovate, ordinate per gravità, e un inventario completo dei componenti del software, la cosiddetta distinta dei materiali.

5. Il cancello che ferma il rilascio quando serve

Trovare i problemi non serve se poi si rilascia comunque. Per questo la pipeline prevede una soglia esplicita: in presenza di vulnerabilità classificate come alte o critiche il controllo non passa, e la cosa diventa immediatamente visibile a tutto il team. La soglia è configurabile progetto per progetto, così da poterla stringere dove il contesto lo richiede, come appunto in ambito bancario.

Tutti i rapporti prodotti vengono conservati insieme alla versione di codice a cui si riferiscono. Questo significa che per ogni rilascio esiste una fotografia archiviata dello stato di sicurezza in quel momento, un elemento decisivo quando arriva un audit e bisogna dimostrare non solo di aver fatto i controlli, ma quando e con quale esito.

6. Analisi dinamica sull'applicazione in funzione, i test DAST

L'ultima fase cambia prospettiva: non si guarda più il codice, ma l'applicazione realmente installata e funzionante, esattamente come la vedrebbe un attaccante dall'esterno. Uno strumento specializzato si mette in mezzo al traffico, osserva ogni scambio tra browser e server e prova a sollecitare l'applicazione con richieste malevole, cercando le debolezze che emergono solo a sistema acceso.

Il passaggio più delicato è arrivare oltre la schermata di accesso, perché le aree davvero interessanti di un gestionale bancario stanno tutte dietro l'autenticazione. Per questo la navigazione dell'applicazione viene automatizzata con uno strumento di collaudo che esegue un vero accesso e percorre le schermate come farebbe un utente reale, mentre l'analizzatore registra tutto ciò che passa.

Cosa arriva al cliente?

Ogni esecuzione della pipeline produce report dettagliati che consegniamo al cliente, con le eventuali falle classificate per livello di gravità. È una differenza sostanziale rispetto a una rassicurazione a voce: il cliente può verificare in autonomia lo stato di sicurezza del proprio sistema, capire quali criticità sono state chiuse e quando, e portare quella documentazione ai propri uffici di conformità.

Test statici e dinamici di questo tipo, insieme alla loro tracciabilità nel tempo, sono anche un tassello richiesto dai principali schemi di certificazione della sicurezza delle informazioni, come la ISO/IEC 27001.

Da un progetto a uno standard interno

Quello che è nato come risposta ai requisiti di un singolo cliente si è rivelato utile ben oltre il suo perimetro. Le stesse verifiche hanno senso su qualsiasi software che gestisca dati sensibili o processi critici, e il costo di tenerle attive è minimo rispetto al valore di scoprire un problema settimane prima che finisca in produzione.

Per questo stiamo progressivamente estendendo la pipeline agli altri progetti che sviluppiamo, adattando le soglie e i controlli al contesto di ciascuno. L'obiettivo è che la verifica automatica della sicurezza non sia una richiesta a cui rispondere, ma il modo normale in cui lavoriamo.