Oggi si parla molto di DevSecOps ed esistono diversi strumenti che consentono di aggiungere alle nostre pipeline controlli automatici alla ricerca di vulnerabilità note nelle dipendenze del nostro software (librerie), nelle immagini dei container (dipendenze del sistema operativo), ma anche nelle configurazioni della nostra infrastruttura o del nostro cluster Kubernetes. Per la parte software gli strumenti si appoggiano a degli archivi pubblici che raccolgono le CVE (Common Vulnerabilities and Exposures) note, per la parte di infrastruttura e configurazione sfruttano l'insieme di buone pratiche messe a punto da organizzazioni quali CIS (Center for Internet Security) o NSA (National Security Agency). Si tratta comunque di regole predefinite, che se da un lato ci consentono di controllare vulnerabilità o errori di configurazione che possono affliggere il nostro software o la nostra infrastruttura, dall'altro poco hanno a che fare con quelle che possono essere le necessità specifiche di un progetto o di un dato team o azienda. Ad esempio, se delle policy aziendali imponessero che tutti gli elementi di infrastruttura (Object storage, Virtual Machine etc…) debbano essere creati solo in determinate regioni? oppure che tutte le risorse Kubernetes debbano avere delle label specifiche o debbano essere create in un dato namespace? come possiamo fare l'enforcing di queste regole in modo totalmente automatico? In questo talk vi mostrerò come sia possibile automatizzare questo genere di controlli scrivendo delle regole in Rego, il linguaggio nativo utilizzato dal progetto Open Policy Agent (OPA) e utilizzando uno noto security scanner Open Source chiamato Trivy.

Comments

Comments are closed.

Bellissimo talk, l'argomento era molto ben definito. Sicuramente ci sprona ad accelerare la transazione a IaC per tutti i progetti.