Che cos'è il ciclo di vita dello sviluppo del software sicuro?

Di solito lo sviluppo software segue un percorso lineare tradizionale: pianificare, programmare, testare, implementare. Per decenni, la sicurezza è entrata in gioco solo durante la fase di test, dopo che migliaia di righe di codice erano già state scritte.

SSDLC sfida questo approccio tradizionale incorporando la sicurezza in tutte le fasi del ciclo di vita dello sviluppo software (SDLC) sin dal primo giorno. L'SSDLC è spesso strutturato in nove fasi: requisiti, analisi, pianificazione, progettazione, sviluppo, documentazione, test, implementazione e manutenzione.

I team iniziano discutendo delle problematiche relative alla sicurezza insieme ai requisiti funzionali, mentre gli sviluppatori scrivono codici sicuri usando input convalidati e standard di autenticazione. I test vengono eseguiti costantemente, non solo prima del rilascio, spesso attraverso controlli automatizzati.

Questo approccio "shift left", che sposta la sicurezza in una fase iniziale del processo di sviluppo, può aiutare a trasformare il modo in cui le organizzazioni sviluppano i software. Invece di chiedere "È sicura?" durante i test, i team chiedono: "Come possiamo renderla sicura?" prima di scrivere la prima riga di codice.

Ad esempio, prendiamo in considerazione un'applicazione di banca. Lo sviluppo tradizionale potrebbe rivelare una vulnerabilità di iniezione SQL durante i test precedenti il lancio, il che richiede agli sviluppatori di riscrivere le interazioni del database su centinaia di file. Con un SSDLC, i team hanno molte più probabilità di rilevare eventuali vulnerabilità in anticipo, perché i controlli di sicurezza vengono eseguiti durante la progettazione, lo sviluppo e il test.

Dati recenti aiutano a dimostrare perché questo approccio proattivo è importante. Secondo un recente studio condotto sulla sicurezza della supply chain, gli attacchi alla supply chain del software sono aumentati del 1300% in soli tre anni.¹

SSDLC può aiutare a proteggere le organizzazioni da questi attacchi informatici e da altri tipi di attacchi rilevando in anticipo eventuali vulnerabilità, quando le correzioni sono più semplici e meno costose. Può inoltre contribuire a mantenere la conformità con regolamenti come il Regolamento generale sulla protezione dei dati (GDPR) e l'Health Insurance Portability and Accountability Act (HIPAA).

In genere esistono nove fasi SSDLC, che seguono da vicino il modello SDLC, tranne per il fatto che ogni fase incorpora anche considerazioni di sicurezza:

• Requisiti
• Analisi
• Pianificazione
• Progetta
• Sviluppo
• Documentazione
• Test
• Distribuzione
• Manutenzione

I team discutono le funzionalità del software finito, definendo i requisiti di sicurezza insieme ai requisiti funzionali fin dal primo giorno, ad esempio implementando la crittografia per i campi di dati sensibili e stabilendo il controllo degli accessi basato sui ruoli (RBAC). Questa discussione prevede il controllo dei potenziali rischi per la sicurezza e dei requisiti di conformità come gli standard di protezione dei dati del GDPR.

Le organizzazioni quantificano le potenziali vulnerabilità e mappano il landscape delle minacce, pianificando gli scenari peggiori anziché basarsi sulle ipotesi migliori. Ad esempio, un'app per il settore sanitario potrebbe analizzare i rischi di violazioni dei dati dei pazienti, attacchi ransomware e minacce interne, pianificando le risposte per ogni caso.

I team di sicurezza e gli stakeholder stabiliscono i ruoli, allocano le risorse e definiscono linee di riferimento accettabili in base al potenziale impatto aziendale. Questa pianificazione consente di assegnare priorità alle vulnerabilità ad alto rischio rispettando comunque le scadenze di sviluppo. Inoltre, consente loro di prevedere un budget per gli strumenti di sicurezza e la formazione prima dell'inizio della codifica.

La fase di progettazione prevede la modellazione delle minacce: un'analisi sistematica delle potenziali vulnerabilità della sicurezza nell'architettura pianificata. Questa pratica aiuta a garantire che il design sicuro sia incorporato nel blueprint del sistema, dalla piattaforma migliore all'interfaccia utente ideale, anziché essere aggiunto come un costoso adattamento a posteriori.

Gli sviluppatori applicano pratiche di codifica sicura basate su standard di codifica sicura stabiliti da organizzazioni come l'Open Web Application Security Project (OWASP). Questi standard possono includere la validazione di tutti gli input, l'implementazione di tecniche di autenticazione, l'uso di chiamate API appropriate, la scansione dei repository e la gestione sicura degli errori.

Gli sviluppatori spesso usano ambienti di sviluppo integrati (IDE) con plug-in di sicurezza, che aiutano a individuare i problemi in anticipo.

I team valutano le dipendenze dei software per mitigare i rischi di sicurezza, con i test di sicurezza iniziano durante lo sviluppo. Ad esempio, un modulo di elaborazione dei pagamenti verrebbe sottoposto a test di sicurezza durante lo sviluppo, non dopo l'integrazione.

I team documentano i controlli di sicurezza e i processi per gli audit, i controlli di conformità e di sicurezza, consentendo una rapida risposta agli incidenti e una costante conformità alle normative.

Il testing combina controlli dei codici con test di sicurezza. I team convalidano sia la funzionalità sia la sicurezza prima dell'implementazione.

I test includono analisi statiche, come ad esempio il test statico di sicurezza dell'applicazione (SAST), per analizzare il codice sorgente senza eseguire il programma e il test dinamico di sicurezza dell'applicazione (DAST) per testare le applicazioni durante l'esecuzione.

Test avanzati possono includere hacker etici che testano il codice, penetration test che convalidano la sicurezza dei dati e simulazioni che usano le API. L'analisi della composizione software (SCA) può anche essere eseguita in parallelo per aiutare a individuare eventuali dipendenze open source vulnerabili e problemi di licenza.

I team proteggono l'ambiente di implementazione, server, configurazioni e middleware, prima di rilasciare il software. Questo aiuta a prevenire l'introduzione di vulnerabilità dovute a infrastrutture non configurate correttamente.

Numerosi team raccolgono anche dati di telemetria del software (metriche, log e tracce) per vedere come si comporta il codice in ambienti reali. OpenTelemetry (OTel) è un progetto open-source della Cloud Native Computing Foundation (CNCF) che consente la raccolta e il trasporto indipendenti rispetto ai fornitori di metriche, log e tracce, aiutando così a garantire segnali coerenti tra servizi, pipeline e ambienti.

Il monitoraggio costante può aiutare a individuare precocemente le minacce e le vulnerabilità, consentendo una rapida correzione durante il ciclo di vita del software. Questa fase può essere particolarmente critica per prevenire exploit zero-day e rispondere alle vulnerabilità non appena vengono scoperte.

Le organizzazioni in genere iniziano il ciclo di vita dello sviluppo del software sicuro con dei framework consolidati: metodologie complete che includono benchmark di sicurezza, best practice di sicurezza e strumenti di valutazione del rischio. Alcuni dei framework più comuni includono:

Il National Institute of Standards and Technology fornisce pratiche e benchmark di riferimento supportati dal governo specifici per lo sviluppo sicuro, incluso il Secure Software Development Framework, NIST SP 800-218.

Questo framework aiuta le organizzazioni a stabilire i requisiti di sicurezza di base per tutti i team di sviluppo. Rispetto ad altri framework, fornisce standard federali più prescrittivi, che spesso lo rendono ideale per i contractor del governo e i settori regolamentati. Le organizzazioni che lavorano con le agenzie federali devono spesso rispettare gli standard del NIST come requisito contrattuale.

L'Open Web Application Security Project (OWASP) offre un framework aperto: il Software Assurance Maturity Model (SAMM).

OWASP SAMM aiuta le organizzazioni a valutare le pratiche di sicurezza del software esistenti e a sviluppare programmi di miglioramento iterativi personalizzati in base ai loro specifici profili di rischio.

Per questo motivo, è spesso preferito dalle organizzazioni che cercano approcci flessibili e basati sulla maturità piuttosto che rigidi requisiti di conformità. Ad esempio, una startup può iniziare con pratiche di sicurezza di base in aree critiche come l'autenticazione, per poi espandersi gradualmente verso test di sicurezza completi man mano che il team e il budget crescono.

La Linea guida OWASP DevSecOps spiega in dettaglio l'implementazione della pipeline con strumenti integrati per test di sicurezza: SAST, DAST, SCA (analisi della composizione software) e IAST (test interattivo di sicurezza dell'applicazione). Seguire questa linea guida può facilitare l'integrazione dei test di sicurezza nelle pipeline esistenti di integrazione continua e consegna continua (CI/CD) senza interrompere i workflow di sviluppo.

Di conseguenza, le organizzazioni che vogliono automatizzare la sicurezza senza rallentare i cicli di rilascio potrebbero favorire la Linea Guida OWASP DevSecOps, ad esempio le aziende fintech che implementano aggiornamenti ogni giorno mantenendo la conformità PCI DSS.

Numerose organizzazioni implementano SSDLC attraverso DevOps e pratiche DevSecOps che automatizzano i test di sicurezza e li integrano nelle pipeline CI/CD, accelerando così lo sviluppo mantenendo gli standard di sicurezza. Utilizzando le tecniche DevSecOps, i team di sviluppo sono responsabili della sicurezza delle applicazioni oltre alla progettazione, alla costruzione, alle operazioni e alla manutenzione in sicurezza. Per iterare rapidamente ed evitare colli di bottiglia, usano spesso l'automazione per i test di sicurezza.

SLSA ("salsa") è un framework di community, originariamente proposto da Google e ora sotto OpenSSF, per la salvaguardia delle supply chain del software.

Le sue linee guida aiutano le organizzazioni a prevenire le manomissioni, a verificare l'integrità degli artefatti e ad automatizzare la verifica dei processi di sviluppo e delle dipendenze. Le organizzazioni che desiderano ottimizzare la sicurezza della supply chain e la provenienza della build potrebbero implementare SLSA per dimostrare che il proprio software non è stato manomesso durante il processo di build. Ad esempio, un fornitore di software che distribuisce applicazioni aziendali deve dimostrare ai clienti che le proprie versioni sono autentiche e non manomesse.

SSDLC può offrire alle organizzazioni diversi benefici fondamentali.

L'approccio "shift left" di SSDLC aiuta le organizzazioni a rilevare e correggere eventuali vulnerabilità quando spesso sono più facili e meno costose da affrontare: durante la progettazione e lo sviluppo piuttosto che dopo l'implementazione.

Ad esempio, un controllo in fase di progettazione potrebbe rilevare che un'architettura pianificata esporrebbe dati sensibili dei clienti attraverso un endpoint non sicuro. L'individuazione precoce di questo problema consente un'architettura più sicura fin dall'inizio, evitando un danno potenziale di una violazione dei dati e il costoso adeguamento dei controlli di sicurezza.

Le organizzazioni possono anche notare una riduzione dei costi quando si verifica una violazione. Secondo il report Cost of a Data Breach, un approccio DevSecOps (incluso SSDLC) è stato il fattore numero uno nella riduzione dei costi delle violazioni dei dati. Le organizzazioni che usano questo approccio hanno riscontrato costi inferiori di 227.192 USD per violazione dei dati.

SSDLC può aiutare a prevenire il tempo di inattività del sistema individuando i problemi di sicurezza prima dell'implementazione, evitando potenzialmente correzioni di emergenza e migliorando la stabilità del software. La modellazione delle minacce e i controlli approfonditi dei codici in tutte le fasi possono anch'esse migliorare questa stabilità.

SSDLC aiuta a proteggere la supply chain, che include tutta l'infrastruttura e le persone che entrano a contatto con il codice, dallo sviluppo attraverso la pipeline CI/CD fino all'implementazione. Combina pratiche di gestione del rischio (come la modellazione delle minacce e la scansione delle dipendenze) con i controlli di cybersecurity (come restrizioni di accesso e firma di codice) per prevenire vulnerabilità durante tutto il ciclo di vita.

Ad esempio, SSDLC può aiutare le organizzazioni a implementare le fatture materiali del software (SBOM) per tenere traccia di tutti i componenti e dipendenze. Questo approccio semplifica l'individuazione e la correzione delle vulnerabilità quando vengono scoperte in librerie di terze parti.

SSDLC aiuta le organizzazioni a garantire la conformità, inserendo controlli di sicurezza e documentazione in ogni fase di sviluppo. Questo processo è critico per le organizzazioni che devono rispettare costantemente standard di sicurezza specifici per settore come il Regolamento generale sulla protezione dei dati (GDPR), l'Health Insurance Portability and Accountability Act (HIPAA) e il California Consumer Privacy Act (CCPA). Una conformità più affidabile può contribuire a ridurre i problemi legali e le potenziali multe.

Quando si implementa SSDLC, i team di sviluppo, operazioni e sicurezza spesso devono collaborare a stretto contatto per far emergere numerosi punti di vista nello sviluppo del software. Questa necessaria collaborazione può aiutare a rompere i silos tra i dipartimenti e prevenire problemi di sicurezza che potrebbero diventare costosi in futuro.

Nonostante i suoi numerosi vantaggi, possono sorgere alcune sfide quando le organizzazioni adottano l'SSDLC.

Gli stakeholder che desiderano time-to-market più rapidi possono spesso considerare i requisiti di sicurezza come un ostacolo alla velocità di sviluppo. Potrebbero persino chiedere di rinviare i test di sicurezza a fasi successive.

Sebbene questo approccio possa accelerare lo sviluppo iniziale, spesso porta a ritardi più costosi quando emergono vulnerabilità successive all'implementazione.

Saltare la modellazione delle minacce durante la progettazione, ad esempio, può lasciare esposti i percorsi di attacco critici. Senza un'analisi sistematica delle minacce, i team potrebbero trascurare lacune di sicurezza nei sistemi di autorizzazione, nei controlli di accesso ai dati o nelle integrazioni di servizi di terze parti, vulnerabilità che diventano esponenzialmente più costose da correggere in fase di produzione.

Mentre il landscape delle minacce continua a evolversi, i team di sviluppo devono mantenere le attuali conoscenze sulla sicurezza. Le organizzazioni che non dispongono di competenze specifiche in materia di sicurezza potrebbero aver bisogno di una maggiore formazione, di assunzioni specializzate o di consulenti esterni per implementare efficacemente il SSDLC.

Ad esempio, gli sviluppatori che non conoscono la codifica sicura potrebbero non sapere quando usare strumenti di analisi statica o come interpretarne i risultati. Senza una formazione adeguata, questi strumenti potrebbero segnalare vulnerabilità critiche non affrontate o generare falsi positivi che fanno perdere tempo in fase di sviluppo. Anche gli sviluppatori più esperti hanno spesso bisogno di una formazione costante per rimanere aggiornati in materia di minacce emergenti e pratiche di sicurezza.

Le complesse architetture software con numerose integrazioni talvolta possono richiedere strumenti e processi di sicurezza sofisticati, aumentando potenzialmente i tempi e i costi di sviluppo. Ad esempio, integrare dispositivi IoT che usano formati di dati e protocolli di comunicazione diversi può creare altre superfici di attacco che i team devono mettere in sicurezza.

Considera un'implementazione dell'API della crittografia, in cui l'API deve funzionare con privilegi di accesso minimi supportando vari casi d'uso. Alcuni servizi potrebbero aver bisogno di funzionalità di crittografia senza diritti di decrittografia. Questo processo può richiedere una pianificazione attenta dei controlli di accesso, dell'autenticazione e della sicurezza del livello di trasporto (TLS), aggiungendo complessità attorno a ogni punto di integrazione che i team devono affrontare senza compromettere la sicurezza o la funzionalità.