devsecopsday 2023
13 Oct 2023 at Savoia Regency Hotel

4

Gli attacchi alla supply chain sono in aumento e lo stesso ciclo di vita dello sviluppo del software (SDLC) è diventato un vettore di attacchi. I recenti attacchi a Log4J, SolarWinds, Kaseya e Codecov hanno evidenziato le aree vulnerabili esposte nel SDLC. In questo intervento discuteremo della crescente minaccia di attacchi alla supply chain, di come le organizzazioni possono adottare misure per proteggersi e una panoramica sul futuro. Verranno trattati argomenti quali: - Condurre valutazioni periodiche della sicurezza dei fornitori di terze parti - Implementazione di solidi controlli di sicurezza per lo sviluppo e la distribuzione del software - Investire in strumenti e tecnologie che aiutino a identificare e mitigare i rischi della catena di fornitura.

3

Con l'aumento della complessità delle software supply chain, è fondamentale avere un modello in grado di gestire i rischi associati. In questo talk, si partirà dalla definizione di una supply chain, elencando i possibili vettori di compromissione e si forniranno possibili soluzioni e framework da poter adottare. Utilizzeremo come esempio il framework del CNCF Security Technical Advisory Group, in quanto un approccio globale alla sicurezza della software supply chain. Ne esamineremo da vicino i vari componenti, partendo dalla fase di sviluppo del codice fino a quella di rilascio. Esploreremo come possa essere utilizzato per gestire i rischi e forniremo indicazioni su come implementarlo all'interno di una organizzazione. Sia che tu sia developer, security expert o manager nella tua azienda, ti forniremo gli strumenti necessari per effettuare i primi passi verso la protezione della tua software supply chain.

4

In questo talk vedrai esempi pratici di come proteggere la tua catena di produzione del software attraverso strumenti open source come Tekton e Sigstore e l’adozione delle specifiche SLSA (Supply-chain Levels for Software Artifacts) della Open Source Security Foundation. Imparerai come certificare il software in modo conforme alle suddette specifiche utilizzando Tekton Chains, esplorerai diversi metodi di firma digitale, tra cui il keyless signing di Sigstore Fulcio, e come usare il transparency log di Sigstore Rekor.

2

Nell’era del DevSecOps e delle tecnologie cloud-native, il paradigma “shift-left” è emerso come un approccio vincente per le strategie di cybersecurity. Questo “shift” enfatizza l’integrazione precoce delle policies di sicurezza nel ciclo di sviluppo di una applicazione erogata su Kubernetes. Centrale per questo approccio è la metodologia Security-as-Code, che prevede l’applicazione di policies di sicurezza in modo dichiarativo. Con questa metodologia le policies di sicurezza diventano parte di una applicazione, così come qualsiasi altra risorsa Kubernetes (deployment, services, …). Questo approccio consente ai team di sviluppo di perfezionare le policies di sicurezza in ambienti meno critici e applicare policies rigorose in produzione, minimizzando i rischi di cybersecurity e assicurando una difesa robusta e scalabile per le applicazioni containerizzate. Per illustrare il valore di queste metodologie mostreremo una demo illustrando in che modo NeuVector e le sue potenzialità possono rendere possibile un approccio solido alle tematiche illustrate.

6

Hai appena scoperto dell'esistenza dei service account, e come Peter Parker quando scopre di poter sparare ragnatele dalle mani, anche tu non vedi l’ora di mettere alla prova il tuo nuovo superpotere. Ma cos’è di preciso un service account? Come può essere efficacemente integrato in un prodotto e in ambiente cloud? E se fosse potenzialmente pericoloso? Durante lo sviluppo di una funzionalità inedita per la gestione dei service account per il prodotto della mia azienda, mi sono confrontata con questi e altri interrogativi. Aspetti come la gestione dei permessi da assegnare, l'impostazione della scadenza e delle notifiche di scadenza dei service account, così come l'amministrazione del rinnovo delle loro credenziali, sono argomenti che non possono essere sottovalutati. Trovare risposte adeguate a queste domande è diventato fondamentale specialmente quando mi è stato chiesto di documentare questa nuova funzionalità, con l'obiettivo di metterne in risalto non solo le opportunità, ma soprattutto i potenziali rischi. In questa presentazione, vi guiderò attraverso la mia esperienza personale con i service account e la creazione di funzionalità per la loro gestione, mettendo in evidenza le enormi possibilità ma anche i pericoli che un approccio non sicuro può comportare. Unitevi a me in questo viaggio: insieme, acquisiremo le competenze e gli strumenti necessari per navigare in questo scenario con (un po') più di sicurezza.

2

Container, Platform Engineering, Internal Developer Platform sono i nuovi "Game Changer" del DevOps: oltre a permettere un miglioramento della velocità di onboarding di nuovi Team portano anche a un miglioramento della stabilità e standardizzazione dei processi e delle risorse, con conseguenze positive sulla sicurezza dei sistemi. Tuttavia, ancora oggi alcune problematiche già note in passato rimangono irrisolte: la distanza tra l'ambiente di sviluppo locale e l'ambiente di integrazione remoto è tutt'ora un problema ricorrente. Controlli su codice, test di integrazione e analisi delle vulnerabilità, ad esempio, sono attività sempre più presenti nelle pipeline di integrazione, spesso però tralasciate durante lo sviluppo locale. Avvicinare questi controlli e test allo sviluppatore non solo riduce i tempi per ricevere feedback, con conseguenze positive sui tempi di sviluppo, ma aiuta anche ad aumentare la consapevolezza di chi sviluppa in merito agli aspetti critici del proprio software. Una maggiore consapevolezza in questo ambito può portare a processi di sviluppo più sicuri, efficienti ed efficaci. Affidare a chi sviluppa la responsabilità di definire e gestire controlli di sicurezza e qualità porta a un aumento del loro carico cognitivo, senza garantire un effettivo miglioramento del ciclo DevOps: in questo talk vedremo come e con che strumenti sia possibile fornire loro un modo per anticipare i controlli di sicurezza, ridurre pratiche di sviluppo rischiose e aumentare la consapevolezza sulla sicurezza del proprio codice.

2

Il GitOps sta diventando sempre più popolare soprattutto quando si comincia a parlare di Kubernetes. Ovviamente con l'avvento di nuove tecnologie e best practice, nascono anche nuovi dubbi, tipo: Come posso gestire i miei secret avendo a che fare con il GitOps?

1

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.

0

Rilevare prontamente minacce alla sicurezza rivolte al cluster ed alla piattaforma ospitante è di cruciale importanza, poiché permette di intervenire sfruttando un elemento chiave: Il tempo. Durante il talk vedremo come poter utilizzare due tool dell'ecosistema CNCF per tale scopo. Il primo, Prometheus, largamente conosciuto, ci permetterà anche di inviare notifiche push agli amministratori del cluster. Il secondo, Falco, sarà il nostro occhio che vigilerà sui tentativi di intrusione. Inizieremo descrivendo le loro caratteristiche e potenzialità, per poi passare ad una implementazione, mostrando come sono integrati tra loro e come possono avvisare gli admin in modo proattivo. Al termine della sessione avrete tutti gli spunti necessari per iniziare con la vostra implementazione.