Strumenti DevSecOps

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.

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 attivano 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.

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.

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.

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.

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.