L'età dell'oro delle migliori pratiche del software DevOps si è stabilita su di noi come una comoda coperta di coerenza. All'interno di questa utopia di gestione del cambiamento perfetta e standard industriali ben oliati, è emersa una progressione naturale verso una sicurezza informatica a tenuta stagna chiamata DevSecOps.

Ovviamente, quando dico "età dell'oro" intendo davvero "Far West". E con "comoda coperta di coerenza" intendo davvero "fredda carta di incertezza". Nell'industria tecnologica, l'implementazione di DevOps significa cose diverse per aziende diverse—anche all'interno di alcune aziende, significa cose diverse per team diversi.

Districare DevSecOps

Da quando il termine è stato coniato un decennio fa, il significato di DevOps è rimasto nebuloso, e il panorama odierno rappresenta un miscuglio di flussi di lavoro DevOps. Pilastri come gli strumenti CI/CD hanno visto un'adozione diffusa, mentre prodotti come il software di gestione del flusso di valore sono sparsi tra poche aziende selezionate.

Nel mondo tecnologico, ciò significa che è il momento perfetto per causare una discontinuità—e DevSecOps è proprio la cosa giusta.

Cos'è DevSecOps?

DevSecOps, che sta per Development Security Operations, presenta una necessaria chiamata all'azione confezionata come un insopportabile parola d'ordine. Il messaggio sottostante è urgente e pungente: anche la sicurezza informatica deve essere un predefinito nel flusso di lavoro DevOps (sviluppo e operazioni IT). Data la natura degli ambienti di software di consegna continua, è diventato sempre più difficile per i professionisti della sicurezza informatica ripulire dopo gli sviluppatori. DevSecOps mira a creare codice altamente sicuro per design, piuttosto che dopo il fatto.

(Per quanto riguarda il termine stesso, beh...stabilisce un precedente interessante per le convenzioni di denominazione. Ci sono molti principi benefici che possono—e dovrebbero—integrarsi con processi DevOps di successo, ma non chiamiamolo DevSecPrivMindfulnessAIOps.)

Resta da vedere se il termine DevSecOps rimarrà, ma per ora fa il suo lavoro, mandando brividi lungo la spina dorsale dell'industria. Forse ciò ha più a che fare con la terminologia nauseante che con le sue implicazioni, ma serve comunque come campanello d'allarme per i team di sviluppo sulla reale necessità di codice sicuro. Come rispondono a quella chiamata aziende e team?

Strumenti DevSecOps

I team DevOps hanno bisogno del giusto stack software per realizzare appieno DevSecOps, o sicurezza per design. Inoltre, questi strumenti devono integrarsi senza problemi con le pipeline preesistenti.

In un mondo ideale, il prodotto perfetto per il lavoro automatizzerebbe anche il grosso del carico di lavoro. Gli sviluppatori non seguiranno il ritmo di una forte sicurezza informatica a meno che la soluzione non sia priva di mal di testa. Oltre a qualche solida sessione di formazione e una fornitura costante di ibuprofene, quali sono le opzioni?

Finalmente trovando un po' di stabilità nel mercato dopo alcuni anni di stagnazione, gli strumenti di analisi della composizione del software (SCA) presentano una soluzione automatizzata e senza soluzione di continuità per gli sviluppatori per gestire gli elementi open-source e di terze parti delle loro applicazioni. Il processo di sviluppo delle applicazioni tende ad accumulare rapidamente un impressionante mucchio di dipendenze e componenti di terze parti. Gli strumenti SCA si integrano con i flussi di lavoro DevOps preesistenti per scansionare costantemente questi componenti alla ricerca di vulnerabilità e aggiornamenti, garantendo una sicurezza completa in mezzo alla confusione delle chiamate API. Questi prodotti fanno poi un passo ulteriore e suggeriscono persino rimedi per le vulnerabilità al momento della rilevazione, rendendoli una necessità per qualsiasi spazio DevSecOps emergente.
Altri strumenti legacy che possono essere utilizzati e combinati per creare un ambiente DevSecOps a tenuta stagna includono il software di scansione delle vulnerabilità, il software di test di sicurezza delle applicazioni dinamiche (DAST), il software di test di sicurezza delle applicazioni statiche (SAST), o il software di test di penetrazione...guarda, ci sono molte soluzioni tra cui scegliere. Tutte contribuiscono con un valore unico a un flusso di lavoro DevSecOps.

La metodologia DevSecOps è lontana dall'essere standardizzata

L'abbondanza di diverse soluzioni che affrontano DevSecOps, se davvero lo chiamiamo così, sembra ottima. Tuttavia, l'industria non ha concordato un mix standard di strumenti per un ambiente di lavoro DevSecOps "migliore pratica". Di conseguenza, ci ritroviamo con una filosofia lavorativa vaga, piuttosto che un insieme specifico di procedure da implementare effettivamente. Suona familiare?

Se le aziende vogliono evitare di ripetere il circo dell'implementazione che chiamiamo DevOps, sono partite male. Basta guardare la diffusione dell'uso in questo sondaggio di 57 professionisti della sicurezza informatica attraverso le industrie condotto da ZeroNorth.

Questi risultati non evocano esattamente frasi come "standard industriale" o "tutto va bene". Su sette possibili strumenti di scansione e test, solo uno vede un uso a livello aziendale da parte di più di un quarto dei professionisti intervistati. Il che è particolarmente preoccupante quando ci si rende conto che non è nemmeno il dataset completo.

Questo particolare grafico ha dovuto essere diviso su due pagine diverse del rapporto di ZeroNorth. E certo, forse avrebbero potuto rendere il carattere un po' più piccolo. Ma è comunque un totale di 12 diversi tipi di strumenti di sicurezza informatica validi—tutti con implementazioni estremamente variabili nell'industria.

Lo stesso rapporto ha rilevato che il 98% dei professionisti considera la sicurezza informatica in DevOps come "estremamente importante" o "molto importante". Tutti generalmente concordano sul fatto che i team DevOps devono adottare le migliori pratiche di sicurezza informatica, ma tutti hanno idee diverse su cosa significhi. Questo problema è intrinseco a filosofie vaghe come "DevOps" e "DevSecOps": ogni team interpreterà queste filosofie in base al proprio flusso di lavoro e cultura interni.

Il futuro di DevSecOps nelle iniziative DevOps e CI/CD

Basandosi sul sentimento diffuso nell'industria per una migliore sicurezza nell'era della trasformazione digitale, sembra probabile che la filosofia DevSecOps sia qui per restare. La domanda è se quella filosofia porterà a un'applicazione standardizzata—e quanto tempo ci vorrà. Se il decennio passato di DevOps è un indicatore, probabilmente vedremo un mosaico di implementazioni alimentate da parole d'ordine e sogni.

Tuttavia, è possibile che l'esperienza diffusa nell'industria con DevOps abbia preparato per sforzi di trasformazione digitale più efficaci in futuro. Ora che le aziende hanno trovato il loro equilibrio con il cloud, DevOps e iniziative CI/CD, un nuovo brillante aggiunta all'ambiente di lavoro potrebbe risultare meno eterea. Forse l'urgenza cruciale per la sicurezza motiverà un fronte unificato.

Qualunque forma assuma, possiamo aspettarci di vedere grandi cambiamenti verso DevSecOps in tutti i settori in futuro. Potrebbero esserci dolori di crescita lungo la strada, specialmente se gli sviluppatori e i partner commerciali vedono le nuove iniziative di sicurezza come ostacoli all'interno di flussi di lavoro efficienti. Tuttavia, le aziende devono trovare modi per far funzionare un DevOps sicuro se vogliono evitare il rischio di costosi fiaschi di sicurezza.