Lo sviluppo di software è una pratica in cui sono impegnate sempre più persone in tutto il mondo. Ci sono sia aziende che individui che creano software, alcuni dei quali proprietari, altri gratuiti o open source e altri sono una fusione dei due. Poiché le minacce alla sicurezza degli utenti o del loro software non si materializzano dal nulla non appena qualcosa viene dichiarato completo e spedito in produzione, sembra il momento giusto per parlare di pratiche di sicurezza che aiuterebbero a gestire i rischi per la sicurezza che potrebbero insinuarsi il software durante il processo di sviluppo. Esistono diversi framework SSDLC (Secure Software Development Life Cycle), inclusi quelli di OWASP, CISAe NIST (SSDF). In questo articolo ne prenderemo in prestito un po' per evidenziare alcune pratiche volte ad aiutarvi a gestire il rischio inerente allo sviluppo del software. Non vivere con un senso di falsa sicurezza pensando che non possa succedere a te. Il report di metà anno sulla sicurezza informatica di Check Point 2023 rivela un picco dell’8% negli attacchi informatici globali nel corso del 2022, e la tendenza non sembra invertirsi.
Cos'è il ciclo di vita dello sviluppo software
Gli sviluppatori di software mirano a creare software in modo rapido, accurato e sicuro. Naturalmente non è sempre possibile ottenerli tutti e tre. Nel corso del tempo, il processo di sviluppo è stato suddiviso in diverse fasi distinte che possono adattarsi a qualsiasi sviluppo software. Queste fasi possono essere suddivise in:
- Analisi dei requisiti – cosa costruiremo e perché
- Pianificazione – come lo costruiremo in termini generali
- Progettazione del software – come lo costruiremo in termini specifici come la progettazione architettonica
- Sviluppo software – scrivere e compilare il software
- Testing – assicurarsi che funzioni come previsto
- Distribuzione – spedirlo o pubblicarlo in modo che l'utente finale possa utilizzarlo
Esistono alcune altre versioni di questo ciclo ma nel complesso sono molto simili. È importante ricordare che il ciclo non è una cosa una tantum: di solito non termina una volta spedito al cliente o pubblicato nel cloud. Ci sono quasi sempre problemi da affrontare che potrebbero richiedere una riprogettazione (tornando al punto di partenza), bug da correggere, funzionalità che si desidera aggiungere e così via. Puoi anche ritrovarti a lavorare su alcune fasi in parallelo o fermarti a metà passo per tornare indietro. Poiché nessuno dei passaggi è intrinsecamente incentrato sulla sicurezza, la sicurezza deve costantemente mettersi al passo con il processo di sviluppo e nelle frenetiche velocità di sviluppo di oggi non è sufficiente.
L'importanza di proteggere il tuo SDLC
Lo sviluppo di software sicuro mira a includere considerazioni sulla sicurezza in tutte le fasi del processo, non trattando la sicurezza come un componente aggiuntivo del processo. In questo modo la sicurezza dovrebbe essere sempre una considerazione, indipendentemente dalla fase del processo in cui sei impegnato: pensare ai requisiti del progetto, pianificare l'architettura, considerare gli elementi costitutivi e l'infrastruttura richiesti e sedersi per sviluppare il codice. Questo approccio è talvolta chiamato sicurezza di spostamento a sinistra approccio.
In questo caso, spostamento a sinistra si riferisce alla distribuzione dei problemi di sicurezza durante il processo di sviluppo e al coinvolgimento degli sviluppatori nella progettazione, implementazione e test della sicurezza.
Può essere intimidatorio per gli sviluppatori che non hanno mai veramente pensato ai problemi di sicurezza doversi improvvisamente occupare di essi. È molto più semplice da gestire se i requisiti sono suddivisi in più buone pratiche ben definite. Puoi pensarlo come prendere un nuovo IDE.
Quanto più ben definiti sono i requisiti e quanti più strumenti automatizzati e completi è possibile utilizzare, tanto più semplici diventeranno le attività.
Migliori pratiche di sicurezza SDLC
Ecco alcune best practice per aiutarti a proteggere il processo di sviluppo senza un ordine particolare:
Training – Molti sviluppatori si sentirebbero incapaci di affrontare il compito di applicare considerazioni di sicurezza e testare il codice che stanno scrivendo. La maggior parte degli sviluppatori è consapevole che lasciare dati di input contaminati nel backend può comportare l'attivazione di codice remoto, proprio come le famose "tabelle di rilascio". Meno persone, tuttavia, avrebbero familiarità con i test di buffer overflow o con la scansione delle vulnerabilità per dipendenze terziarie (o ulteriori). Gli sviluppatori possono colmare queste lacune di conoscenza con l'uso della formazione. Gli sviluppatori sono meglio attrezzati per incorporare i problemi di sicurezza nella codifica e nei test quotidiani quando hanno una comprensione più profonda delle sfide alla sicurezza e delle potenziali vulnerabilità. Inoltre, ha molto più senso che lo sviluppatore che ha scritto il codice e che ha molta familiarità con la sua funzione consideri le lacune di sicurezza e pianifichi i test di conseguenza.
Scansione – Puoi utilizzare molti tipi di scansione per rendere il tuo codice complessivamente più sicuro. L'analisi statica, dinamica e interattiva sono alcune di queste. L'analisi statica cerca evidenti difetti di codifica o possibili vulnerabilità della sicurezza nel codice sorgente. Può essere utilizzato per cercare potenziali vulnerabilità, pratiche di codice non sicure e violazioni degli standard di codifica. Non considera gli eventi di runtime perché esamina solo la sintassi del codice. L'analisi dinamica cerca eventuali difetti di sicurezza, errori di codifica e altri problemi nell'applicazione mentre è in esecuzione. Può essere utilizzato per identificare perdite di memoria, operazioni scadenti e input o processi possibilmente instabili. Tieni presente che, poiché questo tipo di test viene condotto in un determinato momento utilizzando input specifici, la qualità dei test dipende interamente dalle persone che li hanno ideati. L'obiettivo è trovare i problemi prima che lo facciano gli utenti. L'analisi interattiva esamina l'applicazione per individuare eventuali difetti di sicurezza e altri problemi di rottura. Può cercare possibili vulnerabilità, problemi di usabilità e problemi con l'interfaccia utente. Più gli strumenti di scansione sono completi, più sei protetto, ma il compromesso è, ovviamente, nella velocità di sviluppo. Poiché ogni applicazione è unica, spetta a te trovare l'equilibrio tra la giusta quantità di scansioni e la velocità di sviluppo desiderata. Inoltre, ti consigliamo di creare una SBOM completa della tua applicazione e di applicare varie scansioni e report anche a quella fonte di dati. Avere un'eredità SBOM della tua app è un buon modo per conservare informazioni molto dettagliate su componenti e pacchetti che potrebbero rivelarsi preziose per numerosi motivi di sicurezza.
Revisioni del codice – L'esame del codice sorgente per individuare eventuali difetti di sicurezza, errori di codifica e altri difetti del software prima che venga combinato con il ramo di sviluppo attivo è noto come revisione del codice. In genere, questa revisione viene eseguita da uno sviluppatore con maggiore esperienza rispetto a quello che ha creato il codice. Tali revisioni possono aiutare a garantire che il codice sia ben scritto e che l'applicazione sia sicura. Inoltre, supportano il mantenimento di un unico standard e di convenzioni di codifica (come nomi di funzioni e variabili) in tutto il codice base.
Consentire l'integrazione del codice nel ramo principale dopo che almeno due paia di occhi lo hanno esaminato è considerata una buona pratica. Lo sviluppatore che ha creato il codice è, ovviamente, il primo paio di occhi. Può essere utile anche per gli ingegneri altamente qualificati, come i team leader, avere qualcun altro che valuti il loro codice. Per lo meno questo garantisce che più di una persona abbia familiarità con ciascuna sezione del codice. Tieni presente che in momenti di grande stress o in un momento di crisi le persone potrebbero considerare di rinunciare a questo elemento. Se possibile, valuta la possibilità di aggiungere questa regola come elemento hardcoded del tuo CI/CD in modo che non possa essere aggirato.
Testing – Non dobbiamo dirti quanto sia importante testare il tuo codice per scoprire difetti di sicurezza prima che diventino un problema. La maggior parte dei progetti di codice sono complessi e interconnessi, pertanto è impossibile prevedere come una singola, piccola lacuna possa eventualmente avere un impatto sulla sicurezza dell'intera base di codice.
Quando scrivi test automatizzati, prendi in considerazione la funzionalità del codice recentemente prodotto nonché eventuali interazioni significative di back-end e front-end con altre parti della base di codice.
Vulnerabilità come SQL injection, cross-site scripting, archiviazione di dati non sicura e allocazione di memoria inadeguata (che potrebbe causare buffer overflow) sono esempi di problemi di sicurezza che vengono generalmente affrontati durante i test. I test dovrebbero risolvere perdite di memoria, prestazioni lente o inaffidabili e usabilità. Il test dovrebbe essere automatico e integrato nella pipeline CI/CD in modo che nessuna nuova versione o aggiornamento possa essere pubblicato senza essere sottoposto sia ai test unitari che a quelli di integrazione.
Test indipendenti sulla penna – Nessuno può pensare a tutto e come sviluppatori a volte sviluppiamo dei punti ciechi rispetto al codice che abbiamo scritto. Analogamente alla revisione del codice, il pen testing indipendente consente un approccio nuovo e un altro paio di occhi per esaminare criticamente ciò che abbiamo fatto e le precauzioni che abbiamo adottato per proteggere la nostra app e i nostri utenti. Tali test sono consigliati almeno una volta all’anno e dovrebbero includere la valutazione dell’infrastruttura e le vulnerabilità delle app.
Utilizza l'open source in modo sicuro – Quasi tutto il software in fase di sviluppo oggi include software open source in misura maggiore o minore. I componenti open source sono alcune delle principali cause di vulnerabilità importate nella tua applicazione, direttamente o tramite dipendenze temporanee. Inoltre, non sono solo le librerie che utilizzi che possono metterti in pericolo, ma anche il mancato aggiornamento delle vecchie librerie o il mancato aggiornamento con gli ultimi CVE pubblicati che potrebbero avere un impatto su di te. Ti consigliamo di creare un elenco di pacchetti open source approvati per l'utilizzo da parte dell'organizzazione e di controllarlo e aggiornarlo costantemente. Impedire agli sviluppatori di aggiungere qualsiasi pacchetto desiderino, anche solo come test, potrebbe aiutare a ridurre il numero di vulnerabilità da affrontare.
Assicurati che le vulnerabilità non si trasformino in exploit – Non esiste quasi nessuna base di codice priva di vulnerabilità. Qualsiasi scansione decente ne rileverebbe centinaia o migliaia. Eliminarli tutti è impossibile. È anche importante ricordare che le vulnerabilità non sono exploit. Assicurati di disporre di un processo di filtraggio per assicurarti che qualsiasi vulnerabilità scoperta non sia una minaccia sfruttabile e mantieni questo elenco costantemente aggiornato. In questo modo potete rassicurare eventuali terzi o utenti preoccupati per l'ultimo CVE che non ha assolutamente alcun impatto sulla vostra richiesta.
La sicurezza inizia dalla tua mentalità
Probabilmente esistono tanti modi diversi per sviluppare software quanti sono gli sviluppatori, i framework e i linguaggi di codifica. Vale a dire, non è facile trovare le migliori pratiche per proteggere il processo di sviluppo che siano rilevanti indipendentemente dalla lingua, dal campo o dall'IDE che stai utilizzando. Al di là di una miriade di strumenti, alcuni proprietari e altri gratuiti, che richiedono tutti la tua attenzione come "il prossimo strumento di sicurezza insostituibile", lo strumento di sicurezza più importante che puoi utilizzare è la tua mentalità.
Pensa alle tue scelte di design, architettura e archiviazione. Hai considerato l'opzione di una crescita esponenziale della tua base utenti? Hai segmentato correttamente i privilegi di accesso per le diverse parti della tua base di codice e della tua infrastruttura? Hai considerato sia un attacco mirato contro i tuoi dati o segreti, sia un attacco "indiretto" alla catena di fornitura del software?
Tutte queste domande e altre ancora dovrebbero essere prese in considerazione prima ancora di sedersi per pianificare la propria applicazione e dovrebbero essere regolarmente ricontrollate man mano che la base di codice e l'app crescono e si evolvono.
È considerato un assioma che la parte più vulnerabile di qualsiasi software sia l'essere umano che lo esegue (o lo scrive). Non lasciare che la tua applicazione, software o libreria di codici faccia parte delle statistiche crescenti di una nuova ondata di attacchi informatici. Con una pianificazione, strumenti e automazione adeguati puoi trovare il giusto equilibrio tra la gestione del rischio informatico, la protezione del ciclo di vita dello sviluppo e la produzione di codice ben documentato, completo ed efficiente.