{"id":25415,"date":"2024-01-23T10:06:55","date_gmt":"2024-01-23T09:06:55","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=25415"},"modified":"2024-01-25T12:21:26","modified_gmt":"2024-01-25T11:21:26","slug":"verso-il-devsecops-con-gitlab","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/devops-it\/verso-il-devsecops-con-gitlab\/","title":{"rendered":"Verso il DevSecOps con GitLab"},"content":{"rendered":"\n

In questo articolo esploreremo la transizione dal ciclo di vita del software tradizionale al contesto del DevSecOps, approfondendo aspetti legati a DevOps e alla CI\/CD. Inoltre, ci concentreremo sui problemi affrontati durante questo percorso e sulle soluzioni sviluppate nel corso del tempo, con un particolare riguardo su GitLab, una piattaforma di DevSecOps unificata.<\/p>\n\n\n\n

SDLC Tradizionale<\/h2>\n\n\n\n

Prima di introdurre concetti di DevOps e DevSecOps, \u00e8 importante fare un tuffo nel passato per capire come anni fa venivano sviluppati e rilasciati i software applicativi.<\/p>\n\n\n\n

Credo tutti abbiamo gi\u00e0 sentito parlare di \u201cmodello waterfall<\/strong>\u201d (in italiano \u201cmodello a cascata\u201d). Esso rappresenta il Software Development Life Cycle (SDLC) tradizionale, ovvero quello in cui si seguono una serie di step fino ad arrivare al prodotto (software) finito e consegnato al cliente.<\/p>\n\n\n\n

Si inizia con una fase di analisi e raccolta dei requisiti, dopodich\u00e9 si passa alla fase di progettazione dove si progetta il software in modo che rispecchi i requisiti.<\/p>\n\n\n\n

Dopo aver terminato la progettazione segue l\u2019implementazione (scrittura del codice applicativo), per poi procedere con i test finalizzati a verificare che tutto funzioni come da aspettative. Successivamente, si procede con il deploy in ambiente di produzione.<\/p>\n\n\n\n

Vi \u00e8 anche una fase di manutenzione utile nel caso in cui escono dei bug durante l\u2019utilizzo del software da parte del cliente oppure in caso di piccole modifiche oppure aggiunte di funzionalit\u00e0 (features) richieste sempre dal cliente.<\/p>\n\n\n\n

Il problema dell\u2019approccio waterfall \u00e8 che il cliente cambia sempre idea! C\u2019\u00e8 il serio rischio che durante la fase di progettazione, o addirittura durante quella di implementazione, il cliente rivoluzioni tutto con nuovi requisiti spesso incompatibili con quelli raccolti nella prima fase di analisi.<\/p>\n\n\n\n

Il team di sviluppo non \u00e8 mai pienamente certo di soddisfare i requisiti del cliente in quanto possono variare nel tempo. Questo come conseguenza comporta fare uno o pi\u00f9 passi indietro, ovvero si rischia di tornare alla fase iniziale di analisi e raccolta dei requisiti e di rifare la progettazione e l\u2019implementazione.<\/p>\n\n\n\n

Oggi per fortuna la metodologia waterfall \u00e8 quasi completamente un ricordo: non viene pi\u00f9 utilizzata a meno di casi particolari.<\/p>\n\n\n\n

Metodologia Agile<\/h2>\n\n\n\n

Il subentro della metodologia agile<\/strong> ha cambiato tutto! A differenza dell\u2019approccio waterfall, \u00e8 basata sulla distribuzione continua del software in maniera rapida ed iterativa (ciclica).<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

L\u2019obiettivo \u00e8 quello di rilasciare rapidamente le modifiche al software in piccole porzioni, arrivando pian piano a soddisfare le esigenze del cliente che, come sappiamo, possono mutare nel tempo.<\/p>\n\n\n\n

In questo modo si tenta di ridurre il rischio di fallimento, sviluppando il software in finestre di tempo limitate chiamate iterazioni o sprint<\/strong>, che durano in genere da 1 a 4 settimane.<\/p>\n\n\n\n

Ogni iterazione \u00e8 come un piccolo progetto a s\u00e9 stante e deve contenere tutto ci\u00f2 che \u00e8 necessario per rilasciare un piccolo incremento nelle funzionalit\u00e0 del software: quindi ogni volta si procede con la pianificazione, analisi dei requisiti, progettazione, implementazione, test, deploy e revisione.<\/p>\n\n\n\n

Abbiamo per\u00f2 un side-effect: la velocit\u00e0 con cui vengono apportati i cambiamenti potrebbe impattare sulla qualit\u00e0 del software che andiamo a rilasciare! Gli sviluppatori per completare lo sprint nei tempi stabiliti potrebbero trascurare alcuni aspetti relativi alla qualit\u00e0 del software.<\/p>\n\n\n\n

In questo contesto, il DevOps<\/strong> entra in gioco a gamba tesa e si propone come soluzione!<\/p>\n\n\n\n

Development & Operation<\/h2>\n\n\n\n

In generale, in un\u2019organizzazione possiamo distinguere due team: quello di Development e quello di Operation.<\/p>\n\n\n\n

Il team di Development<\/strong> si occupa dello sviluppo del software, ovvero crea applicazioni seguendo le indicazioni del business nel modo pi\u00f9 veloce possibile. L\u2019obiettivo \u00e8 quello di arrivare rapidamente in ambiente di produzione e ridurre al minimo il tempo del \u201ctime to market\u201d.<\/p>\n\n\n\n

Il team di Operation<\/strong>, invece, si occupa di gestire le applicazioni in ambiente di produzione. Ha un duplice obbiettivo: rendere l\u2019ambiente di esercizio il pi\u00f9 stabile e sicuro possibile, ed evitare impatti negativi relativi al deploy di applicazioni non sufficientemente stabili e preformanti.<\/p>\n\n\n\n

\u00c8 come se avessimo un muro (detto \u201cmuro di confusione<\/strong>\u201d) tra i due team:<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Il team di Development ha la pressione del business e tende a rilasciare le applicazioni fin troppo velocemente a scapito della qualit\u00e0 e delle prestazioni, mentre dall\u2019altra parte del muro c’\u00e8 il team di Operation che richiede stabilit\u00e0 e requisiti di qualit\u00e0, performance e sicurezza per l\u2019applicazione deployata in ambiente di produzione.<\/p>\n\n\n\n

A causa di questi obiettivi parzialmente in conflitto tra questi due team di lavoro, si \u00e8 sempre avuta una sorta di diffidenza reciproca, che spesso si traduce in inefficienza.<\/p>\n\n\n\n

Questo conflitto viene risolto con il DevOps<\/a><\/strong>, ovvero un approccio che spinge questi due team a cooperare per rendere il processo di deploy veloce e al contempo sicuro.<\/p>\n\n\n\n

DevOps<\/h2>\n\n\n\n

La parola DevOps<\/strong> potrebbe sembrare un concetto piuttosto semplice, infatti, si compone dalla parola \u201cdev\u201d (development) e dalla parola \u201cops\u201d (operations). Come allude la parola stessa, consiste nel riunire queste due aree funzionali storicamente separate. L\u2019obiettivo \u00e8 quello di colmare il divario (rimuovere i silos) tra i team di sviluppo e di operazioni.<\/p>\n\n\n\n

Per definizione, il DevOps<\/strong> \u00e8 un insieme di pratiche da adottare volte ad accelerare i processi che consentono ad un\u2019idea (es. una nuova feature nel software, una richiesta di miglioramento, fix di bugs, ecc.) di passare dallo sviluppo al deployment in ambiente di produzione, assicurando un\u2019elevata qualit\u00e0.<\/p>\n\n\n\n

Con il DevOps i due team non agiscono pi\u00f9 separatamente, ma si affidano all\u2019automatizzazione per velocizzare processi manuali che sono da sempre lenti.<\/p>\n\n\n\n

Il punto chiave \u00e8 rendere automatici, e di conseguenza obbligatori, una serie di processi in sequenza, come quello di build, test, rilascio e deploy attraverso l\u2019utilizzo di pipeline di CI\/CD<\/strong> e altri tool.<\/p>\n\n\n\n

Che cosa \u00e8 il DevOps?<\/h3>\n\n\n\n

Il concetto di DevOps \u00e8 stato introdotto circa 10 anni fa, tuttavia, oggi ha un significato pi\u00f9 ampio in quanto \u00e8 ancora in fase di evoluzione. Comprende tantissime aree, e viene adottato e adattato in base al contesto e agli obiettivi aziendali.<\/p>\n\n\n\n

Il DevOps non \u00e8 assolutamente un ruolo, un team oppure una riorganizzazione del personale. Chi pensa che il DevOps possa essere realizzato attraverso una riorganizzazione o uno sforzo di assunzione sta solamente guardando ad un solo pezzo del puzzle del DevOps. La struttura organizzativa e i ruoli del team sono secondari rispetto alle pratiche cooperative sottostanti sul lavoro.<\/p>\n\n\n\n

Inoltre, il DevOps non significa semplicemente implementare una serie di tool di DevOps. Non ha senso utilizzare questi tool senza aver ben chiaro in mente i principi base. L\u2019automazione, punto cardine del DevOps, \u00e8 solo l\u2019esercizio del potere: un\u2019automazione imprudente pu\u00f2 causare tanti danni quanto un\u2019automazione saggia pu\u00f2 portare benefici.<\/p>\n\n\n\n

Fatte queste considerazioni, possiamo dare una definizione pi\u00f9 generale del DevOps: \u00e8 quella disciplina radicata nella collaborazione e nella comunicazione, resa possibile rimuovendo le barriere percepite tra i team, creando fiducia in una cultura di apprendimento e miglioramento continuo, e attingendo da comprovate pratiche tecniche e gestionali che lavorano verso l\u2019obiettivo comune di accorciare i cicli di distribuzione del software e migliorare la stabilit\u00e0 delle implementazioni.<\/p>\n\n\n\n

Shift-Left<\/h3>\n\n\n\n

Uno dei pilastri fondamentali del DevOps \u00e8 il cosiddetto Shift Left<\/strong>, a volte chiamato anche Start Left. Descrive il principio di effettuare test e controlli sulla qualit\u00e0 del codice nelle prime fasi del ciclo di vita dello sviluppo del software.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Con la diffusione delle metodologie agili, il test e i controlli di qualit\u00e0 del software non devono attendere finch\u00e9 gli sviluppatori non consegnano il loro codice. Possono invece accadere mentre gli sviluppatori stanno sviluppando. Visivamente, i test e i controlli sulla qualit\u00e0 del software si spostano a sinistra: da qui l\u2019origine del termine shift-left.<\/p>\n\n\n\n

I vantaggi dello shift-left sono molteplici: innanzitutto possiamo scoprire tempestivamente i problemi nel software, inoltre, possiamo garantire, una volta che il software viene distribuito, che questo sia stabile e richieda meno manutenzione.<\/p>\n\n\n\n

Con lo shift-left gli sviluppatori sono al centro del cambiamento: sono in prima fila! Questo per\u00f2 non significa che addossiamo pi\u00f9 responsabilit\u00e0 ai poveri sviluppatori, ma bens\u00ec gli stiamo riducendo il carico di lavoro trasformando problemi critici di \u201cfine gioco\u201d in banali soluzioni di \u201cinizio gioco\u201d.<\/p>\n\n\n\n

I test manuali e i controlli di qualit\u00e0 richiedono molto tempo, sono frustranti e introducono errori umani. Questo andrebbe a rafforzare il muro tra \u201cdev\u201d e \u201cops\u201d, ed \u00e8 l\u2019opposto a ci\u00f2 che il DevOps cerca di fare. Per questo motivo lo shift-left richiede automazione!<\/p>\n\n\n\n

Pratiche di CI\/CD<\/h2>\n\n\n\n

L\u2019automazione \u00e8 il punto focale del DevOps per unire il team Dev e Ops, e si pu\u00f2 applicare in vare modalit\u00e0. La pi\u00f9 importante fa utilizzo di pipeline di Continuous Integration<\/strong> e Continuous Deployment<\/strong> (CI\/CD).<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Continuous Integration<\/h3>\n\n\n\n

La Continuous Integration (CI)<\/strong> \u00e8 una pratica che si applica quando lo sviluppo del codice avviene attraverso l\u2019utilizzo di un sistema di versionamento (es. Git). <\/p>\n\n\n\n

Questa pratica spinge i developer ad integrare frequentemente le modifiche sviluppate in locale verso una code base condivisa (repository), per poi poter eseguire una pipeline che automatizza il processo di build (compilazione) e l\u2019esecuzione di test automatici, come ad esempio quelli di unit\u00e0, di qualit\u00e0 e di integrazione.<\/p>\n\n\n\n

Nota: per poter effettuare i test di integrazione possiamo pensare di affidarci al mock oppure di deployare l\u2019applicazione in un ambiente di staging che verr\u00e0 subito distrutto dopo i test condotti.<\/em><\/p>\n\n\n\n

Dunque, ad ogni nuova integrazione (es. quando viene aperta una pull request) viene eseguita questa pipeline. Nel caso la compilazione automatica oppure i test automatici fallissero, anche la pipeline fallirebbe. Lo sviluppatore \u00e8 costretto a rivedere il codice, fixandolo e migliorandolo in modo che i test passino con successo (assicurando di conseguenza la correttezza e la qualit\u00e0 del software rilasciato).<\/p>\n\n\n\n

Se i test passano con successo, la CI effettua il packaging (impacchetta l\u2019artefatto buildato) e lo deposita all\u2019interno di un artifact repository, versionandolo ed aggiungendo altri metadati.<\/p>\n\n\n\n

Continuous Deployment<\/h3>\n\n\n\n

Con il Continuous Deployment (CD)<\/strong>, oltre agli automatismi previsti dalla CI, viene automatizzato tramite pipeline anche il deploy in ambiente (es. in ambiente di collaudo e di produzione). Infine, nel caso in cui il deploy in produzione avviene manualmente, essendo ragionevolmente uno step molto delicato, parleremo invece Continuous Delivery. <\/p>\n\n\n\n

Di solito quando si pensa al DevOps, viene subito in mente il simbolo dell\u2019infinito:<\/p>\n\n\n

\n
\"CI\/CD,<\/figure><\/div>\n\n\n

Questo particolare simbolo allude agli step di CI\/CD che si ripetono in maniera ciclica: plan, create, verify, package, release (deploy), configure e monitor. <\/p>\n\n\n\n

Si parte sempre dalla pianificazione , poi si sviluppa il codice (in base alle specifiche delineate nella fase di pianificazione), dopodich\u00e9 viene fatta richiesta di integrazione del codice all\u2019interno della code base condivisa, tuttavia, prima di essere integrato viene revisionato (optional) e viene avviata una pipeline di CI\/CD che effettua automaticamente la compilazione (build) e la verifica (test) del codice, fino depositare l\u2019artefatto prodotto dalla build all\u2019interno di un artifact repository (es. per progetti Maven\/Java quello che verr\u00e0 depositato potrebbe essere un JAR e il relativo POM). <\/p>\n\n\n\n

Dopodich\u00e9, la pipeline procede con il rilascio vero e proprio (deploy) del software in produzione.  <\/p>\n\n\n\n

Come gi\u00e0 accennato questo step di deploy pu\u00f2 anche avvenire manualmente nel caso adottiamo la pratica di Continuous Delivery piuttosto che quella del Continuous Deployment. <\/p>\n\n\n\n

Una volta effettuato il deploy, si entra nella fase di operate: qui il team va a testare la stabilit\u00e0 del software ed eventualmente va a configurarlo se necessario. In parallelo, gli utenti finali e\/o i tester iniziano ad utilizzare il software.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Monitoraggio<\/h3>\n\n\n\n

Il software deployato va per\u00f2 anche monitorato! Gli utenti finali e\/o i tester possono segnalare i problemi (issue) durante l\u2019utilizzo del software (es. bug e casi non gestiti), oppure fornire suggerimenti su come migliorarlo o su ci\u00f2 che vogliono sia ancora implementato. <\/p>\n\n\n\n

Tutto questo chiaramente verr\u00e0 affrontato in un una prossima iterazione \/ sprint. Quindi torneremo nuovamente alla fase di pianificazione dove verr\u00e0 aggiornato il backlog in base alle nuove esigenze del progetto e ai bug da fixare, si definiscono delle milestone e le attivit\u00e0 si suddividono in sprint, e si prosegue con il loop (coding, testing, \u2026). <\/p>\n\n\n\n

Nella fase di monitoraggio ci si avvale anche di una serie di tool per appunto monitorare automaticamente le performance del software (es. in termini di CPU\/RAM), oppure per analizzare i log con lo scopo di accorgerci di eventuali errori o in generale di comportamenti anomali degni di attenzione. I dati raccolti in real time vengono poi visualizzati su dashboard grafiche.<\/p>\n\n\n\n

DevSecOps<\/h2>\n\n\n\n

Cosa \u00e8 il DevSecOps? Semplicemente: DevOps + Security. <\/p>\n\n\n\n

Il DevSecOps<\/strong>, chiamato a volte anche SecDevOps, possiamo vederlo come un’estensione del DevOps, che per\u00f2 pone particolare attenzione sulla sicurezza del software che viene rilasciato. La sicurezza diventa parte integrante della qualit\u00e0! <\/p>\n\n\n\n

L\u2019obiettivo \u00e8 quello di riunire tre team (team di development, di operation, e di security) in modo da abbreviare i tempi di rilascio, ridurre i costi, rafforzare la sicurezza ed aumentare la produttivit\u00e0 degli sviluppatori.<\/p>\n\n\n

\n
\"devsecops,<\/figure><\/div>\n\n\n

Lo shift-left \u00e8 applicato anche alla sicurezza: spostiamo verso sinistra (nel ciclo di vita dello sviluppo del software) i controlli sulla sicurezza del software. Piuttosto che affrontare revisioni e ispezioni di sicurezza alla fine del processo e trovare brutte soprese, in questo modo ci pensiamo prima! <\/p>\n\n\n\n

Con il DevSecOps vogliamo incorporare la sicurezza in tutto il ciclo di vita del software in modo da ridurre le vulnerabilit\u00e0 di sicurezza. Tutti sono pi\u00f9 felici in quanto il team DevOps assicurer\u00e0 il rispetto di queste best practice e controlli di sicurezza. <\/p>\n\n\n\n

Nella pipeline di CI\/CD verranno introdotti ulteriori job, racchiusi in opportuni stage, che valutano e verificano la security applicativa, come ad esempio: <\/p>\n\n\n\n