Close

Strumenti DevSecOps

Gli strumenti DevSecOps che proteggono i flussi di lavoro DevOps

Foto di Kev Zettler
Kev Zettler

Full Stack Web Developer


Nonostante le lodevoli iniziative delle aziende di software, le violazioni della sicurezza continuano a verificarsi. Dal 2000, circa 3,5 miliardi di persone hanno subito il furto dei dati personali. In parte il problema risiede nel fatto che man mano che aumentano la scalabilità e la complessità delle applicazioni software aumenta anche la superficie esposta a vulnerabilità ed exploit della sicurezza.

Inoltre, poiché sempre più organizzazioni adottano un approccio DevOps, che automatizza e integra i processi tra i team di sviluppo software e IT, gli strumenti di sicurezza tradizionali spesso non sono più adeguati. Oggi gli sviluppatori devono integrare misure di sicurezza in ogni fase del flusso di lavoro di sviluppo. Quando è applicata alla sicurezza dei flussi di lavoro DevOps, questa pratica viene definita DevSecOps.

Che cos'è DevSecOps?


DevSecOps indica la pratica di integrare la sicurezza in una pipeline di continuous integration, continuous delivery e continuous deployment. Incorporando i valori DevOps nella sicurezza software, la verifica della sicurezza diventa una parte attiva e integrata del processo di sviluppo.

Proprio come DevOps, DevSecOps è una metodologia organizzativa e tecnica che combina flussi di lavoro di gestione dei progetti con strumenti IT automatizzati. DevSecOps integra controlli di sicurezza attivi e test di sicurezza nello sviluppo Agile e nei flussi di lavoro DevOps in modo che la sicurezza sia integrata nel prodotto invece di essere applicata a un prodotto finito.

Per implementare DevSecOps, i team devono:

  • Introdurre la sicurezza nel corso dell'intero ciclo di vita dello sviluppo software per ridurre al minimo le vulnerabilità nel codice software.
  • Garantire che l'intero team DevOps, incluso il team di sviluppo e quello operativo, condivida la responsabilità di seguire le best practice di sicurezza.
  • Porre in essere controlli di sicurezza automatizzati in ogni fase della distribuzione del software tramite l'integrazione di controlli, strumenti e processi di sicurezza nel flusso di lavoro DevOps.

Con DevSecOps, la sicurezza dovrebbe essere applicata a ogni fase della tipica pipeline DevOps: pianificazione, codice, build, test, rilascio e distribuzione.

Il concetto di "continuo" è una caratteristica differenziata di una pipeline DevOps. Ciò include continuous integration, continuous delivery/deployment (CI/CD), feedback continuo e operazioni continue. Invece di test eseguiti una tantum o di distribuzioni pianificate, ogni funzione viene eseguita in modo continuativo.

Icona strumenti
materiale correlato

Scopri di più su Snyk per Bitbucket Cloud

Icona del download
scopri la soluzione

Ottieni Snyk per Bitbucket Cloud

Simbolo dell'infinito DevSecOps

Pianifica


La pianificazione è la fase meno automatizzata di DevSecOps perché prevede attività di collaborazione, discussione, revisione e strategia di analisi della sicurezza. I team devono eseguire un'analisi di sicurezza e creare un piano che delinei dove, come e quando verranno eseguiti i test di sicurezza. Uno strumento di pianificazione molto diffuso per DevSecOps è IriusRisk, uno strumento di progettazione collaborativa per la modellazione delle minacce. Altri strumenti includono strumenti di monitoraggio e gestione dei ticket come Jira Software e strumenti di comunicazione e chat come Slack.

Codice


Gli strumenti DevSecOps per la fase di codice aiutano gli sviluppatori a scrivere codice più sicuro. Importanti pratiche di sicurezza in fase di codice includono l'analisi del codice statico, le revisioni del codice e gli hook di pre-commit.

Quando gli strumenti di sicurezza si collegano direttamente al flusso di lavoro Git esistente degli sviluppatori, ogni commit e merge attiva automaticamente un test o una revisione della sicurezza. Questi strumenti supportano diversi linguaggi di programmazione e ambienti di sviluppo integrati. Alcuni degli strumenti di codice di sicurezza più diffusi includono Gerrit, Phabricator, SpotBugs, PMD, CheckStyle e Find Security Bugs.

Compila


La fase di build inizia quando gli sviluppatori eseguono il commit del codice nel repository di origine. Gli strumenti di build di DevSecOps si concentrano sull'analisi automatica della sicurezza rispetto all'artefatto dell'output della build. Importanti pratiche di sicurezza includono l'analisi dei componenti software, i test di sicurezza delle applicazioni statiche (SAST) e i test unitari. Gli strumenti possono essere collegati a una pipeline CI/CD esistente per automatizzare questi test.

Gli sviluppatori installano e compilano regolarmente utilizzando dipendenze di codice di terze parti, che possono provenire da una fonte sconosciuta o non attendibile. Le dipendenze del codice esterno possono includere, accidentalmente o a causa dell’azione di utenti malevoli, vulnerabilità ed exploit. Durante la fase di build, è fondamentale esaminare e analizzare queste dipendenze per cercare eventuali vulnerabilità della sicurezza.

Alcuni strumenti ben noti per eseguire l'analisi della fase di build includono: OWASP Dependency-Check, SonarQube, SourceClear, Retire.js, Checkmarx e Snyk.

Testa


La fase di test viene attivata dopo che un artefatto di build è stato creato e distribuito correttamente in ambienti di staging o test. L'esecuzione di una suite di test completa richiede molto tempo. Questa fase dovrebbe essere sottoposta a fail-fast in modo che le attività di test più costose siano lasciate alla fine.

La fase di test utilizza strumenti di test della sicurezza delle applicazioni dinamiche (DAST) per rilevare flussi di applicazioni live come autenticazione utente, autorizzazione, SQL Injection ed endpoint correlati alle API. I test DAST incentrati sulla sicurezza analizzano un'applicazione rispetto a un elenco di problemi noti di gravità elevata, come quelli elencati nell'OWASP Top 10.

Sono disponibili numerosi strumenti di test open source e a pagamento, che offrono una varietà di funzionalità e supporto per gli ecosistemi linguistici, tra cui BDD Automated Security Tests, JBroFuzz, Boofuzz, OWASP ZAP, Arachni, IBM AppScan, GAUNTLT e SecApps Suite.

Release


Entro la fase di rilascio del ciclo DevSecOps, il codice dell'applicazione e l'eseguibile dovrebbero già essere testati completamente. La fase si incentra sulla protezione dell'infrastruttura dell'ambiente di runtime attraverso l'esame dei valori di configurazione dell'ambiente come il controllo degli accessi degli utenti, l'accesso ai firewall di rete e la gestione dei dati segreti.

Il principio del privilegio minimo (PoLP) è una delle principali preoccupazioni della fase di rilascio. PoLP indica che qualsiasi utente, programma o processo dispone di un privilegio di accesso minimo per svolgere la sua funzione. Ciò comporta il controllo delle chiavi API e dei token di accesso in modo che i responsabili dispongano di accesso limitato. In assenza di questo controllo, un utente malintenzionato potrebbe trovare una chiave per accedere ad aree riservate del sistema.

Gli strumenti di gestione della configurazione rappresentano un ingrediente essenziale per la sicurezza nella fase di rilascio, poiché forniscono visibilità sulla configurazione statica di un'infrastruttura dinamica. La configurazione del sistema può quindi essere verificata e rivista. La configurazione diventa immutabile e può essere aggiornata solo tramite commit in un repository di gestione della configurazione. Alcuni strumenti di gestione della configurazione di ampia diffusione includono Ansible, Puppet, HashiCorp Terraform, Chef e Docker.

La community della sicurezza fornisce linee guida e raccomandazioni sulle best practice per il rafforzamento dell'infrastruttura, come i benchmark CIS (Center for Internet Security) e le checklist di configurazione NIST.

Distribuisci


Se le fasi precedenti vengono superate correttamente, è possibile distribuire in produzione l'artefatto della build. Le aree di sicurezza da affrontare durante la fase di distribuzione sono quelle che si verificano solo nel sistema di produzione live. Ad esempio, eventuali differenze di configurazione tra l'ambiente di produzione e i precedenti ambienti di staging e sviluppo devono essere esaminate in modo approfondito. I certificati TLS e DRM di produzione devono essere convalidati e revisionati per il rinnovo imminente.

La fase di distribuzione è quella ideale per utilizzare strumenti di verifica runtime come Oquery, Falco e Tripwire, che estraggono informazioni da un sistema in esecuzione per stabilire se il funzionamento è quello previsto. Le organizzazioni possono anche eseguire principi di ingegneria del caos sperimentando un sistema per creare fiducia nella capacità del sistema di resistere a condizioni turbolente. È possibile simulare eventi reali, come server che si bloccano, guasti del disco rigido o interruzioni delle connessioni di rete. Netflix è ampiamente noto per il suo strumento Chaos Monkey, che applica i principi dell'ingegneria del caos. Netflix utilizza anche lo strumento Security Monkey che cerca violazioni o vulnerabilità in gruppi di sicurezza dell'infrastruttura configurati in modo errato ed elimina gli eventuali server vulnerabili.

Sicurezza continua


Dopo che un'applicazione viene distribuita e stabilizzata in un ambiente di produzione live, sono necessarie ulteriori misure di sicurezza. Le aziende devono monitorare e osservare l'applicazione live per rilevare eventuali attacchi o perdite con controlli di sicurezza automatizzati e cicli di monitoraggio della sicurezza.

Runtime Application Self-Protection (RASP) identifica e blocca automaticamente le minacce alla sicurezza in entrata in tempo reale. RASP funge da proxy inverso che osserva gli attacchi imminenti e consente all'applicazione di riconfigurarsi automaticamente senza l'intervento umano in risposta a condizioni esplicite.

Un team interno o esterno specializzato può eseguire test di penetrazione per individuare exploit o vulnerabilità attraverso la compromissione intenzionale di un sistema. Un'altra tecnica di sicurezza è l'utilizzo di un programma Bug Bounty che offre una ricompensa a persone esterne che segnalano exploit e vulnerabilità della sicurezza.

Il monitoraggio della sicurezza utilizza l'analisi per strumentare e monitorare metriche critiche relative alla sicurezza. Ad esempio, questi strumenti contrassegnano le richieste a endpoint pubblici sensibili, come moduli di accesso agli account utente o endpoint di database. Alcuni esempi di strumenti di difesa runtime più diffusi includono Imperva RASP, Alert Logic e Halo.

In conclusione...


Man mano che un numero sempre più elevato di team di sviluppo fa evolvere i propri processi e adotta nuovi strumenti, l'attenzione rivolta alla sicurezza deve essere impeccabile. DevSecOps è un processo ciclico che andrebbe iterato e applicato continuamente a ogni nuova distribuzione di codice. Gli exploit e gli aggressori sono in continua evoluzione ed è importante che anche i team software moderni si evolvano.

Un buon punto di partenza per avviare i test DevSecOps è l'automazione dei test con Bitbucket Pipelines. Inoltre, è importante assicurarsi di controllare gli strumenti e le risorse di automazione dei test disponibili nell'Atlassian Marketplace.

Kev Zettler
Kev Zettler

Kev è uno sviluppatore web full-stack lead e imprenditore seriale con oltre un decennio di esperienza nella creazione di prodotti e team con metodologie Agile. È un appassionato collaboratore, autore e insegnante nell'ambito delle tecnologie open source emergenti come DevOps, criptovaluta e realtà aumentata/virtuale. Nel tempo libero, partecipa a competizioni dedicate allo sviluppo di giochi indie.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Workshop di simulazione

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up