DevSecOps: come integrare la sicurezza nel ciclo di sviluppo del software

La metodologia DevOps ha seguito una parabola evolutiva, che ha permesso nel tempo a portare al centro dello sviluppo del software la nozione di security by design. Questa evoluzione ha radici che affondano nel passato e che è necessario in premessa analizzare sinteticamente.

I modelli tradizionali pre-DevOps

I modelli tradizionali, che possiamo definire pre-DevOps, si fondavano sui seguenti elementi:

• Sviluppo e operazioni isolati: i teams di sviluppo e operazioni lavoravano in silos distinti. Il codice veniva sviluppato, testato e poi trasmesso al gruppo di lavoro di operazioni per la distribuzione e la gestione.
• Processi lenti e manuali: le implementazioni erano lente e spesso eseguite manualmente, portando a cicli di rilascio lunghi e a una mancanza di visibilità tra gruppi di lavoro.
• Instabilità e rilascio ritardato: gli sviluppatori spingevano per rilasciare nuove versioni, mentre gli operatori resistevano per mantenere la stabilità, causando conflitti e ritardi.

Elementi caratterizzanti della metodologia DevOps

In risposta ai limiti dei modelli tradizionali è emersa la metodologia DevOps, che si è contraddistinta immediatamente per i seguenti elementi:

• Agile e continous integration (CI): con l’avvento dell’Agile e della CI nei primi anni 2000, l’accento si spostò sulla collaborazione e sull’integrazione continua. Tuttavia, queste pratiche erano principalmente limitate allo sviluppo.
• Concetti di DevOps: DevOps è emerso come un’estensione delle pratiche Agile e CI, promuovendo la collaborazione tra sviluppo e operazioni per ridurre il divario tra i team e automatizzare i processi di rilascio e gestione.

Si sono formalizzati gli strumenti e le pratiche del modello oggetto di analisi, in particolare:

• Primi eventi e comunità: nel 2009, eventi come il primo DevOpsDays a Ghent hanno consolidato il movimento. La comunità iniziò a formalizzare concetti e pratiche DevOps, con enfasi sulla cultura collaborativa e sulla filosofia “Infrastructure as Code (IaC)”.
• Strumenti DevOps: sono stati sviluppati strumenti per supportare le pratiche DevOps:
  • Automazione CI/CD: Jenkins, GitLab CI, Travis CI.
  • Gestione della configurazione: Puppet, Chef, Ansible.
  • Monitoraggio e logging: Nagios, Prometheus, Splunk.
  • Containerizzazione: Docker, Kubernetes.

Questo modello, nel tempo, ha iniziato ad essere adottato dagli stakeholder ed è maturato:

• Adozione aziendale: aziende come Netflix, Amazon, Google e Microsoft hanno adottato DevOps su larga scala, dimostrando che una stretta integrazione tra sviluppo e operazioni porta a rilasci più rapidi, affidabili e sicuri.
• DevSecOps: con l’evoluzione della sicurezza integrata (DevSecOps), DevOps ha abbracciato anche la sicurezza come parte del ciclo di sviluppo, non solo alla fine.
• Cloud e microservizi: la diffusione del cloud computing e dei microservizi ha facilitato la scalabilità e la distribuzione continua, diventando pilastri del DevOps moderno.

La metodologia DevOps continua ad evolversi, tanto che:

• è ora ampiamente accettata, con enfasi su collaborazione, automazione e miglioramento continuo.
• proliferano nuove pratiche, si pensi all’adozione di GitOps (gestione dell’infrastruttura attraverso Git) e NoOps (automazione completa delle operazioni) rappresentano ulteriori evoluzioni nel paradigma DevOps.
• le piattaforme DevOps moderne integrano funzionalità di CI/CD, gestione delle infrastrutture, sicurezza e monitoraggio, supportando ambienti di sviluppo complessi e distribuiti.

DevOps: i principi fondamentali

DevOps è un approccio al software progettato per ridurre i tempi di rilascio delle nuove versioni degli applicativi. Il termine deriva dalla fusione di Development (sviluppo) e IT Operations (operazioni IT).

• Development si riferisce alla creazione del software.
• IT Operations comprende le attività di rilascio, monitoraggio e supporto dell’applicativo.

Questo metodo si basa su due principi fondamentali: automazione e collaborazione.

• Il primo comporta implementare tecnologie per minimizzare le attività manuali, incrementando l’efficienza dei processi e riducendo il rischio di errori. Automatizzando i compiti ripetitivi, si migliorano significativamente la qualità dei prodotti e la velocità dei processi di sviluppo e rilascio.
• Il secondo favorisce una comunicazione più fluida e una maggiore integrazione tra vari team aziendali, inclusi sviluppatori, operazioni IT, marketing e vendite. Questo facilita il coordinamento interno e l’allineamento agli obiettivi aziendali.

L’adozione della cultura DevOps consente a business unit tradizionalmente separate, come sviluppo, operazioni IT e controllo qualità, di lavorare insieme in modo più efficace. Tale collaborazione migliora la capacità di rispondere alle esigenze dei clienti, portando a prodotti più affidabili e di alta qualità.

Come massimizzare i vantaggi di un approccio DevOps

Per massimizzare i vantaggi di un approccio DevOps, è essenziale integrare anche i controlli di sicurezza, sia statici che dinamici:

• Controlli statici: Riguardano l’analisi del codice e delle dipendenze.
• Controlli dinamici: Coinvolgono l’analisi dell’ambiente di produzione.

Tradizionalmente, i controlli di sicurezza venivano effettuati manualmente da un team dedicato solo alla fine dello sviluppo. In passato, con cicli di sviluppo che potevano durare mesi o addirittura anni, la sicurezza non era considerata una priorità come lo è oggi.

Con DevOps, i cicli di sviluppo sono brevi e frequenti (settimane o giorni), e la sicurezza deve essere integrata continuamente.

Il modello CALMSS

Uno dei modelli chiave per comprendere DevOps è CALMSS, che rappresenta Culture, Automation, Lean, Management and Measurement, Sharing and Sourcing. Questo modello descrive le caratteristiche fondamentali del DevOps, che si basa su un insieme di pratiche e cambiamenti culturali supportati da strumenti automatizzati e da processi di Lean Management.

DevOps permette di automatizzare il rilascio del software lungo la sua catena di produzione, consentendo alle organizzazioni di sviluppare software e applicazioni di alta qualità e sicure in modo molto più rapido.

Gli elementi chiave del DevOps sono, come descritto sopra:

• Culture: si intende che il focus è orientato al cambiamento culturale e la collaborazione tra team.
• Automation: i processi di rilascio devono utilizzare strumenti di automatizzazione.
• Lean: adotta i principi di Lean Management[1] per migliorare l’efficienza.
• Management and Measurement: una gestione e una misurazione continua delle performance.
• Sharing and Sourcing: l’orientamento alla condivisione delle conoscenze e delle risorse

La necessità di un team interfunzionale

Un’implementazione DevOps efficace richiede che uno o più di questi elementi diventino parte integrante del processo di sviluppo aziendale, accelerando i tempi di rilascio del codice e creando sistemi più flessibili e sicuri. Tuttavia, la qualifica “DevOps” non implica necessariamente che uno sviluppatore sappia gestire anche aspetti operativi o viceversa. Esso presuppone un team interfunzionale in cui ogni membro è responsabile per l’intero ciclo di sviluppo.

Per implementare DevOps, è essenziale comprendere che questo approccio non si limita a linee guida generiche come sviluppo rapido, verifiche frequenti, automazione e collaborazione.

Un team IT potrebbe dichiararsi DevOps solo perché ha integrato alcuni processi, ma ciò non permette di considerarlo una profonda attuazione di un ambiente DevOps.

DevOps e pratiche Agile

Esso si basa su metodologie di lavoro che spesso fanno riferimento ai principi Agile.

Al riguardo, il Manifesto Agile, che è stato pubblicato nel 2001, ha definito un modello di sviluppo focalizzato sulla consegna frequente di software funzionante e di qualità al cliente.

Le pratiche Agile, che qui citiamo seppur sinteticamente, prevedono:

• team di sviluppo piccoli, cross-funzionali e auto-organizzati;
• sviluppo iterativo e incrementale;
• pianificazione adattiva;
• coinvolgimento diretto e continuo del cliente nel processo di sviluppo.

Questi principi sono essenziali anche in un ambiente DevOps, dove l’obiettivo è migliorare la qualità e la velocità del rilascio del software.

All’interno della metodologia Agile i due framework più utili in questo contesto sono:

• Scrum: Ideale per la gestione di progetti in cui è difficile poter effettuare una pianificazione in anticipo. Esso facilita la gestione dei progetti concentrandosi su cicli di sviluppo brevi e iterativi. Questo framework enfatizza la definizione degli obiettivi, la priorizzazione delle attività e la rapida identificazione di potenziali problemi, permettendo ai diversi team di lavoro di adattarsi velocemente ai cambiamenti.
• Kanban: permette la visualizzazione del flusso di lavoro, rendendo espliciti i passaggi del processo per migliorare l’efficienza. Kanban limita il lavoro in corso (WIP), permettendo ai team di riconoscere rapidamente le opportunità di miglioramento e mantenere il controllo sul carico di lavoro.

Questi framework sono cruciali per i team di sviluppo, poiché facilitano la rapida definizione degli obiettivi e delle priorità, l’assegnazione delle attività e, la tempestiva individuazione dei problemi nel processo di sviluppo, migliorando così la gestione complessiva del progetto.

DevSecOps: integrazione della sicurezza

Parte del nostro excursus vuole dimostrare come l’integrazione di approcci tradizionali e agili, supportata da una robusta governance e dall’adozione di DevOps, possa portare a una gestione dei progetti più efficace e allineata con le attuali dinamiche aziendali e tecnologiche.

Tuttavia, anche le implementazioni DevOps più avanzate possono fallire se la sicurezza viene trattata in modo saltuario. Questo può accadere in quanto i principali rischi per le applicazioni, spesso, emergono già nella fase di progettazione, rendendoli difficili da individuare e correggere nelle fasi successive dello sviluppo. Per cui, stante la centralità che la sicurezza ha assunto nello sviluppo del software, è stato coniato il termine DevSecOps.

DevSecOps integra la sicurezza direttamente nelle prime fasi dello sviluppo delle applicazioni e delle infrastrutture. Implementando controlli automatici, sia statici che dinamici, il processo diventa più lineare ed efficiente, permettendo di risparmiare tempo e risorse.

• Integrazione della sicurezza: considerando la sicurezza fin dall’inizio del ciclo di sviluppo, si evitano rallentamenti e si sfruttano efficacemente le soluzioni di monitoraggio e automazione.
• Coinvolgimento tra i team: sviluppatori e operatori sono attivamente coinvolti nel processo di sicurezza, riducendo il divario con gli esperti di sicurezza e prevenendo vulnerabilità fin dall’inizio.
• Risultati migliorati: questa integrazione garantisce la produzione di versioni software sicure e stabili in tempi più brevi.

Come per il DevOps, il successo e l’efficienza del DevSecOps dipendono dal supporto dei team coinvolti. È quindi cruciale comunicare chiaramente i benefici di questa metodologia. Entrambi gli approcci, DevOps e DevSecOps, si basano sul concetto di integrazione continua e distribuzione continua (CI/CD).

CI/CD rappresenta un approccio per distribuire applicativi in modo frequente, incorporando l’automazione nei processi.

L’acronimo CI/CD sta per Continuous Integration (CI), Continuous Delivery e Continuous Deployment (CD).

• Continuous integration (CI): è un processo continuo di integrazione del codice, che permette di rilevare e risolvere rapidamente eventuali conflitti, l’obiettivo è suddividere il lavoro in unità più piccole, rendendo così il processo di sviluppo più efficiente e flessibile nell’affrontare cambiamenti. È una pratica utilizzata nei contesti di sviluppo software basati su versioning. Questo approccio è stato introdotto originariamente nell’ambito dell’Extreme Programming (XP) per affrontare il problema noto come “integration hell”, ovvero le difficoltà di integrare porzioni di software sviluppate indipendentemente nel corso di lunghi periodi, che possono divergere significativamente. In questo processo, tutti gli sviluppatori caricano le loro modifiche del codice in un repository centrale condiviso. Ogni volta che viene effettuato un cambiamento, si avvia automaticamente una build, ossia la compilazione del software che genera un file eseguibile, seguita da una serie di test per verificare le funzionalità dell’applicativo. Uno dei principali benefici dell’adozione della CI è il risparmio di tempo durante lo sviluppo, poiché consente di identificare e risolvere tempestivamente i conflitti. Inoltre, aiuta a ridurre il tempo necessario per correggere bug e regressioni, enfatizzando l’importanza di avere una suite di test efficace.
• Continuous delivery/deployment (CD): rilascio continuo di aggiornamenti software, che facilita l’introduzione di nuove funzionalità e correzioni in modo rapido e affidabile. Secondo questo modello, le fasi di produzione, sviluppo, controllo qualità e rilascio non sono eventi isolati, ciò permette di sottoporre il software a controlli di qualità regolari e di rilasciarlo in fase di sviluppo, spesso con funzionalità di base, che vengono poi testate dal cliente in un ambiente reale. Il feedback del cliente e dei tester è cruciale per il controllo qualità durante tutto il ciclo di sviluppo. La Continuous Delivery è rappresentata come un ciclo continuo di sviluppo, test, rilascio e feedback che consente agli sviluppatori di rispondere rapidamente alle esigenze del cliente e migliorare costantemente il software in sviluppo. Le tre fasi di sviluppo, controllo e produzione non sono separate, ma interconnesse in un ciclo continuo: il prodotto attraversa costantemente queste fasi e viene continuamente migliorato.
  Questo sistema è particolarmente pratico per identificare tempestivamente quali parti del codice hanno causato eventuali errori, evitando ricerche dispendiose. Prima del rilascio al cliente, il software passa attraverso la pipeline di Continuous Delivery, dove vengono eseguiti test sia automatici che manuali in una fase intermedia. Solo dopo aver superato tutti i test con esito positivo, viene creata una versione stabile (“stable”) del prodotto, che viene quindi ufficialmente rilasciata.

Il Continuous Deployment, invece, diversamente dal precedente approccio è un processo di rilascio del software che sfrutta test automatizzati per validare la correttezza e la stabilità delle modifiche al codice, preparandolo per una distribuzione autonoma e immediata in ambiente di produzione. Questo processo permette di ridurre drasticamente errori e sprechi di risorse rispetto al tradizionale metodo manuale di spostare e verificare il codice tra diverse macchine. Gli sviluppatori integrano le modifiche al codice e le impacchettano all’interno di un artefatto che viene trasferito in ambiente di produzione, in attesa di essere approvato per la distribuzione, in questo contesto subisce controlli automatizzati, in caso di esito negativo il pacchetto viene scartato, in caso di esito positivo viene distribuito in produzione.

Il modello DevSecOps, il cui acronimo sta per “Development, Security, and Operations”, si pone l’obiettivo di incorporare la sicurezza fin dalla fase iniziale di sviluppo del software. Il suo focus è quello di garantire che la sicurezza non sia considerata un’aggiunta tardiva o un’attività separata, ma piuttosto un elemento integrato in ogni aspetto del processo di sviluppo.

Attraverso le caratteristiche della collaborazione e della automazione, il modello di sviluppo mira a ridurre i rischi legati alla sicurezza e a garantire un rilascio rapido e sicuro del software.

Con il continuo aumento delle minacce informatiche e l’esplosione delle applicazioni cloud-based e IoT, le organizzazioni devono essere consapevoli dei rischi e delle implicazioni della mancanza di sicurezza. Una violazione della sicurezza può avere gravi conseguenze, tra cui perdite finanziarie, danni alla reputazione dell’azienda e compromissione della fiducia dei clienti.

Integrare la sicurezza fin dalle prime fasi del ciclo di sviluppo del software non solo aiuta a mitigare i rischi legati alla sicurezza, ma può anche contribuire a migliorare la qualità complessiva del software e a ridurre i costi associati alla risoluzione dei problemi di sicurezza dopo il rilascio.

Il principio di security by design

La security by design è il principio di progettazione software e di sistema che integra un approccio proattivo che permette l’incorporazione della sicurezza in tutte le fasi di progettazione, sviluppo, test, distribuzione e manutenzione, anziché essere aggiunta come un ripensamento o un componente secondario.

L’obiettivo è garantire che i principi di sicurezza siano incorporati intrinsecamente, riducendo le vulnerabilità e migliorando la resilienza contro minacce e attacchi, senza compromettere la funzionalità o l’usabilità del sistema.

Evoluzione storica

La sua evoluzione storica e normativa è strettamente legata alla crescente complessità dei sistemi informatici e all’aumento delle minacce informatiche.

Gli anni ’70 sono caratterizzati dalla crescente preoccupazione per la sicurezza, con l’avvento dei primi virus informatici e attacchi a sistemi di rete, negli anni ’80, Il Dipartimento della Difesa degli Stati Uniti pubblica il “Trusted Computer System Evaluation Criteria” (TCSEC), noto anche come Orange Book, stabilendo standard per la valutazione della sicurezza dei sistemi informatici.

Nei primi anni ’90 l’aumento degli attacchi cyber su larga scala comportano nuovi contributi normativi, si pensi all’ITSEC che un fornisce un quadro di riferimento per la valutazione della sicurezza dei sistemi IT, evoluzione dell’Orange Book, ed ancora la Direttiva 95/46/EC per la protezione dei dati personali, che anticipa la necessità di protezione integrata nei sistemi di gestione dei dati.

Gli anni 2000 sono caratterizzati dall’emergenza di framework di sicurezza e normative sempre più ampie:

• viene sviluppato l’OWASP (Open Web Application Security Project) che definisce le buone pratiche di sicurezza per le applicazioni web;
• la ISO/IEC 27001 (standard internazionale per la gestione della sicurezza delle informazioni) incoraggia un approccio sistemico alla sicurezza integrandola nei processi aziendali;
• i Common Criteria (che verranno raccolti all’interno della ISO/IEC 15408) fornisce un quadro internazionale per la valutazione della sicurezza IT, favorendo l’adozione di pratiche di sicurezza integrate nei sistemi.

Negli anni 2010 il focus è rappresentato dalla progettazione sicura e l’adozione del GDPR.

Le problematiche di sicurezza collegate a IoT e cloud

Con l’introduzione sempre più massive di soluzioni IoT e l’uso del cloud computing, diventano sempre più emergenti le problematiche di sicurezza collegate a queste due tecnologie, considerata la maggiore presenza di oggetti collegati alla rete ed un incremento delle superficie di attacco.

DevOps: l’impatto del Gdpr

Nel 2016 viene pubblicato il General Data Protection Regulation (GDPR) all’interno degli Stati dell’Unione Europea, evoluzione normativa della direttiva del 1995, questo regolamento che verrà adottato nei successivi due anni all’interno dei sistemi normativi dei Paesi europei sottolinea un cambio di marcia nel trattamento dei dati personali e, tra i tanti principi – che tutt’oggi sono entrati all’interno della nostra quotidianità – sottolinea la necessità di una protezione dei dati personali sia by design che by default.

In pratica il regolamento richiede che la protezione dei dati sia attuata per impostazione predefinita con l’integrazione di misure di sicurezza fin dalla progettazione (by design) dei sistemi che trattano dati personali.

Oltreoceano, invece, il NIST (cioè, il National Institute of Standards and Technology) pubblica SP 800-160, che fornisce linee guida per l’ingegneria della sicurezza dei sistemi.

DevSecOps: definizione e principi fondamentali

È degli anni 2020 l’adozione del DevSecOps, modello che integra pratiche di sicurezza nella pipeline DevOps per garantire una sicurezza continua durante il ciclo di vita dello sviluppo del software.

In questi anni il panorama normativo è sempre più complesso e strutturato, incentrato sulla sicurezza dei sistemi informativi delle organizzazioni, ne sono un esempio la formalizzazione di alcuni standard internazionali e la pubblicazione di direttive in ambito europeo, quali:

• ISO/IEC 27701: sstensione della ISO/IEC 27001 per la gestione delle informazioni personali, sottolineando la necessità di privacy by design.
• Direttiva NIS2 (2022): Aggiornamento della direttiva europea sulla sicurezza delle reti e delle informazioni che richiede misure di sicurezza integrate nei sistemi essenziali per la società.

La Security by Design è evoluta da un concetto marginale a un principio centrale nella progettazione dei sistemi IT, influenzata da normative sempre più rigorose che richiedono l’integrazione della sicurezza nelle fasi iniziali di sviluppo.

Da iniziative come il TCSEC negli anni ’80, passando per l’ITSEC e ISO/IEC 27001, fino a GDPR e NIS2, la normativa ha continuamente enfatizzato la necessità di sicurezza intrinseca per proteggere i dati e garantire la resilienza dei sistemi contro le minacce emergenti.

Note

[1] Ideati dal fondatore di Toyota, dopo la seconda guerra mondiale, si fonda su cinque principi fondamentali: identificare il valore; mappare il flusso di valore; creare un flusso; stabilire un sistema di pull (in cui i gruppi lavorano solo su ciò di cui il cliente ha bisogno in un preciso momento, avviando la produzione in base alla domanda effettiva e non alle proiezioni previste); miglioramento continuo.