Adottare imperativi di pianificazione dello sviluppo sicuro

Questo articolo definisce gli imperativi principali per l'integrazione della sicurezza nelle procedure di sviluppo come parte della disciplina Sicurezza di sviluppo.

Le organizzazioni moderne si basano su un rapido sviluppo di software per offrire innovazione, soddisfare i requisiti aziendali, mantenere un vantaggio competitivo e rispondere alle mutevoli esigenze aziendali. Sebbene DevOps consenta questa agilità, introduce anche nuovi rischi per la sicurezza man mano che i processi di codice, infrastruttura e distribuzione si evolvono più rapidamente.

Per adottare in modo sicuro le procedure DevOps, le organizzazioni devono integrare la sicurezza nei processi di strategia di sviluppo, flussi di lavoro e recapito e adottare procedure DevSecOps che proteggono il recapito delle applicazioni nel ciclo di vita.

Risultati

L'adozione degli imperativi di pianificazione in questo articolo consente alle organizzazioni di:

• Ridurre l'introduzione dei punti deboli della sicurezza nei carichi di lavoro di produzione.
• Migliorare la coerenza delle decisioni di idoneità alla produzione.
• Ridurre l'attrito tra sviluppo, sicurezza e operazioni.
• Migliorare la resilienza delle applicazioni e dell'infrastruttura di distribuzione.
• Sostenere la velocità dell'innovazione, gestendo al contempo la sicurezza e il rischio operativo.

Riconoscere l'ambito della sicurezza di sviluppo

La sicurezza dello sviluppo si applica a più del codice dell'applicazione. Le organizzazioni devono definire i requisiti di sicurezza e le attività in tutti i componenti coinvolti nella progettazione, nella compilazione, nella distribuzione e nei carichi di lavoro operativi.

Le organizzazioni devono tenere conto dei rischi per la sicurezza tra:

• Logica e servizi dell'applicazione
• Automazione dell'infrastruttura/Distribuzioni IaC (Infrastructure-as-Code)
• Pipeline di compilazione e rilascio
• Configurazioni di distribuzione e script operativi
• Ambienti di sviluppo e identità del servizio
• Dipendenze di terze parti e componenti della supply chain

Il riconoscimento di questo ambito completo consente alle organizzazioni di definire i requisiti di sicurezza che riflettono il modo in cui i carichi di lavoro moderni vengono distribuiti, anziché limitare la sicurezza alla revisione del codice dell'applicazione in ritardo nel ciclo di vita.

Tenere conto dei rischi principali

Le organizzazioni devono includere in modo esplicito i rischi seguenti quando si definiscono i requisiti:

Area di rischio	Impatto di esempio
Errori di progettazione delle applicazioni	Accesso non autorizzato, esposizione dei dati, difetti della logica persistente.
Compromissione della pipeline	Inserimento di codice dannoso in artefatti di compilazione.
Compromissione dell'ambiente per sviluppatori	Furto di credenziali o elevazione dei privilegi.
Uso improprio degli strumenti DevOps	Modifiche non autorizzate tramite automazione o integrazioni.
Vulnerabilità della supply chain	Introduzione di dipendenze dannose o vulnerabili.

Questi rischi informano direttamente gli imperativi di pianificazione definiti in questo articolo e devono essere affrontati tramite decisioni di progettazione, processo e governance.

Questi rischi influiscono sia sui carichi di lavoro dell'applicazione che sull'infrastruttura usata per compilarli e gestirli.

Integrare la sicurezza nella strategia/ciclo di vita

La sicurezza deve essere incorporata nella strategia di sviluppo, non applicata come controllo post-rilascio.

Le organizzazioni devono definire i requisiti di sicurezza insieme ai requisiti funzionali e allinearli a:

• Strategia di sviluppo
• Pianificazione dell'architettura
• Flussi di consegna
• Modelli di supporto operativo

I risultati della sicurezza sono responsabilità condivise di proprietà dei ruoli tecnici e operativi, supportati dagli specialisti della sicurezza.

La sicurezza consente l'innovazione, non è un ostacolo da imporre dopo la consegna.

Le organizzazioni devono adottare un approccio continuo al ciclo di vita dello sviluppo sicuro (Secure Development Lifecycle, SDL) che include:

• Definizione dei requisiti di sicurezza all'inizio della progettazione.
• Allineamento dei requisiti di sicurezza con architettura e implementazione.
• Integrazione della sicurezza con l'automazione dell'infrastruttura.
• Eseguire la validazione continua della sicurezza.
• Monitoraggio dei problemi di sicurezza.
• Assegnazione delle priorità alla correzione.
• Applicazione degli esiti delle verifiche di sicurezza alle decisioni sulla prontezza al rilascio, in modo che i problemi di sicurezza siano considerati fattori bloccanti per la messa in produzione quando necessario.

La sicurezza deve essere valutata e migliorata continuamente man mano che si evolvono architetture di applicazioni, rischi e modelli di recapito.

Definire i criteri minimi di redditività della produzione

I carichi di lavoro devono soddisfare i criteri minimi di validità prima del rilascio di produzione. Questi criteri definiscono se un carico di lavoro è sicuro, conforme e operativo pronto per l'uso di produzione in tre dimensioni:

• Sviluppo (dev): gli stakeholder dello sviluppo definiscono i requisiti funzionali minimi necessari per soddisfare le esigenze aziendali e il valore per il cliente/l'utente.
• Sicurezza (sec):gli stakeholder della sicurezza definiscono i requisiti minimi necessari per soddisfare gli obblighi normativi, sostenere il comportamento di sicurezza dell'organizzazione e supportare il rilevamento e la risposta delle minacce attive.
• Operazioni (ops): i responsabili delle operazioni definiscono i requisiti minimi di prestazioni, qualità e manutenibilità necessari affinché il carico di lavoro funzioni in modo affidabile negli ambienti di produzione.

Criteri di redditività della produzione:

• Assicurarsi che i carichi di lavoro siano sicuri per la distribuzione e il funzionamento negli ambienti di produzione.
• Fungono da elementi di input per le decisioni di rilascio e devono essere applicati in modo coerente in tutti i flussi di lavoro di sviluppo.

I criteri di redditività della produzione si evolvono in base alle modifiche apportate a:

• Modelli di distribuzione delle applicazioni.
• Condizioni di minaccia.
• Tolleranza ai rischi dell'organizzazione.
• Requisiti di conformità.

Integrare la sicurezza nei flussi di lavoro di sviluppo

La sicurezza deve essere integrata direttamente nei processi di sviluppo e distribuzione. Le organizzazioni devono:

• Definire i requisiti di sicurezza all'interno dei flussi di lavoro di sviluppo.
• Integrare le attività di sicurezza in:
  • Processi di progettazione
  • Pipeline di compilazione
  • Flussi di lavoro di distribuzione (CI/CD)
• Implementare meccanismi di convalida della sicurezza come:
  • Analisi del codice
  • Convalida delle dipendenze
  • Controlli di configurazione

I risultati della sicurezza devono essere trattati come difetti di produzione e incorporati nelle decisioni di rilascio.

La validazione della sicurezza dovrebbe avvenire continuamente durante tutto il processo di delivery, non solo nei punti di controllo del rilascio.

Bilanciare e uniformare i requisiti

Le organizzazioni devono definire il modo in cui lo sviluppo, la sicurezza e i requisiti operativi sono bilanciati nelle decisioni di distribuzione del software. I carichi di lavoro di produzione devono soddisfare i requisiti per:

• Funzionalità aziendali.
• Resilienza della sicurezza.
• Velocità dell'innovazione.
• Affidabilità e prestazioni operative.

Le organizzazioni devono definire obiettivi di recapito condivisi e metriche delle prestazioni che:

• Allinearsi agli obiettivi condivisi di prestazioni e distribuzione tra sviluppo, sicurezza e operazioni.
• Evitare il dominio da un singolo dominio.
• Classificare in ordine di priorità i risultati in base a:
  • Tolleranza ai rischi dell'organizzazione.
  • Obblighi normativi.
  • Responsabilità aziendale.

L'equilibrio deve adattarsi man mano che le condizioni di minaccia si evolvono, i modelli di distribuzione cambiano e le priorità organizzative cambiano.

Stabilire la responsabilità condivisa

Un approccio DevSecOps efficace richiede una responsabilità condivisa tra i team di sviluppo, sicurezza e operazioni al fine di:

• Allineamento della responsabilità sui criteri di fattibilità della produzione.
• Allineare gli obiettivi di delivery tra le varie discipline.
• Ridurre i silos e gli attriti dannosi che creano lacune di sicurezza, ritardi nelle consegne e instabilità operativa.

Applicare protezioni di sicurezza basate su criteri

Le protezioni guidate dai criteri devono applicare controlli senza introdurre un eccessivo attrito. I guardrail devono includere:

• Requisiti di identità e accesso.
• Standard di configurazione e conformità.
• Controlli di distribuzione e rilascio.

I guardrail devono essere:

• Integrato nelle basi della piattaforma (ad esempio zone di destinazione).
• Incorporato nei flussi di lavoro di sviluppo/distribuzione.
• Applicato automaticamente, quando possibile.

Questo approccio garantisce che i requisiti di sicurezza vengano applicati in modo coerente mantenendo la velocità di recapito.

Per un approccio bilanciato alla sicurezza e alla velocità dell'innovazione, valuta l'adozione utilizzando paletti basati su criteri.

Sostenere e migliorare

La sicurezza non rimane efficace come set statico di controlli e deve evolversi nel tempo.

Le organizzazioni devono valutare e aggiornare continuamente le procedure di sicurezza dello sviluppo in risposta alle modifiche in:

• Condizioni di minaccia e comportamento degli utenti malintenzionati.
• Architetture di applicazioni e modelli di recapito.
• Obblighi normativi.
• Tolleranza ai rischi dell'organizzazione.
• Criteri di redditività della produzione.
• Processi di recapito dello sviluppo.
• Procedure di governance della sicurezza.

Le procedure di sicurezza devono evolversi insieme ai sistemi protetti.

Tecniche di allineamento

I team devono essere allineati a:

• Definire obiettivi comuni: i responsabili dello sviluppo, della sicurezza e delle operazioni devono definire in modo collaborativo gli obiettivi di recapito e le metriche delle prestazioni per il recapito del carico di lavoro, per supportare una pianificazione coerente del rilascio.
• Evitare la dominanza delle decisioni a dominio singolo: le decisioni di recapito devono tenere conto dei requisiti operativi, di sviluppo e sicurezza per evitare squilibri che potrebbero influire negativamente sull'affidabilità, la conformità o le funzionalità aziendali del carico di lavoro.
• Classificare in ordine di priorità il miglioramento continuo rispetto ai criteri di rilascio statici: le procedure di sicurezza dello sviluppo devono essere perfezionate in modo iterativo nel corso del tempo man mano che i modelli di distribuzione delle applicazioni, le condizioni di minaccia e le priorità dell'organizzazione si evolvono.
• Stabilire un contesto condiviso di erogazione tra i diversi stakeholder: i team di sviluppo, sicurezza e operazioni devono mantenere una comprensione comune di:
  • Urgenza aziendale e tempistiche di consegna
  • Condizioni di minaccia rilevanti e esposizione al rischio
  • Requisiti di disponibilità e supporto operativi
• Monitorare i problemi di recapito introdotti dai requisiti di sicurezza: i requisiti di sicurezza possono causare problemi di recapito. I leader devono valutare se questo attrito contribuisce alla riduzione dei rischi (ad esempio, abilitando l'identificazione precedente delle vulnerabilità) o ritarda inutilmente la distribuzione del carico di lavoro senza migliorare materialmente la resilienza di produzione.
• Incorporare la sicurezza dello sviluppo nella pianificazione e nell'allocazione delle risorse: i requisiti di sicurezza per i carichi di lavoro delle applicazioni devono essere incorporati nella pianificazione dello sviluppo e nell'allocazione delle risorse insieme alle funzionalità e ai requisiti di supporto operativo.
• Definire obiettivi condivisi relativi alle prestazioni di delivery: le metriche delle prestazioni e del successo per i carichi di lavoro delle applicazioni devono riflettere i risultati di delivery relativi a sviluppo, sicurezza e operazioni.

Allineare i flussi di lavoro ai requisiti di sicurezza

La sicurezza deve essere operativa tramite flussi di lavoro di sviluppo. Le organizzazioni devono definire e allineare i flussi di lavoro per:

• Attività di progettazione dell'architettura.
• Processi di compilazione e distribuzione.
• Flussi di lavoro di rilevamento e correzione dei problemi.

I risultati della sicurezza devono essere:

• Assegnati a una priorità e monitorati.
• Gestito insieme ai difetti di produzione.
• Incorporato nelle decisioni di idoneità per il rilascio.

L'allineamento del flusso di lavoro garantisce che i requisiti di sicurezza vengano applicati in modo coerente durante il recapito.

Passaggi successivi

Informazioni sullo sviluppo usando i principi di Zero Trust