Supply chain del software sicura distribuisci il software nell'ambiente di produzione in modo rapido e sicuro

L'implementazione di una supply chain del software sicura è parte integrante della protezione dello sviluppo di software e dell'accelerazione delle funzionalità DevSecOps.

Cosa è una supply chain del software sicura?

Una supply chain del software sicura è il set di processi impiegati per distribuire il software (incluse tutte le sue dipendenze) nell'ambiente di produzione in modo sicuro, affidabile e coerente, con aggiornamenti periodici al codice sorgente e controlli definiti per la governance della piattaforma.

Una supply chain del software sicura fornisce la certezza che il codice e le relative dipendenze siano affidabili, compliant, aggiornati e pronti per il rilascio e assicura che vengano eseguite analisi periodiche per rilevare, segnalare ed eliminare vulnerabilità. Inoltre, con un set definito di policy applicate in modo coerente in tutti i sistemi della catena, impedisce l'accesso non autorizzato e l'esecuzione di pacchetti non firmati.

---

Best practice per una supply chain del software sicura

Per sviluppare una supply chain del software sicura, hai bisogno di un set di strumenti e procedure che consentano alla tua organizzazione di distribuire pacchetti software (proprietari e di terze parti) dal codice sorgente fino alla produzione, a livelli di qualità e velocità sostenuti rispetto al tuo livello di rischio accettato.

VMware ha identificato cinque aree di interesse per lo sviluppo di software sicuro che permetteranno alle organizzazioni di integrare la sicurezza nello sviluppo di software agile e aiuteranno a mitigare gli attacchi alla supply chain del software.

1. 1. Protezione del codice sorgente delle applicazioni

   Nell'ambito del ciclo di sviluppo del software, la parte della supply chain su cui hai maggiormente controllo è costituita dal codice che scrivi. È inutile avere una supply chain sicura se poi questa invia codice non sicuro. Implementando strategie per assicurare che il codice sia protetto, puoi contribuire a mitigare gli attacchi alla supply chain.

   Best practice

   • ◼ Mettere gli sviluppatori nelle condizioni di supportare la predisposizione alla sicurezza negli ambienti di produzione.
   • ◼ Implementare il controllo degli accessi per i repository di codice al fine di impedire modifiche non autorizzate e indesiderate.
   • ◼ Utilizzare il linting del codice o l'accesso al codice statico per individuare errori comuni a livello di codice in fase di sviluppo, prima che si trasformino in bug di produzione a rischio di exploit.
   • ◼ Includere la revisione paritaria del codice per evitare le vulnerabilità non intenzionali introdotte per errore e quelle introdotte volontariamente per finalità dannose da un utente malintenzionato.
   • ◼ Applicare la gestione dei segreti in modo che il codice sorgente sia privo di credenziali e configurazioni sensibili, al fine di prevenire un attacco se il codice viene divulgato, sottoposto a decompilazione o altrimenti reso pubblico.
   • ◼ Usare Static App Security Testing (SAST), un tipo di test per la sicurezza del software, che consente di analizzare il codice sorgente e cercare schemi di codifica che corrispondano a pratiche di codifica deboli note.
   • ◼ Impiegare la funzione di analisi della composizione del codice sorgente (SCA) per verificare le librerie, i framework e i componenti di terze parti utilizzati nell'applicazione.

   Risultati

   • ◼ Gli sviluppatori di app sono in grado di sviluppare codice di alta qualità seguendo best practice di sicurezza.
   • ◼ Tutti i commit nel repository sono attendibili.
   • ◼ Il codice sorgente è privo di segreti o di altri dati sensibili dell'ambiente.
2. 2. Gestione delle dipendenze delle app

   Pochi sviluppatori iniziano da zero quando creano le loro build. Per risparmiare tempo e accelerare l'attività di sviluppo, possono usare codice preconfezionato di cataloghi Open Source e di altro tipo. Questo significa che il software deve tenere conto dei frammenti di codice preconfezionato integrato nella build finale durante la fase di ricerca delle vulnerabilità e installazione di patch nell'app in produzione.

   Per garantire processi sicuri di sviluppo e progettazione del software, i team devono essere in grado di visualizzare chiaramente le dipendenze delle applicazioni. L'esecuzione di analisi periodiche per verificare che in tutte le librerie dipendenti siano installate patch e siano assenti CVE (Common Vulnerabilities and Exposures) riduce il rischio che una dipendenza possa essere sfruttata.

   Best practice

   • ◼ Incorporare l'analisi periodica delle vulnerabilità delle dipendenze per assicurare l'installazione di patch e l'assenza di CVE in tutte le librerie dipendenti.
   • ◼ Installare patch per le dipendenze vulnerabili in modo tempestivo.
   • ◼ Usare l'associazione delle dipendenze (file di blocco) a specifiche versioni verificate per evitare che vengano introdotte nuove vulnerabilità aggiornando involontariamente una dipendenza.
   • ◼ Valutare la possibilità di sfruttare dipendenze acquisite da origini note e attendibili, utilizzate da un numero elevato di sviluppatori, che possono avere meno probabilità di essere compromesse rispetto a quelle provenienti da origini meno affidabili.
   • ◼ Individuare con esattezza le dipendenze in uso. Le applicazioni moderne sono spesso costituite da decine di dipendenze, se non di più, che creano un vettore di attacco in cui le vulnerabilità vengono introdotte ai livelli più profondi nella gerarchia delle dipendenze.
   • ◼ Riflettere sull'opportunità di acquisire una nuova dipendenza. In alcuni casi, è possibile ridurre al minimo la superficie di attacco evitando di acquisire dipendenze di grandi dimensioni.
   • ◼ Valutare la possibilità di eseguire aggiornamenti alle dipendenze esistenti. I vendor di software spesso distribuiscono aggiornamenti da un server centralizzato nell'ambito delle attività di manutenzione di routine. Un hacker in grado di infiltrarsi nella rete del vendor può inserire malware in ciò che appare come un normale aggiornamento di un prodotto.
   • ◼ Esercitarsi nella gestione dei rischi.

   Risultati

   • ◼ Gli sviluppatori possono convalidare in modo sicuro l'origine delle dipendenze interne e di terze parti.
   • ◼ I team responsabili delle app possono visualizzare l'intera distinta base del software dell'applicazione.
   • ◼ Le parti interessate possono identificare rapidamente le applicazioni potenzialmente vulnerabili a CVE.
   • ◼ È garantita l'installazione di patch più agevole per le vulnerabilità delle dipendenze di applicazioni.
3. 3. Protezione dei sistemi CI/CD

   La governance è un aspetto importante del controllo della pipeline CI/CD (integrazione continua/distribuzione continua). L'implementazione e la corretta configurazione delle autorizzazioni per l'uso dei sistemi contribuiscono a proteggere la supply chain del software. Ciò include il principio dei privilegi minimi richiesti.

   Best practice

   • ◼ Implementare il controllo degli accessi per le pipeline CI/CD e impedire tentativi di aggiramento nelle pipeline eliminando le porte laterali.
   • ◼ Usare account di sistema con i privilegi minimi richiesti per eseguire processi, attività e script nelle pipeline di automazione.
   • ◼ Eseguire deployment basati su pull anziché su push. Quando si eseguono deployment basati su push, è necessario esporre le credenziali all'esterno del sistema di destinazione. Negli scenari di deployment basati su pull, le credenziali del sistema di destinazione non vengono esposte, ma i controller sincronizzano le modifiche di stato dai repository Git (GitOps) o dai registri delle immagini.
   • ◼ Utilizzare la gestione delle credenziali per le pipeline CI/CD e verificare che gli strumenti di deployment richiedano credenziali per l'accesso agli ambienti più sensibili.
   • ◼ Generare e archiviare audit trail e registri di build.

   Risultati

   • ◼ Gli sviluppatori possono convalidare in modo sicuro l'origine delle dipendenze interne e di terze parti.
   • ◼ I team responsabili delle app possono visualizzare l'intera distinta base del software dell'applicazione.
   • ◼ Le parti interessate possono identificare rapidamente le applicazioni potenzialmente vulnerabili a CVE.
   • ◼ È assicurata l'installazione di patch più agevole per le vulnerabilità delle dipendenze di applicazioni.
4. 4. Protezione della creazione e del registro delle immagini

   Per una maggiore protezione delle immagini dei container, l'obiettivo è quello di ridurre il numero di CVE a rischio elevato nel registro delle immagini e il tempo richiesto per correggerle. A tale scopo, è possibile verificare che le immagini di base siano attendibili e firmate e che siano applicate policy di controllo per il repository delle immagini.

   Best practice

   • ◼ Implementare policy di controllo e degli accessi per i repository di immagini. Tutti i riferimenti alle immagini in uso devono essere stati autorizzati e convalidati da un processo CI automatizzato, riducendo al minimo l'accesso all'esterno.
   • ◼ Utilizzare un set ridotto di immagini di base approvate per ridurre l'area della superficie di attacco. Verificare che le immagini di base siano firmate e sottoposte al controllo delle versioni. Le immagini di base attendibili vengono determinate, rese disponibili e utilizzate per la build.
   • ◼ Archiviare le immagini delle app e/o gli artefatti in una posizione sicura. Applicare policy di controllo per i repository delle immagini e verificare che queste ultime siano firmate quando vengono archiviate in un registro.
   • ◼ Aggiornare il database delle vulnerabilità e usarlo per eseguire analisi delle vulnerabilità delle immagini regolarmente pianificate.
   • ◼ Utilizzare una build di immagine sicura, riproducibile e prodotta utilizzando un set noto di soli artefatti attendibili. Assicurare l'introduzione di backdoor durante la creazione è difficile ed è un'operazione rilevabile.
   • ◼ Tracciare gli artefatti promossi in produzione per assicurarsi che agli ambienti superiori vengano promossi gli stessi artefatti utilizzati per i test. Sono disponibili audit trail.
   • ◼ Utilizzare il tagging delle immagini.
   • ◼ Convalidare le attestazioni.

   Risultati

   • ◼ Le immagini delle applicazioni vengono firmate per garantirne l'integrità.
   • ◼ Le immagini vengono archiviate in un registro sicuro.
   • ◼ È assicurata l'attendibilità degli artefatti distribuiti.
   • ◼ Le vulnerabilità delle immagini risultano visibili.
   • ◼ La correzione delle vulnerabilità delle immagini può essere gestita agevolmente.
5. 5. Protezione del runtime

   L'implementazione di architetture zero-trust e di soluzioni di gestione delle informazioni di sicurezza e degli eventi (SIEM), unitamente agli strumenti di rilevamento delle minacce avanzate, crea un ambiente più sicuro per le applicazioni e la relativa piattaforma di sviluppo. L'integrazione dell'osservabilità nelle operation della piattaforma consente di monitorare il runtime e conoscere le prestazioni delle app.

   Best practice

   • ◼ I tecnici della sicurezza devono essere in grado di rilevare gli attacchi mettendo in correlazione una serie di eventi, possibilmente tramite uno strumento SIEM, e altri strumenti di rilevamento delle minacce capaci di identificare determinati eventi indicanti che un hacker è riuscito a ottenere l'accesso.
   • ◼ Utilizzare l'analisi delle vulnerabilità del runtime per identificare vulnerabilità negli ambienti Kubernetes.
   • ◼ Implementare un livello di networking sicuro per impedire agli hacker di ottenere l'accesso a una rete e attraversarla senza problemi per raggiungere altri ambienti e reti attendibili. La protezione dei dati in transito tramite comunicazioni sicure è essenziale per evitare lo sniffing del traffico di rete da parte di un hacker.
   • ◼ Usare una strategia multi-tenancy sicura. Adottare una strategia con spazi dei nomi e cluster per l'isolamento, aggiungendo il controllo degli accessi in base al ruolo.
   • ◼ Configurare in modo appropriato l'ambiente di sviluppo per evitare violazioni della sicurezza spesso causate da errori di configurazione nell'infrastruttura.
   • ◼ Utilizzare la gestione dei segreti per assicurare che vengano distribuiti nelle app e nei servizi che li richiedono e che tali servizi e app possano accedere ai soli segreti necessari per poter funzionare. Ciò consente di ridurre la superficie di attacco e l'impatto di una potenziale violazione.
   • ◼ Implementare l'accesso sicuro all'ambiente per assicurarsi che possano accedere solo gli utenti autorizzati. A tale scopo, possono risultare appropriati più controlli di sicurezza diversi. Gli accessi non autorizzati devono essere rilevabili.
   • ◼ Utilizzare test dinamici della sicurezza delle app ("black box") per individuare vulnerabilità della sicurezza e punti deboli in un'applicazione in esecuzione.
   • ◼ Impedire l'esecuzione di immagini non firmate in un ambiente di produzione.
   • ◼ Ridurre il tempo necessario per correggere le vulnerabilità della sicurezza nella supply chain.
   • ◼ Implementare l'applicazione uniforme delle policy. Determinare, applicare e testare policy di sicurezza, audit dei registri, policy di compliance e policy di rete.
     • Le policy di sicurezza e di accesso vengono applicate in modo coerente.
     • Il sistema rifiuta di eseguire codice che non proviene dalla supply chain del software sicura.
     • È facile commettere errori nella scrittura di policy (rego): svilupparle con attenzione, eseguendo i test appropriati.
     • Testare le policy integrate per evitare conflitti.

   Risultati

   • ◼ È garantito l'isolamento dei carichi di lavoro per evitare che quelli vicini possano influenzarli, accedervi o interferire con essi.
   • ◼ Le comunicazioni tra i servizi sulla rete sono sicure e affidabili.
   • ◼ Gli sviluppatori possono visualizzare rapidamente le CVE delle applicazioni.
   • ◼ La piattaforma di hosting dei carichi di lavoro è sicura, aggiornata e ricca di funzionalità.

L'importanza di una supply chain del software sicura

Negli ultimi anni l'attenzione sullo sviluppo del software è aumentata enormemente con l'acuirsi degli attacchi alla supply chain. Di recente, l'Executive Order on Improving the Nation's Cybersecurity ha delineato le best practice di sicurezza della supply chain per le organizzazioni, con l'obiettivo di gestire situazioni in cui gli hacker hanno ottenuto accesso al processo di sviluppo e inserito malware nel codice sorgente. Il malware si è propagato a valle nel software pubblicato e ha consentito agli hacker di sottrarre informazioni alle organizzazioni che eseguivano l'applicazione. L'Executive Order fornisce l'opportunità alle organizzazioni negli Stati Uniti di sviluppare supply chain del software più sicure ed evitare casi di compromissione che possano interrompere funzioni critiche dell'infrastruttura.

Comprendere e mitigare le vulnerabilità nel percorso verso la produzione aiuta a ridurre i rischi degli investimenti aziendali, offre l'opportunità di distribuire rapidamente agli utenti finali software più sicuro ed elimina i punti di frizione per gli sviluppatori che distribuiscono il codice. Tanzu fornisce soluzioni per set di strumenti sicuri con misure di sicurezza definite da operatori, particolarmente apprezzate dagli sviluppatori. Gli esperti di Tanzu Labs collaborano al tuo fianco per creare processi per la tua organizzazione in grado di migliorare la collaborazione tra i team di sviluppo e sicurezza. Ti aiuteremo a ottimizzare le pratiche DevOps con le nostre comprovate soluzioni e ti spiegheremo come iniziare a proteggere il tuo percorso di sviluppo delle applicazioni su una piattaforma sicura in cui creare idee che apportino valore al tuo business.