Il concetto di sicurezza è tradizionalmente visto come un ostacolo all’innovazione. I team DevOps vogliono essere liberi di esplorare la propria creatività e abbracciare tecnologie cloud-native, come Docker, Kubernetes, PaaS e le architetture serverless, ma la sicurezza impone politiche e protocolli che limitano la libertà di scelta. Si tratta di un aspetto particolarmente problematico se ci si trova di fronte a soluzioni isolate. Questo approccio frammentato aggiunge complessità e aumenta la mole di lavoro dei team IT, che a loro volta diventano più difensivi nella gestione del rischio.
Il 99% dei programmi software commerciali include almeno un componente open source, ubiquità che li rende un bersaglio gradito agli hacker. Non sorprende quindi che nel 2021 si sia registrato un aumento del 650% rispetto all’anno precedente degli attacchi, perpetuati all’interno delle comunità open source grazie alle sue principali debolezze.
Una sola vulnerabilità può costare milioni di euro in multe e ancora di più in perdita di fiducia. Le aziende devono essere consapevoli di quale open source abbiano implementato e di quanto attivamente lo stiano gestendo.
La gestione di questi rischi è più facile a dirsi che a farsi. Se si gestisce la sicurezza internamente, l’investimento in conoscenze e personale non deve essere sottovalutato.
“Sapete che software avete in esecuzione? È compatibile con la sicurezza della vostra infrastruttura? Avete i mezzi per identificare le vulnerabilità? Siete in grado di risolvere i problemi che trovate?”. Queste sono solo alcune delle domande base che un team di sicurezza deve porsi. Se le risposte dovessero dare un responso negativo, cosa dovrebbe fare l’organizzazione? Ad esempio, smettere di usare l’open source? No, è altrettanto rischioso. Nel 2021 sono state introdotte sei milioni di nuove versioni di software open source, che hanno aiutato le organizzazioni a promuovere l’innovazione e, in ultima analisi, i profitti.
Una sicurezza che dice “sì”
C’è un altro modo. Con esso i rischi di sicurezza intrinsechi al software open source possono essere mitigati senza impiegare significative risorse interne per affrontare le sfide. Un modo in cui la sicurezza non equivalga a un “no” quando qualcuno dice: “Voglio provare questo, voglio lavorare con questo strumento”. Piuttosto, la sicurezza dovrebbe diventare il motivo per cui si può dire “sì”.
La sicurezza è fondamentalmente una questione di cultura, più precisamente una cultura aperta. In essa, innovazione e sicurezza non sono agli antipodi ma diventano intercambiabili. Si tratta di sicurezza e sviluppo, ovvero di DevSecOps.
La sicurezza non è più isolata a un team specifico nella fase finale dello sviluppo. Con i rapidi cicli di rilascio di oggi, essa deve essere integrata nei flussi di lavoro DevOps, invece di essere aggiunta quando l’applicazione sta per essere distribuita in produzione. Questo spesso richiede cambiamenti organizzativi, pratiche di lavoro diverse e un reset culturale.
Il 78% delle organizzazioni intervistate per lo “State of Kubernetes Security Report 2022” di Red Hat ha attualmente in corso un’iniziativa DevSecOps e il 27% sta integrando e automatizzando la sicurezza nell’intero ciclo di vita delle applicazioni.
Ad ogni modo, la trasparenza è fondamentale, in quanto trasforma la sicurezza da qualcosa di segreto a qualcosa di condiviso. Tutti la possiedono e tutto avviene pubblicamente. Open source significa più persone che identificano una vulnerabilità, più persone che indagano, più persone che sviluppano e testano la patch e più utenti finali consapevoli e quindi in grado di intervenire.
Le vulnerabilità sono apprezzate, ma è necessario trovarle velocemente, risolverle velocemente e imparare da esse. Si tratta di uno sforzo di gruppo in cui una maggiore partecipazione e apertura migliorano il lavoro degli IT.
La grande sfida per la sicurezza dell’open source è in realtà rappresentata dal fatto che gli strumenti e le tecnologie DevOps – pensiamo ai container, a Kubernetes, a Docker, ai microservizi – sono altamente personalizzabili, con varie opzioni di configurazione che possono influire sulla sicurezza di un’applicazione. Una configurazione errata è una minaccia. L’automatizzazione della gestione della configurazione, in modo che sia la tecnologia (e non l’uomo) a fornire le protezioni, allevia questi problemi.
Conoscere la propria fonte
La provenienza è comunque importante. Sapere da chi si ottiene l’open source è la prima linea di difesa. Una delle cose più belle dell’open source è che qualsiasi organizzazione di qualsiasi dimensione può adottare e utilizzare liberamente tali tecnologie. L’aspetto negativo è l’investimento che si deve effettuare per garantire che questi progetti siano adeguatamente rivisti, controllati e protetti dagli sviluppatori prima di essere messi in produzione.
In alternativa, si può cercare un software open-source fornito da aziende che eseguono i controlli di sicurezza e gli aggiornamenti per i clienti. Meno sono i fornitori di software, meno sono i partner di cui ci si deve fidare o a cui si deve chiedere assistenza. Meno sistemi significano anche meno complessità e quindi meno lavoro da fare. La lista della spesa dovrebbe includere:
- software ottenuto da reti di distribuzione controllate, sicure e autentificate;
- codice conservato in archivi interni sicuri;
- pacchetti firmati e con forti garanzie contro la manomissione e soggetti a modifiche minime del codice durante la vita del prodotto.
Oltre la sicurezza
Lasciare la sicurezza all’ultimo posto, significa intromettersi, interrompere, limitare e, alla fine, distogliere l’attenzione e le risorse dalle attività che possono davvero aiutare l’azienda a crescere.
Se invece è integrata fin dall’inizio nel pacchetto software, nei processi di sicurezza del distributore e nella piattaforma di distribuzione, la sicurezza guida l’innovazione, permettendo di rendere l’azienda un ambiente che funziona in background garantendo silenziosamente che la produttività non venga compromessa.