AppSec Governance: integrare la sicurezza nello sviluppo

La sicurezza applicativa è stata, per lungo tempo, un aspetto non sufficientemente gestito: il software era sviluppato, testato nelle funzionalità e, poco prima del rilascio, sottoposto a una verifica di sicurezza. Inoltre, in caso di problemi gravi, il rilascio era ritardato e i costi di correzione salivano.

Oggi, questo modello non regge più. I cicli di rilascio sono rapidi, le applicazioni dipendono da decine di librerie esterne e le interfacce esposte su Internet sono il primo bersaglio degli attaccanti.

A ciò si aggiunge la pressione normativa. Direttive e regolamenti europei come NIS2 (Network and Information Security Directive), CRA (Cyber Resilience Act) e DORA (Digital Operational Resilience Act) chiedono di dimostrare che la sicurezza è presente lungo tutto il ciclo di sviluppo, con processi documentati e prove verificabili.

La AppSec Governance (Application Security Governance) risponde a queste esigenze. Non è uno strumento, ma un insieme di ruoli, regole, controlli e metriche che porta la sicurezza dentro il SDLC, (Software Development Life Cycle).

Cos’e la AppSec Governance e come si integra nei processi software

La AppSec Governance stabilisce le politiche di sviluppo sicuro, assegna le responsabilità tra team di sviluppo, sicurezza e management, fissa i criteri che un software deve rispettare per essere rilasciato e misura, nel tempo, i risultati. Senza ciò, i singoli controlli restano iniziative isolate e dipendono dalla buona volontà dei team.

Inoltre, è doveroso evidenziare che la validazione del codice sorgente, prima del rilascio in produzione, contribuisce in modo diretto alla sicurezza infrastrutture ibride, riducendo le vulnerabilità applicative esposte sui canali pubblici.

Ancora, per rendere questa validazione sistematica, i controlli vanno inseriti nella pipeline di sviluppo e non lasciati alla discrezione dei singoli.

Come spostare le verifiche di sicurezza a sinistra nella pipeline CI CD

È importante evidenziare che, più tardi si scopre una vulnerabilità, più costa correggerla. Un difetto trovato mentre lo sviluppatore scrive il codice si risolve in pochi minuti, mentre se lo stesso è scoperto in produzione, richiede analisi, correzione urgente, nuovo rilascio e, nel peggiore dei casi, la gestione di un incidente.

Il principio dello shift left nasce da qui: anticipare i controlli di sicurezza alle prime fasi del ciclo di sviluppo, cioè, a “sinistra”, sulla linea del tempo che va dalla scrittura del codice al rilascio.

Lo strumento per attuarlo è la pipeline CI/CD (Continuous Integration/Continuous Delivery), i.e. il processo automatico che a ogni modifica compila il software, lo testa e lo prepara alla distribuzione. Ne consegue che, inserire i controlli di sicurezza in questo flusso li rende sistematici, attivandoli a ogni modifica. DI seguito una per comprendere meglio come i controlli si distribuiscono lungo tutto il percorso.

Inoltre, il quality gate è il meccanismo che dà forza al modello, ovvero si tratta di una soglia di sicurezza, definita in anticipo che blocca, automaticamente, il passaggio alla fase successiva, qualora emergessero vulnerabilità oltre il livello accettato.

È importante ricordare che, affinché lo shift left funzioni, e non diventi un ostacolo per gli sviluppatori, devono rispettare alcune caratteristiche, quali:

• Velocità – I controlli devono concludersi in tempi compatibili con il lavoro quotidiano, altrimenti i team cercheranno di aggirarli.
• Falsi positivi – Un’analisi, che segnala troppi problemi inesistenti, perde credibilità e viene ignorata.
• Risultati opportunamente disponibili – Le segnalazioni devono comparire negli strumenti che gli sviluppatori già usano, con indicazioni chiare su come correggere.
• Introduzione graduale – Si consiglia di partire da poche regole ad alto impatto – prima in sola segnalazione e poi in modalità bloccante – per evitare di fermare i rilasci fin dal primo giorno.

Tuttavia, anticipare i controlli, di fatto, non elimina quelli successivi. Di fatto, lo shift left sposta l’attenzione verso l’inizio del ciclo, ma i test sull’applicazione in esecuzione e il monitoraggio in produzione sono, comunque necessari per intercettare eventuali problematiche durante il ciclo di sviluppo.

Qual è la differenza tra analisi del codice statica SAST e dinamica DAST

I due approcci sono complementari e intercettano tipologie diverse di problemi.

La SAST (Static Application Security Testing) analizza il codice sorgente, o il codice compilato, senza eseguire l’applicazione ed è in grado di individuare errori di programmazione, uso di funzioni pericolose e credenziali scritte nel codice. Si applica nel ciclo di sviluppo e indica la riga esatta da correggere; tuttavia, può generare falsi positivi, oltre a non rilevare i problemi che dipendono dall’ambiente di esecuzione.

La DAST (Dynamic Application Security Testing) testa l’applicazione in esecuzione, dall’esterno, simulando il comportamento di un attaccante, oltre a rilevare difetti di configurazione, problemi di autenticazione e vulnerabilità che emergono solo a runtime. Non richiede l’accesso al codice, ma interviene più tardi e non indica dove correggere.

Come gestire le vulnerabilità applicative nei software aziendali

Rilevare una vulnerabilità non è sufficiente. È importante, altresì, è capire in quali applicazioni compare e quanto è pericolosa, per poi decidere in che ordine intervenire: nessun team può correggere tutto subito.

Due strumenti rendono possibile tutto questo: un inventario aggiornato dei componenti e un metodo per stabilire le priorità in base al rischio.

Come strutturare la Software Bill of Materials (SBOM) per le librerie terze

Gran parte del codice di un’applicazione moderna non viene scritta dall’azienda, ma proviene da librerie e componenti open source o commerciali. La SBOM (Software Bill of Materials) è l’inventario dettagliato di questi componenti, simile all’elenco degli ingredienti riportato su un prodotto alimentare.

Quando viene scoperta una vulnerabilità in una libreria molto diffusa, la SBOM permette di individuare in pochi minuti quali applicazioni sono coinvolte.

Perché l’inventario sia davvero utile, e non resti un documento archiviato, deve:

• Essere generato in automatico a ogni build, integrando gli strumenti nella pipeline, invece di compilarla a mano;
• adottare formati standard, come CycloneDX o SPDX (Software Package Data Exchange), leggibili da strumenti diversi;
• includere anche le dipendenze indirette, cioè le librerie richiamate da altre librerie, dove si nascondono molti rischi;
• fornire informazioni per ogni componente in termini di nome, versione, licenza, origine e identificativo univoco;
• essere collegato a un archivio di vulnerabilità note, come i database CVE (Common Vulnerabilities and Exposures), per ricevere un avviso quando un componente diventa a rischio;
• conservare le versioni associate a ciascun rilascio, per ricostruire con precisione cosa era in produzione in una determinata data.

Come prioritizzare la correzione del codice in base al livello di rischio

Nessuna azienda riesce a correggere subito tutte le vulnerabilità rilevate. Pertanto, per stabilire le priorità, è utile considerare più aspetti, quali:

• Gravità tecnica (punteggio CVSS – Common Vulnerability Scoring System).
• Sfruttabilità concreta – Esistono exploit pubblici? La falla è già attaccata attivamente? Indicatori come l’EPSS (Exploit Prediction Scoring System) e i cataloghi di vulnerabilità sfruttate aiutano a rispondere.
• Esposizione – Il componente è raggiungibile da Internet o solo dalla rete interna?
• Criticità dei dati e del processo coinvolti.
• Presenza di controlli compensativi, come firewall applicativi o segmentazione di rete.

Tali informazioni permettono di stabilire i livelli di priorità associati a tempi massimi di correzione (SLA di remediation): ad esempio, pochi giorni per le falle critiche sfruttabili e tempi più lunghi per quelle a basso rischio.

Come la sicurezza applicativa riduce la superficie d’attacco esterna

Ogni applicazione web, ogni API e ogni servizio esposto è un punto di ingresso potenziale; pertanto, ridurre la superficie d’attacco, significa avere meno punti esposti e renderli più difficili da sfruttare e, di fatto, la sicurezza applicativa contribuisce a entrambi gli obiettivi.

Come prevenire le vulnerabilità più diffuse nelle interfacce web e API

Le vulnerabilità più comuni sono ben note e raccolte da progetti come l’OWASP (Open Web Application Security Project), che pubblica le classifiche OWASP Top 10 per le applicazioni web e per le API. Per la gestione delle vulnerabilità è necessario garantire:

• controllo degli accessi: verificare a ogni richiesta che l’utente sia autorizzato a quella risorsa specifica, per evitare che modificando un identificativo si acceda ai dati altrui;
• validazione degli input: trattare come non attendibile ogni dato in ingresso e usare query parametrizzate per prevenire la SQL injection e altre forme di iniezione;
• autenticazione robusta: autenticazione a più fattori (MFA, Multi-Factor Authentication), gestione sicura delle sessioni e dei token;
• protezione dei dati: cifratura in transito con TLS (Transport Layer Security) e a riposo, senza esporre nelle risposte più informazioni del necessario;
• configurazione sicura: disattivare funzioni e servizi inutili, gestire i segreti fuori dal codice, impostare intestazioni di sicurezza HTTP;
• gestione delle API: inventario completo delle interfacce, comprese quelle dimenticate o non documentate, limiti sul numero di richieste (rate limiting) e controllo delle versioni obsolete;
• protezione perimetrale: un WAF (Web Application Firewall) e un API gateway riducono il rischio, ma non sostituiscono la correzione del codice.

Inoltre, è importante evidenziare che la formazione dei team è quanto mai strategica: sviluppatori che conoscono i rischi tipici scrivono codice più sicuro fin dall’inizio.

Ancora, molti programmi prevedono figure di riferimento per la sicurezza all’interno di ogni squadra, .e. i cosiddetti security champions.

Come dimostrare la compliance dello sviluppo software agli auditor esterni

Gli auditor non si accontentano di sapere che i controlli esistono, richiedono di dimostrare che essi siano applicati in modo coerente e verificabile. Le evidenze più richieste durante gli audit sono:

• politiche e procedure di sviluppo sicuro, approvate e aggiornate;
• report delle scansioni SAST, DAST e SCA, con date, esiti e azioni conseguenti;
• registri dei quality gate, che documentano i rilasci bloccati o approvati e le relative motivazioni;
• SBOM associate a ciascun rilascio;
• tracciamento delle vulnerabilità dalla scoperta alla chiusura, con tempi misurati rispetto agli SLA di correzione;
• registro delle eccezioni, con approvazioni e scadenze;
• evidenze di formazione dei team di sviluppo;
• esiti dei penetration test periodici e relative correzioni.

Tali evidenze, di fatto, consentono all’organizzazione di dimostrare il rispetto dei principali requisiti di compliance normativa applicabili al proprio settore e al proprio perimetro operativo.

Conclusione

La sicurezza del software non si aggiunge alla fine del processo di sviluppo: si costruisce lungo tutto il ciclo di vita.

Inoltre, integrare la sicurezza nello sviluppo significa trasformare regole, controlli e responsabilità in un processo continuo, dalla prima riga di codice fino alla produzione e alla dimostrazione della compliance.

L’integrazione dello shift left nella pipeline CI/CD – insieme all’uso coordinato di SAST e DAST, SBOM aggiornata e prioritizzazione basata sul rischio – permette di individuare le vulnerabilità prima del rilascio e concentrare gli interventi sulle esposizioni più rilevanti.

Ancora, lo stesso processo può produrre le evidenze necessarie per la compliace al quadro normativo di cyber sicurezza e agli standard di settore, trasformando la compliance da adempimento documentale in un risultato concreto: meno vulnerabilità, minore superficie d’attacco e maggiore capacità di dimostrare l’efficacia dei controlli a clienti, auditor e stakeholder.

Si consiglia alle organizzazioni di iniziare il percorso di sicurezza del codice in modo progressivo: scegliere un’applicazione critica; introdurre nella pipeline i primi controlli automatici con quality gate, inizialmente in modalità di sola segnalazione; misurare quante vulnerabilità vengono intercettate prima del rilascio.

In parallelo, occorre mappare, altresì, gli obblighi normativi applicabili e verificare quali evidenze la pipeline è già in grado di produrre.

È da questi risultati che nasce una base misurabile per estendere, progressivamente, il modello all’intero portafoglio applicativo, integrando sicurezza, sviluppo e compliance in un unico processo.