Passare da DevOps a DevSecOps

Durante la creazione o la modernizzazione di una disciplina di sicurezza per lo sviluppo, questo articolo descrive come l'integrazione della sicurezza nelle procedure di sviluppo consente il passaggio dalle operazioni di sviluppo (DevOps) alle operazioni di sicurezza per sviluppatori (DevSecOps) e consente la distribuzione sicura delle applicazioni.

Le organizzazioni moderne si affidano allo sviluppo rapido di software per offrire innovazione, rispondere ai cambiamenti dei requisiti aziendali e mantenere un vantaggio competitivo. DevOps consente questa agilità grazie all'integrazione e al recapito continui. Tuttavia, una maggiore velocità introduce anche nuovi rischi per la sicurezza.

I cicli di rilascio continui riducono il tempo tra le decisioni di progettazione e la distribuzione di produzione, aumentando la probabilità che i punti deboli vengano introdotti negli ambienti di produzione, tra cui:

• Punti deboli di progettazione delle applicazioni
• Dipendenze vulnerabili
• Errori di configurazione
• Errori di automazione dell'infrastruttura
• Scarsa gestione dei segreti o igiene.

Rischio DevOps

Gli ambienti DevOps moderni espandono la superficie di attacco tra sistemi di sviluppo, pipeline e produzione. Gli strumenti DevOps, ad esempio repository di codice sorgente, pipeline e sistemi di automazione, sono obiettivi di alto valore per gli utenti malintenzionati.

Se il codice dannoso viene introdotto in anticipo, potrebbe superare i controlli di sicurezza esistenti e raggiungere i sistemi di produzione.

Gli obiettivi di attacco comuni includono:

• Inserimento di codice dannoso negli artefatti di compilazione.
• Compromissione delle identità degli sviluppatori o degli account del servizio.
• Accesso o esfiltrazione dei dati di produzione.

Gli utenti malintenzionati spesso usano applicazioni personalizzate e ambienti di sviluppo per ottenere l'accesso a:

• Dati sensibili dell'organizzazione o dei clienti.
• Logica di business proprietaria e proprietà intellettuale.
• Infrastruttura di produzione tramite sistemi di sviluppo compromessi.
• Clienti a valle tramite la compromissione della catena di fornitura del software.

I potenziali rischi per la sicurezza sono riepilogati nel diagramma seguente:

Rischio per applicazioni e sviluppo

I carichi di lavoro delle applicazioni possono essere compromessi tramite punti deboli introdotti durante lo sviluppo o tramite compromissione dell'infrastruttura usata per compilarli e distribuirli.

Rischio	Destinazione	Potenziale risultato
Progettazione/implementazione di app	I problemi di sicurezza introdotti durante la progettazione o lo sviluppo possono esporre carichi di lavoro a tecniche di attacco come: - Convalida dell'input non corretta - Logica di autenticazione o autorizzazione non sicura - Crittografia debole o implementata in modo non corretto - Esposizione dei dati sensibili tramite la logica dell'applicazione	Questi punti deboli potrebbero consentire agli utenti malintenzionati di: - Accedere o modificare i dati dell'applicazione - Eseguire operazioni non autorizzate - Mantenere un accesso persistente attraverso vulnerabilità logiche inserite.
Infrastruttura/automazione di sviluppo	Gli attacchi potrebbero colpire: - Repository di codice sorgente - Pipeline di compilazione - Automazione della distribuzione - Modelli IaC (Infrastructure-as-Code) - Sviluppare endpoint o identità di servizio	La compromissione potrebbe consentire agli utenti malintenzionati di: - Inserire codice dannoso in artefatti di compilazione - Modificare le configurazioni di distribuzione - Mantenere l'accesso permanente tramite un difetto logico impiantato - Ottenere credenziali o segreti usati negli ambienti di produzione.
Catena di approvvigionamento software di sviluppo	Le applicazioni si basano in genere su: - Librerie di terze parti - Pacchetti open source - Immagini del contenitore - Servizi della piattaforma	Le vulnerabilità o il codice dannoso introdotto tramite queste dipendenze possono influire: - Carichi di lavoro di produzione dell'organizzazione - Ambienti del cliente o del partner

L'integrazione della sicurezza nei processi di sviluppo riduce la probabilità che questi rischi vengano propagati nel rilascio di produzione.

Spostamento a sinistra

Shift left è un approccio di progettazione della sicurezza che integra la sicurezza in precedenza nel ciclo di vita di sviluppo.

Invece di convalidare la sicurezza in ritardo nel processo, le organizzazioni lo incorporano in:

• Visualizzazione
• Design
• Sviluppo
• Operations

In questo modo si riducono i costi di correzione e l'esposizione ai rischi.

Per supportare questo approccio, le organizzazioni devono"

• Usare procedure consigliate strutturate, ad esempio il ciclo di vita dello sviluppo della sicurezza (SDL) all'inizio del processo, anziché in ritardo quando i problemi diventano costosi e difficili da risolvere.
• Per sostenere questo approccio, integrare governance, rischio e conformità (GRC) nella strategia di sviluppo.

Cos'è DevSecOps?

DevSecOps offre l'approccio Shift Left estendendo DevOps e incorporando la sicurezza in ogni fase del ciclo di vita dello sviluppo software, dall'idea all'inizio attraverso la progettazione, lo sviluppo e le operazioni.

• Negli approcci di sviluppo tradizionali, la convalida della sicurezza è stata spesso eseguita come controllo di qualità finale prima del rilascio. Questo ha creato ritardi, costi di correzione aumentati e consentito la persistenza delle vulnerabilità fino alla fine del ciclo di vita.

• DevSecOps sposta la sicurezza in precedenza e la incorpora continuamente nei processi operativi e di sviluppo.

• DevSecOps riduce l'attrito tra i team di sviluppo, operazioni e sicurezza, allineandoli agli obiettivi condivisi della velocità dell'innovazione, dell'affidabilità e della resilienza della sicurezza e consentendo ai team di risolvere i problemi più importanti in anticipo e continuamente.

• DevSecOps integra la sicurezza in:

  • Progettazione architettonica
  • Implementazione dell'applicazione
  • Automatizzazione dell'infrastruttura
  • Processi operativi e di distribuzione

Benefits

DevSecOps consente ai team di sviluppo, sicurezza e operazioni di:

• Identificare e correggere i problemi in precedenza nel ciclo di vita.
• Ridurre l'esposizione nella produzione.
• Mantenere la velocità di consegna durante la gestione dei rischi.

La sicurezza diventa parte del modo in cui viene creato e distribuito il software, anziché un controllo applicato dopo il recapito.

Ciclo di vita dell'innovazione sicura

L'innovazione in genere procede attraverso due fasi del ciclo di vita:

Fase	Dettagli
Incubazione delle idee	Una funzionalità è progettata, implementata e convalidata per l'uso di produzione iniziale. Inizia con una nuova idea
Versione iniziale	Una prima versione di produzione soddisfa i criteri minimi di prodotto per l'uso sicuro del prodotto. - Sviluppo: la funzionalità soddisfa i requisiti aziendali minimi. - Sicurezza: le funzionalità soddisfano i requisiti di conformità, sicurezza e sicurezza normativi per l'uso in produzione. - Operazioni: La funzionalità soddisfa i requisiti minimi di qualità, prestazioni e supporto per essere un sistema di produzione.

Dopo il rilascio iniziale, lo sviluppo diventa iterativo man mano che i carichi di lavoro si evolvono con:

• Modifica della tolleranza ai rischi
• Requisiti dell'applicazione e maturità
• Obblighi normativi
• Condizioni di minaccia

Integrare la sicurezza in fase di sviluppo

Gli approcci di sviluppo tradizionali convalidano la sicurezza in ritardo nel ciclo di vita, come controllo finale prima del rilascio dopo il completamento della progettazione e dell'implementazione. Negli ambienti di sviluppo moderni, la convalida ritardata aumenta:

• Complessità della vulnerabilità
• Costo della correzione
• Ritardi operativi e interruzioni
• Aumento dell'esposizione ai rischi allo sfruttamento attivo

DevSecOps integra continuamente la sicurezza in tutto lo sviluppo e le operazioni, per risolvere i problemi in precedenza, ridurre i rischi e migliorare la coerenza.

Procedure chiave

La sicurezza deve essere incorporata in processi di sviluppo esistenti per essere efficaci, scalabili e sostenibili. Deve essere integrato direttamente nel modo in cui le app vengono progettate, compilate, distribuite e gestite, non implementate in un flusso di lavoro separato o parallelo. È consigliabile:

• Mappatura dei flussi di lavoro end-to-end dall'idea allo sviluppo, alla distribuzione e alle operazioni continue.
• Definizione di ruoli, strumenti e responsabilità chiare per la sicurezza in ogni fase del ciclo di vita.
• Definizione di percorsi di correzione coerenti per vulnerabilità, difetti e problemi di progettazione.

Personalizzare le procedure di sicurezza in base al rischio del carico di lavoro. Le applicazioni critiche per l'azienda richiedono maggiore rigore, mentre gli scenari a basso rischio possono seguire approcci semplificati.

Assicurarsi almeno di:

• Identificare le fasi, le persone e le tecnologie coinvolte nel ciclo di vita dello sviluppo.
• Definire il modo in cui le attività di sicurezza si integrano in ogni fase, anziché considerarle come checkpoint separati.
• Stabilire processi per la gestione delle modifiche principali e delle correzioni di routine per tutto il ciclo di vita.

Automatizza la sicurezza nei processi di sviluppo e distribuzione

L'automazione è essenziale per applicare la sicurezza in modo coerente e su larga scala tra le operazioni e lo sviluppo.

• Integrare i controlli di sicurezza e gli strumenti direttamente nelle pipeline CI/CD.
• Automatizzare le attività chiave, ad esempio la modellazione delle minacce, l'analisi del codice, la convalida e l'applicazione dei criteri.
• Usare Infrastructure as Code (IaC) per abilitare distribuzioni ripetibili e sicure.

Le fondamenta della piattaforma, come le landing zone di Azure, possono supportare questo approccio contribuendo a

Le basi della piattaforma, ad esempio Azure zone di destinazione possono supportare questo approccio fornendo modelli standardizzati per la sicurezza, la governance e l'integrazione di DevOps.

Risultati previsti

Le organizzazioni che passano da DevOps a DevSecOps possono:

• Ridurre la probabilità che le vulnerabilità vengano introdotte nei carichi di lavoro di produzione
• Limitare la capacità degli utenti malintenzionati di sfruttare l'infrastruttura di sviluppo o l'automazione
• Migliorare la resilienza delle applicazioni alle tecniche di attacco in continua evoluzione
• Supportare i requisiti normativi e di conformità dell'organizzazione
• Sostenere la velocità di innovazione senza aumentare il rischio operativo o di sicurezza

Suggerimenti per esplorare il viaggio

L'adozione di DevSecOps richiede modifiche organizzative e culturali.

Cambiamenti di istruzione e cultura

Si tratta di passaggi preliminari critici. Il team di cui si dispone deve sviluppare nuove competenze e adottare nuove prospettive per comprendere il modello DevSecOps.

Il cambiamento dell'istruzione e della cultura richiede tempo, attenzione, sponsorizzazione dirigente e follow up regolare per aiutare gli individui a comprendere e vedere il valore del cambiamento.

Il cambiamento delle culture e delle competenze può talvolta sfruttare l'identità professionale degli individui, creando un potenziale di resistenza forte. È fondamentale comprendere ed esprimere il perché, cosa e come del cambiamento per ogni individuo e la loro situazione.

La modifica richiede tempo

È possibile spostarsi rapidamente solo quando il team può adattarsi alle implicazioni delle operazioni in modi nuovi. I team devono continuare a svolgere il loro lavoro abituale mentre si trasformano.

È fondamentale classificare attentamente in ordine di priorità ciò che è più importante e gestire le aspettative di quanto può accadere questa modifica.

Adottare una strategia graduale, in cui gli elementi più importanti e fondamentali vengono prima, porta benefici alla tua organizzazione.

La modifica introduce (temporaneo) attrito

Tutte le nuove tecnologie, metodologie e altre modifiche introducono attrito e confusione. È fondamentale concentrarsi sull'attrito sano che spinge il pensiero critico a ridurre il rischio evitando attriti non integri che rallentano i processi con benefici limitati o riduzione del rischio.

Risorse limitate

Una sfida che le organizzazioni di solito devono affrontare nelle prime fasi consiste nel trovare talenti e competenze nello sviluppo di applicazioni e sicurezza.

Man mano che le organizzazioni iniziano a collaborare in modo più efficace, potrebbero trovare talenti nascosti, ad esempio sviluppatori con una mentalità orientata alla sicurezza o professionisti della sicurezza con un background di sviluppo.

Turni in corso

Le app cambiano rapidamente. Oltre alle nuove funzionalità, la definizione tecnica e la composizione di un'applicazione stanno cambiando fondamentalmente con l'introduzione di tecnologie come cloud, serverless e intelligenza artificiale.

Questo cambiamento sta cambiando le procedure di sviluppo, la sicurezza delle applicazioni e consente anche ai non sviluppatori di creare applicazioni.

Prendere in considerazione un modello SRE

Alcune implementazioni di DevSecOps combinano le operazioni e le responsabilità di sicurezza in un ruolo SRE (Site Reliability Engineer).

Anche se un modello di questo tipo può funzionare, spesso è un cambiamento estremo rispetto alla cultura e alle procedure aziendali esistenti.

Se si sta valutando un modello SRE, è consigliabile iniziare incorporando la sicurezza in DevOps usando vittorie rapide pratiche e progressi incrementali descritti in questa guida per assicurarsi di ottenere un buon ritorno sugli investimenti (ROI) e soddisfare esigenze immediate.

Questo aggiunge in modo incrementale le responsabilità di sicurezza al personale operativo e di sviluppo, che sposta i team più vicini a uno stato finale SRE.

Passaggi successivi

Informazioni sulle procedure consigliate per lo sviluppo sicuro.