Distribuzione del software in modo sicuro

Velocità e time to market sono le priorità principali per le organizzazioni di tutto il mondo che creano software e applicazioni per soddisfare le esigenze dei clienti. Questi imperativi strategici sono stati la vera forza dell'eccezionale crescita dei container come piattaforma preferita. Grazie ai molti vantaggi dei container tra cui time to market più rapido, maggiore disponibilità, sicurezza rafforzata, migliore scalabilità e riduzione dei costi, nell'ultimo anno molte di queste organizzazioni hanno iniziato a prendere in considerazione anche un approccio serverless.

Sebbene le soluzioni software abbiano ridotto i tempi necessari per offrire una nuova funzionalità o anche un nuovo prodotto, molte delle pratiche di sicurezza esistenti non sono in grado di tenere il passo con l'aumento della velocità, il che genera tre problemi:

1. Gli sviluppatori vengono rallentati dai processi esistenti, con conseguenti ritardi.
2. I team addetti alla sicurezza e alle operazioni devono trovare dei compromessi che espongono l'organizzazione a possibili minacce.
3. I team di sviluppo lavorano sulla base di processi di sicurezza esistenti per rispettare le scadenze, il che li rende vulnerabili.

Negli ultimi anni si sono verificate molte violazioni della sicurezza classificate come attacchi alla "catena di fornitura del software".

Nel dicembre 2021 è stata identificata Log4Shell , una vulnerabilità pericolosa nel software Apache Log4j. Segnalata con il punteggio massimo CVSS pari a 10, questa vulnerabilità è stata particolarmente devastante a causa della popolarità di Log4j, un framework di logging basato su Java. Due fattori hanno contribuito ad aumentarne la gravità. Il primo è che era una vulnerabilità molto facile da sfruttare, che ha permesso l'esecuzione completa del codice da remoto. Il secondo è che spesso aveva molti livelli di profondità nella struttura delle dipendenze e, di conseguenza, veniva facilmente ignorata.

Solarwinds, un'azienda di software IT, è stata attaccata da hacker nazionalisti che hanno inserito codici dannosi in build ufficiali di software open source in uso presso l'azienda. Questo aggiornamento dannoso è stato inviato a 18.000 clienti, inclusi i Dipartimenti del Tesoro e del Commercio degli Stati Uniti.

Kaseya, un'altra azienda di software per la gestione informatica, è stata attaccata da una vulnerabilità zero-day che ha compromesso il server VSA Kaseya in uso e ha inviato uno script dannoso per fornire un ransomware che cripta tutti i file sui sistemi interessati.

L'urgenza di rispondere a questi e altri incidenti simili ha portato la Casa Bianca a emettere nel maggio del 2021 un ordine esecutivo che richiede alle organizzazioni che hanno relazioni commerciali con il governo federale di mantenere determinati standard per la sicurezza del software.

Per molti aspetti, il termine "catena di fornitura del software" è particolarmente appropriato: i processi per la creazione di una catena di fornitura del software sono molto simili a quelli previsti per la produzione di un'auto.

Un produttore di automobili impiega vari pezzi di altre aziende, produce componenti proprietari e li integra tutti insieme mediante un processo altamente automatizzato. Il produttore garantisce la sicurezza delle sue operazioni assicurando che ogni componente di terze parti provenga da una fonte attendibile. I componenti proprietari vengono testati con grande cura per garantire che non abbiano problemi di sicurezza. Infine, l'assemblaggio viene svolto seguendo un processo affidabile che porta alla produzione finale dell'automobile.

La catena di fornitura del software è simile sotto molti aspetti. Un produttore di software impiega componenti di terze parti, spesso open source, per eseguire funzioni specifiche e sviluppa un proprio software, che è la sua proprietà intellettuale principale. Il codice viene quindi eseguito attraverso un processo di compilazione che combina questi componenti in artefatti di cui può essere eseguito il deployment e che, successivamente, passano alla fase di produzione.

Basta un solo anello non protetto per violare la catena di fornitura del software.

Come nel caso degli attacchi di alto profilo dell'anno scorso, ciascuno dei passaggi del processo può generare una vulnerabilità che può essere sfruttata da utenti malintenzionati.

Ad esempio, un pacchetto npm ha in media 12 dipendenze dirette e circa 300 dipendenze indirette. Inoltre, sappiamo che quasi il 40% di tutti i pacchetti npm pubblicati dipende da un codice con vulnerabilità note.

Queste vulnerabilità potrebbero inficiare la sicurezza del codice, ad esempio nascondendosi in una libreria che non viene mai utilizzata. È comunque obbligatorio verificare sempre queste vulnerabilità.

La portata di questo problema è enorme. Se anche una sola di queste vulnerabilità non viene corretta, gli utenti malintenzionati potrebbero avere accesso alla catena di fornitura del software.

Google realizza applicazioni su scala globale da decenni. Nel corso del tempo abbiamo reso open source molti dei nostri progetti interni per contribuire a incrementare la velocità degli sviluppatori. Allo stesso tempo, abbiamo sviluppato diverse procedure interne per rendere più sicura l'esperienza nel campo del software.

Ecco alcune delle nostre iniziative volte a rafforzare le catene di fornitura del software ovunque.

• Aumento degli investimenti: ad agosto 2020 abbiamo annunciato che nei cinque anni successivi avremmo investito 10 miliardi di dollari per rafforzare la cybersicurezza, ad esempio espandendo i programmi Zero Trust, contribuendo a proteggere la catena di fornitura del software e migliorando la sicurezza open source.
• Supply-chain Levels for Software Artifacts (SLSA): si tratta di un framework end-to-end per l'integrità della catena di fornitura. È un equivalente open source di molti processi che abbiamo implementato internamente a Google. Gli SLSA permettono di verificare la provenienza delle build e della loro realizzazione.
• DevOps Research and Assessment (DORA): il nostro team DORA ha condotto un programma di ricerca di sette anni che ha convalidato una serie di funzionalità tecniche, dei processi, di misurazione e culturali per potenziare la distribuzione del software e le prestazioni dell'organizzazione.
• Open Source Security Foundation: nel 2019 abbiamo collaborato alla nascita di Open Source Security Foundation, un forum intersettoriale sulla sicurezza della catena di fornitura.
• Allstar: si tratta di un'app GitHub installata all'interno di organizzazioni o repository per impostare e applicare i criteri di sicurezza. Consente di applicare in modo continuo le best practice sulla sicurezza per i progetti GitHub.
• Scorecard open source: le scorecard utilizzano metriche di valutazione come criteri di sicurezza ben definiti, procedura di revisione del codice e copertura continua mediante test con strumenti di analisi del codice in modalità fuzzing e statica per fornire un punteggio del rischio per i progetti open source.

Riteniamo che due aspetti siano necessari per superare il problema della sicurezza della catena di fornitura del software:

1. Standard e framework di settore.
2. I servizi gestiti che implementano questi standard mediante principi del privilegio minimo, sono noti come architettura Zero Trust. Si tratta di un'architettura in cui nessuna persona, dispositivo o rete può avere un'affidabilità intrinseca, ma deve guadagnarsela per consentire l'accesso alle informazioni.

Esaminiamo questi aspetti uno alla volta.

Al momento, il framework SLSA è un insieme di linee guida sulla sicurezza adottabili in modo incrementale e comunemente accettate dalle aziende di settore. Nella sua forma finale, l'SLSA non sarà un semplice elenco di best practice da applicare, ma supporterà la creazione automatica di metadati controllabili che possono essere inseriti nei motori dei criteri per assegnare la "certificazione SLSA" a un determinato pacchetto o a una specifica piattaforma di build.

L'SLSA è progettato per essere incrementale e pratico, nonché per fornire vantaggi per la sicurezza in ogni fase. Se un artefatto è considerato idoneo al livello più alto, i consumatori possono avere la certezza che non è stato manomesso e che la sua origine può essere rintracciata in modo sicuro, il che è difficile o addirittura impossibile con la maggior parte dei software odierni.

L'SLSA è composto da quattro livelli: SLSA 4 rappresenta lo stato finale ideale. I livelli inferiori indicano traguardi incrementali con garanzie corrispondenti incrementali di integrità. Attualmente i requisiti sono i seguenti:

SLSA 1 richiede che il processo di compilazione sia completamente generato con script/ automatizzato e che consenta di identificare la provenienza, ovvero una serie di metadati sulla creazione di un artefatto, inclusi processo di compilazione, origine di primo livello e dipendenze. Conoscere la provenienza consente ai consumatori del software di prendere decisioni sulla sicurezza basate sul rischio. Sebbene non garantisca una protezione da possibili manomissioni, la provenienza di livello SLSA 1 offre un livello base di identificazione della sorgente di codice e può contribuire alla gestione delle vulnerabilità.

SLSA 2 richiede l'utilizzo del controllo della versione e di un servizio di build in hosting che generi una provenienza autenticata. Questi requisiti aggiuntivi danno al consumatore una maggiore fiducia nell'origine del software. A questo livello, la provenienza impedisce manomissioni, purché il servizio di build sia attendibile. Il livello SLSA 2 offre inoltre un facile percorso di upgrade al livello SLSA 3.

SLSA 3 richiede in più che le piattaforme di origine e di build soddisfino standard specifici per garantire rispettivamente la verificabilità dell'origine e l'integrità della provenienza. Il livello SLSA 3 offre protezioni molto più efficaci contro le manomissioni rispetto ai livelli precedenti, in quanto previene classi di minacce specifiche come la contaminazione tra build.

SLSA 4 è attualmente il livello più alto e richiede la revisione di tutte le modifiche da parte di due persone, nonché un processo di compilazione ermetico e riproducibile. La revisione da parte di due persone è una best practice del settore per individuare gli errori e scoraggiare comportamenti dannosi. Le build ermetiche garantiscono che l'elenco delle dipendenze della provenienza sia completo. Le build riproducibili, anche se non sono del tutto obbligatorie, offrono molti vantaggi in termini di verificabilità e affidabilità. Nel complesso, il livello SLSA 4 offre al consumatore una certezza molto alta che il software non sia stato manomesso. Ulteriori dettagli su questi livelli proposti sono disponibili nel repository di GitHub, inclusi i requisiti corrispondenti per origine, compilazione e provenienza. 

La catena di fornitura del software può essere suddivisa in cinque fasi: codifica, build, pacchettizzazione, deployment ed esecuzione. Analizziamo ciascuna di queste fasi in termini di approccio alla sicurezza.

Google Cloud offre strumenti completamente gestiti per le fasi di codifica, build, deployment ed esecuzione, in cui le best practice e gli standard indicati in precedenza sono implementati per impostazione predefinita.

Per proteggere la catena di fornitura del software occorre stabilire, verificare e gestire una catena di attendibilità che stabilisca la provenienza del codice e garantisca che ciò che esegui in produzione sia effettivamente quello che volevi. Google ottiene questo risultato mediante attestazioni generate e verificate durante tutto il processo di sviluppo e deployment del software, creando un livello di sicurezza dell'ambiente attraverso la revisione del codice, la provenienza verificata del codice e l'applicazione dei criteri. Tutti questi processi ci aiutano a ridurre al minimo i rischi per la cate na di fornitura del software e a migliorare la produttività degli sviluppatori.

Come base usiamo una serie di servizi infrastrutturali sicuri e comuni, ad esempio la gestione di identità e accessi e l'audit logging. Inoltre, proteggiamo la catena di fornitura del software tramite la definizione, il controllo e l'applicazione delle attestazioni durante l'intero ciclo di vita del software.

Analizziamo più in dettaglio come raggiungere la sicurezza dell'ambiente nel processo di sviluppo mediante l'uso di criteri e dati sulla provenienza in Google Cloud.

La protezione della catena di fornitura del software inizia quando gli sviluppatori iniziano a progettare l'applicazione e a scrivere il codice. Sono inclusi sia i software proprietari che i componenti open source, entrambi con difficoltà specifiche.

Software open source e dipendenze

L'open source consente agli sviluppatori di velocizzare il processo di creazione, in modo che le organizzazioni possano essere più agili e produttive. Tuttavia, il software open source non è assolutamente perfetto e, sebbene il nostro settore dipenda da queste soluzioni, spesso abbiamo pochissime informazioni sulle dipendenze e sui diversi livelli di rischio associati. Per la maggior parte delle aziende, i rischi sono dovuti principalmente a vulnerabilità o licenze.

Le dipendenze generate da software open source, pacchetti, immagini di base e altri artefatti sono alla base della "catena di affidabilità".

Supponiamo, ad esempio, che la tua organizzazione stia creando il software "a". Questo diagramma mostra la catena di affidabilità, ovvero il numero di dipendenze implicite del progetto. Nel diagramma, i blocchi da "b" a "h" sono dipendenze dirette e quelli da "i" a "m" sono dipendenze indirette.

Ora immagina che esista una vulnerabilità a un livello molto profondo nella struttura delle dipendenze. Il problema può comparire molto rapidamente su vari componenti. Inoltre, le dipendenze cambiano abbastanza frequentemente: in media, durante una giornata 40.000 pacchetti npm registrano una variazione delle dipendenze.

Open Source Insight è uno strumento creato da Google Cloud per fornire un grafico di dipendenze transitorio al fine di visualizzare le dipendenze e le relative sottodipendenze, fino alla struttura completa delle dipendenze. Open Source Insight viene aggiornato continuamente con avvisi di sicurezza, informazioni sulle licenze e altri dati di sicurezza in più lingue e in un unico luogo. Se utilizzato insieme alle scorecard open source, che forniscono un punteggio dei rischi per i progetti open source, Open Source Insight consente agli sviluppatori di fare scelte migliori tra i milioni di pacchetti open source disponibili.

Per risolvere questo problema è fondamentale concentrarsi sulle dipendenze sotto forma di codice. Poiché queste si spostano verso la fine della catena di fornitura, sono più difficili da analizzare. Per proteggere le dipendenze, consigliamo di iniziare con la fornitura:

• Utilizza strumenti come Open Source Insight e le scorecard OSS per comprendere meglio le dipendenze. 
• Scansiona e verifica codice, pacchetti e immagini di base tramite un processo automatizzato che abbia un ruolo chiave all'interno del flusso di lavoro.
• Controlla in che modo gli utenti accedono a queste dipendenze. È fondamentale verificare rigorosamente se nei repository esistono codici sia proprietari sia open source, con vincoli che stabiliscono requisiti rigorosi di audit e revisione del codice.

Parleremo in modo più dettagliato dei processi di build e deployment, ma è importante anche verificare la provenienza della build, avvalersi di un ambiente di build sicuro e garantire che le immagini siano firmate e successivamente convalidate al momento del deployment.

Gli sviluppatori possono adottare varie pratiche di programmazione sicure:

• Automatizzare i test
• Utilizzare linguaggi software memory-safe 
• Eseguire revisioni obbligatorie del codice
• Garantire l'autenticità dei commit
• Identificare in anticipo il codice dannoso
• Evitare di esporre informazioni sensibili
• Richiedere l'output del logging e della build 
• Sfruttare la gestione delle licenze

Il passaggio successivo per proteggere la catena di fornitura del software consiste nel definire un ambiente di build sicuro su larga scala. Il processo di compilazione, in pratica, inizia con l'importazione del codice sorgente da un repository in uno dei tanti linguaggi disponibili, quindi prosegue con l'esecuzione delle build per rispettare le specifiche indicate nei file di configurazione.

I provider cloud come Google offrono l'accesso a un ambiente di build gestito e aggiornato che consente di creare immagini su qualsiasi scala.

Durante il processo di compilazione occorre prendere in considerazione diversi aspetti:

• I secret sono protetti durante il processo di compilazione e oltre?
• Chi ha accesso agli ambienti di build?
• Esistono vettori di attacco relativamente nuovi o rischi di esfiltrazione?

Per sviluppare un ambiente di build sicuro, bisogna iniziare dai secret. Sono fondamentali e relativamente facili da proteggere. Per iniziare, fai in modo che i tuoi secret non siano mai in testo non crittografato e, per quanto possibile, non facciano parte della build. Devi invece assicurarti che siano criptati e che le build siano parametrizzate per fare riferimento a secret esterni da utilizzare in base alle esigenze. Questo semplifica anche la rotazione periodica dei secret e riduce al minimo l'impatto di eventuali fughe di informazioni.

Il passaggio successivo prevede la configurazione delle autorizzazioni per la build. Il processo di compilazione coinvolge vari utenti e account di servizio. Ad esempio, alcuni utenti potrebbero dover gestire i secret, altri potrebbero doversi occupare del processo di compilazione aggiungendo o modificando i passaggi, mentre altri ancora potrebbero semplicemente dover visualizzare i log.

A questo scopo, è importante seguire queste best practice:

• La più importante è il principio del privilegio minimo. Implementa autorizzazioni molto granulari per concedere a utenti e account di servizio le autorizzazioni esatte di cui hanno bisogno per svolgere in modo efficace il loro lavoro.
• Assicurati di sapere in che modo utenti e account di servizio interagiscono, nonché di comprendere chiaramente la catena di responsabilità dalla configurazione di una build alla sua esecuzione, fino ai rispettivi effetti downstream.

Man mano che fai lo scale up di questo processo, devi stabilire i limiti consentiti della build e utilizzare l'automazione per fare lo scale up tramite la configurazione sotto forma di codice e la parametrizzazione. Ciò consente di verificare in modo efficace eventuali modifiche al processo di compilazione. Inoltre, assicurati di soddisfare le esigenze di conformità mediante procedure di approvazione per build e deployment sensibili, richieste di pull per le modifiche all'infrastruttura e revisioni costanti degli audit log da parte di persone fisiche.

Infine, assicurati che la rete sia adatta alle tue esigenze. Nella maggior parte dei casi, è meglio ospitare il proprio codice sorgente in reti private protette da firewall. Google Cloud ti dà accesso a funzionalità come i pool privati Cloud Build, un ambiente di build serverless e protetto all'interno del perimetro della rete privata, nonché soluzioni come i Controlli di servizio VPC per impedire l'esfiltrazione delle proprietà intellettuali.

Autorizzazione binaria

IAM è logicamente un punto di partenza indispensabile, ma non è infallibile. Le credenziali divulgabili rappresentano un serio rischio per la sicurezza perciò, al fine di ridurre la dipendenza da IAM, puoi passare a un sistema basato su attestazione meno soggetto a errori. Google utilizza un sistema chiamato Autorizzazione binaria, che consente il deployment solo di carichi di lavoro attendibili.

Il servizio di autorizzazione binaria stabilisce, verifica e gestisce una catena di attendibilità tramite attestazioni e controlli dei criteri durante tutto il processo. Sostanzialmente, l'autorizzazione binaria genera firme crittografiche (attestazioni) quando il codice e altri artefatti passano verso la fase di produzione e, prima del deployment, queste attestazioni vengono controllate in base a vari criteri.

Quando utilizzi Google Cloud Build, viene acquisito un insieme di attestazioni che successivamente viene aggiunto alla catena di affidabilità nel suo complesso. Ad esempio, vengono generate attestazioni per le attività eseguite, gli strumenti di build, i processi utilizzati e così via. In particolare, Cloud Build consente di raggiungere il livello SLSA 1 mediante l'acquisizione dell'origine della configurazione di compilazione, che può essere utilizzata per garantire che la build sia stata basata su script. Le build generate mediante script sono più sicure di quelle manuali e sono obbligatorie per ottenere il livello SLSA 1. Inoltre, è possibile analizzare la provenienza della build e altre attestazioni mediante il digest delle immagini container, che crea una firma univoca per ogni immagine e che oltretutto è obbligatorio per raggiungere il livello SLSA 1.

Una volta completata la build, avrai un'immagine container quasi pronta per passare in produzione. È essenziale disporre di una posizione sicura per archiviare le immagini, in modo da impedire la manomissione di quelle esistenti e il caricamento di immagini non autorizzate. È probabile che il gestore di pacchetti abbia bisogno di immagini sia per le build proprietarie e open source, sia per i pacchetti dei linguaggi utilizzati dall'applicazione.

Artifact Registry di Google Cloud fornisce un repository di questo tipo. Artifact Registry offre una singola posizione da cui la tua organizzazione può gestire sia le immagini container sia i pacchetti dei linguaggi, ad esempio Maven e npm. È completamente integrato con gli strumenti e i runtime di Google Cloud e supporta i protocolli per gli artefatti nativi. Per questo motivo è facile da integrare con gli strumenti CI/CD man mano che lavori alla configurazione di pipeline automatizzate.

Come per la fase di build, è essenziale garantire che le autorizzazioni per accedere ad Artifact Registry siano ben definite e rispettino i principi del privilegio minimo. Oltre a limitare l'accesso non autorizzato, il repository dei pacchetti può offrire molti più vantaggi. Artifact Registry, ad esempio, include l'analisi delle vulnerabilità per eseguire la scansione delle immagini e garantire che il loro deployment sia sicuro. Questo servizio scansiona le immagini in base a un database di vulnerabilità aggiornato costantemente per valutare nuove minacce e avvisarti qualora venga rilevata una vulnerabilità.

Questo passaggio genera altri metadati, tra cui un'attestazione nel caso in cui i risultati di vulnerabilità di un artefatto corrispondano a determinate soglie di sicurezza. Queste informazioni vengono quindi archiviate nel servizio di analisi che struttura e organizza i metadati dell'artefatto per renderli accessibili immediatamente all'autorizzazione binaria. Puoi utilizzarli per impedire automaticamente il deployment di immagini rischiose in Google Kubernetes Engine (GKE).

Le ultime due fasi nella catena di fornitura per la sicurezza del software sono il deployment e l'esecuzione. Anche se si tratta di due passaggi separati, è opportuno considerarli insieme come un modo per garantire che solo le build autorizzate passino in produzione.

In Google abbiamo sviluppato alcune best practice per determinare il tipo di build da autorizzare. Il primo passo è garantire l'integrità della catena di fornitura in modo che possa generare solo artefatti attendibili. Quindi, la gestione delle vulnerabilità deve essere una parte integrante nel ciclo di vita della distribuzione del software. Infine, abbiamo unito questi due elementi per applicare flussi di lavoro basati su criteri per l'analisi delle vulnerabilità e dell'integrità.

Per arrivare a questa fase hai già passato quelle di codifica, build e pacchettizzazione. Le attestazioni acquisite lungo la catena di fornitura possono essere verificate per garantire l'autenticità tramite l'autorizzazione binaria. In modalità di applicazione forzata, il deployment di un'immagine viene eseguito solo se le attestazioni soddisfano i criteri dell'organizzazione, mentre in modalità di controllo le violazioni dei criteri vengono registrate e attivano degli avvisi. Puoi anche utilizzare l'autorizzazione binaria per limitare l'esecuzione delle build, a meno che non siano state create utilizzando il processo approvato di Cloud Build. L'autorizzazione binaria garantisce che venga eseguito il deployment solo del codice rivisto e autorizzato.

È essenziale eseguire il deployment delle immagini in un ambiente di runtime affidabile. GKE, la nostra piattaforma Kubernetes gestita, adotta un approccio incentrato sulla sicurezza per i container.

GKE si occupa di molti problemi di sicurezza dei cluster che richiedono attenzione. Gli upgrade automatici dei cluster consentono di applicare le patch necessarie a Kubernetes e mantenerlo aggiornato in modo automatico mediante canali di rilascio. L'avvio protetto, i nodi schermati e i controlli di integrità garantiscono che il kernel e i componenti del cluster del nodo non siano stati modificati ed eseguano ciò che era previsto. Inoltre, fanno in modo che nel cluster non vengano aggiunti nodi dannosi. Infine, il Confidential Computing consente di eseguire cluster con nodi la cui memoria è criptata, in modo che i dati rimangano riservati anche durante l'elaborazione. Se abbiniamo tutto questo alla crittografia dei dati sia at-rest che in transito sulla rete, GKE offre un ambiente molto sicuro, privato e riservato per eseguire carichi di lavoro containerizzati.

In più, GKE offre anche una maggiore sicurezza delle applicazioni mediante la gestione dei certificati per i bilanciatori del carico, l'identità dei carichi di lavoro e funzionalità di rete avanzate con modalità molto efficaci per configurare e proteggere il traffico in entrata nel cluster. GKE fornisce anche ambienti sandbox per eseguire applicazioni non attendibili, proteggendo al contempo il resto dei carichi di lavoro.

Grazie a GKE Autopilot, le best practice e le funzionalità di sicurezza di GKE vengono implementate automaticamente, il che riduce ulteriormente la superficie di attacco e minimizza gli errori di configurazione che possono generare problemi di sicurezza.

Naturalmente, la necessità di eseguire verifiche non si limita al deployment. L'autorizzazione binaria supporta anche la convalida continua in modo da rispettare sempre i criteri definiti anche dopo il deployment. Se un'applicazione in esecuzione non è conforme a un criterio esistente o appena aggiunto, viene creato e registrato un avviso per avere la certezza che in produzione venga eseguito esattamente ciò che era previsto.

Gestione delle vulnerabilità

Oltre a garantire l'integrità, un altro aspetto della sicurezza della catena di fornitura consiste nell'assicurare che le vulnerabilità vengano individuate e risolte rapidamente. Gli utenti malintenzionati hanno perfezionato le loro tecniche per inserire attivamente le vulnerabilità nei progetti upstream. La gestione delle vulnerabilità e il rilevamento dei difetti dovrebbero essere incorporati in tutte le fasi del ciclo di vita della distribuzione del software.

Quando il codice è pronto per il deployment, utilizza una pipeline CI/CD e sfrutta i numerosi strumenti disponibili per eseguire una scansione completa del codice sorgente e degli artefatti generati. Sono disponibili analizzatori statici, strumenti di fuzzing e vari metodi per l'analisi delle vulnerabilità.

Dopo aver eseguito il deployment del carico di lavoro in produzione, e mentre è in esecuzione in questa fase e viene utilizzato dagli utenti, è necessario monitorare le potenziali minacce e avere pronti dei piani per risolvere immediatamente eventuali problemi.

Conclusione

Riassumendo, la protezione della catena di fornitura del software prevede l'adozione di best practice come l'SLSA e l'utilizzo di servizi gestiti affidabili in grado di implementarle.

È fondamentale:

• Iniziare dal codice e dalle dipendenze, assicurandosi che siano affidabili.
• Proteggere il sistema di compilazione e utilizzare le attestazioni per verificare che siano stati seguiti tutti i passaggi di build necessari.
• Assicurarsi che tutti i pacchetti e gli artefatti siano attendibili e non possano essere manomessi.
• Applicare controlli su chi può eseguire il deployment e su cosa può essere distribuito, nonché mantenere un audit trail e utilizzare l'autorizzazione binaria per convalidare le attestazioni per ogni artefatto di cui eseguire il deployment.
• Eseguire le applicazioni in un ambiente attendibile e assicurarsi che nessuno possa manometterle durante l'esecuzione, nonché tenere d'occhio eventuali vulnerabilità rilevate di recente per proteggere il deployment.

Tutti i prodotti Google si basano su best practice per ogni fase di questo percorso, in modo che i clienti possano avere una base solida su cui sviluppare le proprie soluzioni.

Vuoi proteggere la catena di fornitura del software? Ci teniamo a precisare che il punto di partenza è molto arbitrario. Non esiste un'azione specifica che possa proteggere l'intera catena di fornitura e nessuna è più importante di un'altra per quanto riguarda la sicurezza complessiva della catena di fornitura. Detto questo, ecco quattro consigli per iniziare.

1. Applica le patch al software

Se il codice che hai distribuito nell'ambiente di produzione contiene vulnerabilità note, hai spalancato le porte agli attacchi di utenti malintenzionati. Non conta quanto sia protetta la catena di fornitura del software perché hanno già trovato un modo per violare il codice. Di conseguenza, l'applicazione delle patch è fondamentale.

2. Tieni sotto controllo ciò che viene eseguito nel tuo ambiente

Dopo aver applicato le patch, devi poter controllare la catena di fornitura del software. Devi anzitutto essere in grado di avere la certezza che quello che stai eseguendo proviene effettivamente dai tuoi strumenti di build o da repository attendibili. Questo livello di controllo è utile per prevenire sia attacchi mirati che errori involontari, ad esempio nel caso di uno sviluppatore che ha eseguito il deployment di un codice che ignorava fosse non sicuro. In questo modo puoi avere una base solida per aggiungere strumenti come il test dei clic e l'autorizzazione binaria. 

3. Assicurati che i pacchetti di fornitori di terze parti siano sicuri

Un problema emergente nella sicurezza della catena di fornitura è la frequenza con cui il software dei fornitori viene violato per fornire un canale per il ransomware o l'accesso non autorizzato ai deployment dei clienti di destinazione. I pacchetti dei fornitori di terze parti che esegui nel tuo ambiente, ad esempio prodotti per la gestione del sistema e della rete o per la sicurezza, spesso prevedono privilegi molto elevati. Ti consigliamo di chiedere a questi fornitori di andare oltre le loro istruzioni standard sulla sicurezza e di garantire in qualche modo l'affidabilità dei pacchetti che utilizzi. Puoi chiedere loro qual è il livello di conformità SLSA dei pacchetti o se devono rispettare i requisiti del recente ordine esecutivo statunitense.

4. Fai in modo di avere una copia privata del codice sorgente

Se ti avvali di un software open source, non utilizzare una versione disponibile direttamente su internet per iniziare il processo di build. Genera una tua copia privata a cui applichi regolarmente le patch, in modo da avere un punto di partenza "pulito" per ogni build, anche per sapere con totale certezza da dove proviene il codice sorgente. 

Best practice DevOps

1. Sei anni del report State of DevOps, una serie di articoli con informazioni approfondite sulle funzionalità che prevedono le prestazioni di distribuzione del software e un controllo rapido per aiutarti a capire come te la stai cavando e come migliorare.
2. Report Google Cloud 2021 Accelerate State of DevOps
3. Google Cloud whitepaper: Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale

Protezione della catena di fornitura del software

1. Blog di Google Cloud: What is zero trust identity security
2. Blog sulla sicurezza di Google: Introducing SLSA, an end-to-end framework for supply chain integrity
3. White paper Google Cloud: Shifting left on security: Securing software supply chains