Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





SDLC agile e sicuro - Best practice

23/10/20 CoreTech Blog

I processi di sviluppo agili aiutano le aziende a rilasciare software molto più rapidamente di quanto sarebbe possibile utilizzando cicli di progettazione e sviluppo classici come quelli basati sul modello a cascata. La maggior parte delle applicazioni web richiede una metodologia agile perché devono essere aggiornate molto spesso e molto rapidamente per soddisfare le esigenze dei clienti.

Tuttavia, molte aziende hanno difficoltà a includere la sicurezza nel ciclo di vita dello sviluppo del software. Per questo motivo, i test di sicurezza delle applicazioni possono diventare un grave collo di bottiglia e minare completamente gli sforzi investiti in pratiche agili.

Diamo un'occhiata ad alcune best practice SLDC sicure che aiuteranno i tuoi team di sviluppo a diventare veramente agili.

Chiudi il Team Gap

La maggior parte delle aziende che sviluppano le proprie applicazioni web hanno team di sviluppo software e team di sicurezza separati. Questi team collaborano attraverso i problemi presentati e, possibilmente, con l'aiuto dei project manager. Tuttavia, raramente ci sono contatti diretti o cooperazione.

Se i test di sicurezza vengono eseguiti al di fuori del ciclo agile, nelle fasi finali di distribuzione (ad esempio, la gestione temporanea), anche questo porta a tensioni. I team di sicurezza potrebbero riscontrare problemi di blocco appena prima di un rilascio pianificato, il che potrebbe causare ritardi imprevisti e esercitare molta pressione sugli sviluppatori per risolvere rapidamente tali problemi. A volte, questo può persino portare all'ostilità tra i team e mettere a repentaglio l'intero progetto.

La best practice più importante per le metodologie di sviluppo agili è quindi quella di colmare il divario tra team di sviluppo e team di sicurezza. Sebbene l'azienda abbia bisogno di un team di sicurezza dedicato per sviluppare policy di sicurezza e gestire i problemi di sicurezza al di fuori dell'SDLC, i team agili dovrebbero anche (idealmente) includere esperti di sicurezza.

Ad esempio, in molte aziende che seguono le metodologie Scrum, un team agile include non solo sviluppatori e stakeholder aziendali, ma anche scrittori tecnici e analisti dell'esperienza utente. Pertanto, non vi è alcun motivo per cui tali team non dovrebbero includere anche un esperto di sicurezza.

Rendi la sicurezza parte della qualità del codice

Gli sviluppatori di software dovrebbero sapere come garantire la qualità del codice sorgente. È prassi comune che ogni pezzo di codice scritto o modificato venga sottoposto a revisione da parte di un altro sviluppatore.

Banner

Tuttavia, tale revisione del codice di solito non include la ricerca e l'eliminazione delle vulnerabilità di sicurezza. Questo perché né i creatori del codice né i revisori sono adeguatamente formati per riconoscere tali vulnerabilità e non dispongono di strumenti automatici per riconoscerle.

La consapevolezza della sicurezza deve iniziare qui, con il processo iniziale di creazione del codice. Una vulnerabilità di SQL injection nel codice dovrebbe essere percepita come un errore fondamentale, non diverso dall'utilizzo di un algoritmo di bubble sort quando è disponibile l' ordinamento rapido .

Pertanto, la migliore pratica consiste nel far testare a ogni sviluppatore dell'azienda la propria conoscenza delle vulnerabilità della sicurezza che possono essere introdotte nel codice. Se si riscontrano carenze in questo senso, dovrebbero ricevere una formazione specialistica per insegnare loro a riconoscere ed evitare potenziali vulnerabilità, nonché a correggerle nel codice di altre persone. I processi di reclutamento che implicano un test delle capacità dello sviluppatore di scrivere software di qualità dovrebbero anche testare la conoscenza delle vulnerabilità della sicurezza.

Nessuna applicazione lasciata indietro

Le grandi organizzazioni gestiscono spesso migliaia di diversi progetti di sviluppo contemporaneamente. Questi grandi progetti sono realizzati da diverse unità organizzative, spesso in diversi paesi. In tali ambienti, è normale che i team DevOps lavorino in modo indipendente e c'è poco spazio per un modello SDLC unificato. Ciò porta alcuni team ad adottare pratiche sicure per l'intero ciclo di vita dello sviluppo del software, mentre altri rilasciano le proprie applicazioni senza alcun test di sicurezza, lasciando alcune applicazioni gravemente vulnerabili.

Anche se un'organizzazione desidera unificare globalmente l'intero processo di sviluppo, test e distribuzione delle applicazioni, è spesso ostacolata dalle differenze negli approcci adottati da determinati team. Ad esempio, le applicazioni possono essere scritte utilizzando linguaggi, framework e IDE completamente diversi e gestite utilizzando diversi CI / CD e strumenti di rilevamento dei problemi. Un team in un paese potrebbe sviluppare applicazioni in Java utilizzando Jira e Jenkins, mentre un altro potrebbe programmare in PHP e utilizzare GitHub sia per il monitoraggio dei problemi che per CI / CD.

In tali condizioni, l'introduzione di test di sicurezza comuni e automatizzati nella fase di test dell'SDLC può essere molto difficile. Non solo ciò richiede diversi approcci diversi, ma se l'organizzazione desidera utilizzare SAST e SCA, potrebbe essere semplicemente impossibile utilizzare gli stessi strumenti per ogni team. Ciò, a sua volta, richiede flussi di lavoro di gestione separati, introducendo ancora più potenziali problemi.

L'unica soluzione praticabile in questi casi è utilizzare il test dinamico della sicurezza delle applicazioni (DAST), indipendente dalla lingua e facile da integrare nelle pipeline CI / CD. Questo è il motivo per cui ti consigliamo di iniziare i tuoi sforzi SDLC sicuri da DAST, non da SAST o SCA. E quando scegli la tua soluzione DAST, assicurati di sceglierne una progettata per essere inclusa nell'SDLC.


Articoli su Acunetix

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!