Diventa Autore per CoreTech | Scopri di più





Che cos'è DevSecOps e come dovrebbe funzionare?

07/07/22 CoreTech Blog

DevSecOps sta per sviluppo, sicurezza e operazioni. Simile a DevOps o SecOps, è un concetto che unisce due ruoli precedentemente separati in un ambiente unificato. I team DevSecOps hanno la responsabilità di fornire le condizioni per lo sviluppo continuo di software sicuro.

Banner

Essendo un concetto più recente di DevOps, DevSecOps è stato coniato per sottolineare l'importanza dei processi di sicurezza IT e dell'automazione della sicurezza nel ciclo di vita dello sviluppo del software. Sebbene l'idea di unire i team di sviluppo e i team operativi IT non sia così nuova, fino a qualche tempo fa le policy di sicurezza erano spesso trattate solo come compito dei team di sicurezza. Tuttavia, le crescenti preoccupazioni sulla sicurezza informatica hanno reso necessario chiarire che i controlli di sicurezza sono un aspetto chiave della fornitura continua e che tutti dovrebbero esserne responsabili, non solo i team di sicurezza dedicati.

I presupposti chiave delle pratiche DevSecOps (al contrario delle pratiche DevOps tradizionali) sono:

  • Le pratiche di sicurezza delle informazioni devono essere parte integrante del ciclo di vita dello sviluppo del software e applicate in ogni fase del flusso di lavoro.
  • Tutti i membri del team coinvolti nel processo di sviluppo del software devono assumersi la responsabilità condivisa della sicurezza, non solo i professionisti della sicurezza.
  • I problemi di sicurezza devono essere individuati il ​​prima possibile nel ciclo di sviluppo.
  • I controlli dei rischi per la sicurezza devono essere il più possibile automatizzati per mantenere uno sviluppo agile.

Storia di DevOps e DevSecOps

In passato, lo sviluppo del software seguiva principalmente il modello a cascata. C'è stata una lunga fase di analisi, una lunga fase di progettazione, una lunga fase di sviluppo e infine il software è stato compilato, testato e rilasciato. Per il rilascio della prossima versione, il processo richiederebbe mesi se non anni. Pertanto, non c'era bisogno di automazione e i team lavoravano in silos. Gli sviluppatori compilavano manualmente i programmi, li collegavano, li caricavano in un ambiente di test (di solito un server fisico), il controllo qualità eseguiva suite di test manuali, la sicurezza testava il prodotto finale, ecc.

Oggi viviamo nell'era delle metodologie agili. Ciò significa che i team di sviluppo introducono regolarmente piccole modifiche e le nuove versioni dei prodotti (sia interne che ufficiali) vengono rilasciate su base settimanale o talvolta anche giornaliera. Ciò significa che il software deve essere compilato/costruito, collegato, pubblicato e testato regolarmente. Se ciò dovesse essere fatto manualmente, consumerebbe così tante risorse da rendere impossibile lo sviluppo agile. Per essere agile, devi automatizzare il più possibile i cicli di rilascio.

Questo è il motivo per cui è emersa la necessità di DevOps: soluzioni che consentissero di snellire e automatizzare il più possibile la consegna del software e persone che gestissero l'automazione. Un team DevOps utilizza soluzioni di integrazione continua/distribuzione continua (CI/CD) per creare pipeline di sviluppo. Una pipeline CI/CD implica il prelievo del codice sorgente da un repository come git, la creazione di un ambiente virtuale con le impostazioni corrette (macchina virtuale o container), la creazione dell'applicazione lì, la pubblicazione in quell'ambiente virtuale, l'esecuzione di unit test automatizzati (compreso l'utilizzo di strumenti come Selenium) e fornire il risultato a tutte le parti interessate.

Il problema è che il concetto originale di DevOps non includeva affatto la sicurezza. Le pipeline DevOps contenevano sempre test per verificare se l'applicazione si comportava in base alle aspettative. Tuttavia, di solito non contenevano test per verificare se l'applicazione è sicura e non può essere attaccata. I team di sicurezza (SecOps) lavoravano dopo il rilascio dell'applicazione e spesso verificavano manualmente potenziali vulnerabilità. Se viene rilevata una tale vulnerabilità, la versione dovrebbe tornare spesso allo sviluppatore da un ambiente di staging o (peggiore) di produzione. Questo non era agile e quindi la necessità di integrazione della sicurezza con DevOps, ovvero DevSecOps, a volte chiamato shift-left a causa dell'espansione della sicurezza sul lato sinistro dei diagrammi SDLC.

DevSecOps per applicazioni Web e API

Esistono molti strumenti di sicurezza che aiutano le aziende a mantenere la sicurezza delle applicazioni web. Tuttavia, solo pochissimi di essi possono essere utilizzati come parte di DevSecOps. Questi sono gli strumenti del futuro perché le aspettative del mercato richiedono sempre più automazione e integrazione, quindi DevSecOps è il futuro per tutto lo sviluppo di applicazioni Web, inclusi API, servizi Web, microservizi e altro ancora.

  • I firewall delle applicazioni Web (come ModSecurity open source) sono inutili per DevSecOps. I WAF funzionano monitorando le richieste degli utenti reali e quindi hanno senso solo negli ambienti di produzione. Non aiutano con la risoluzione dei problemi, proteggono solo da problemi che non possono essere risolti in tempo.
  • Gli strumenti di test di penetrazione manuale (Metasploit, Kali Linux, ecc.) sono inutili per DevSecOps perché non sono pensati per essere utilizzati come parte dell'automazione. Sebbene i tester di penetrazione siano indispensabili, non devono essere percepiti come qualcuno che sostituirà il Sec in DevSecOps.
  • I semplici scanner di vulnerabilità web non sono adatti per DevSecOps perché non sono fatti per essere integrati con strumenti CI/CD. Ciò significa che non possono fornire un mezzo adeguato di valutazione della vulnerabilità della sicurezza nelle pipeline.

Le uniche soluzioni considerate strumenti DevSecOps sono gli scanner SAST (test di sicurezza delle applicazioni statiche), DAST (test di sicurezza delle applicazioni dinamiche) e IAST (test interattivo di sicurezza delle applicazioni) di classe enterprise:

  • Gli scanner SAST, noti anche come strumenti di analisi del codice, sono spesso citati come perfetti per DevSecOps, ma non è necessariamente così. Gli scanner SAST presentano diversi svantaggi principali. Segnalano molti falsi positivi e quindi tendono ad essere ignorati dagli sviluppatori con il tempo. Hanno anche lo scopo di proteggere solo il codice e quindi sono completamente indifesi contro le vulnerabilità di sicurezza associate a configurazioni o dati (ad esempio server Web configurati in modo errato o password predefinite). Non verificano la sicurezza di moduli e librerie di terze parti (e la maggior parte dei software oggigiorno si basa pesantemente sulle dipendenze). Infine, sono limitati ad ambienti e linguaggi di sviluppo selezionati.
  • Gli scanner DAST, chiamati anche scanner di vulnerabilità web, devono essere utilizzati successivamente nell'SDLC rispetto agli scanner SAST. Funzionano dopo che l'applicazione è stata creata e distribuita in un ambiente di runtime. Questo è spesso citato come il loro svantaggio, ma in realtà la posizione nella pipeline fa poca differenza per lo sviluppo agile (purché siano inclusi nella pipeline). Gli scanner DAST di classe business includono anche funzionalità integrate per l'integrazione con gli strumenti CI/CD. Il loro principale svantaggio è che non possono mostrare esattamente dove si trova l'errore nel codice sorgente, quindi gli sviluppatori devono trovare gli errori da soli.
  • Gli scanner IAST sono la soluzione migliore per i processi DevSecOps perché presentano i vantaggi di entrambi gli scanner SAST e DAST. Tuttavia, gli scanner IAST possono essere basati su strumenti SAST o strumenti DAST, quindi è importante fare questa distinzione. Uno scanner IAST basato su uno strumento SAST presenta ancora la maggior parte degli svantaggi di tale strumento SAST, sebbene elimini alcuni falsi positivi. Uno scanner IAST basato su uno strumento DAST, tuttavia, elimina il principale svantaggio di DAST rendendolo praticamente lo strumento perfetto per le pipeline DevSecOps.

Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23