Proteggi la tua supply chain di immagini container
Come proteggere la tua supply chain software?
Proteggere la tua supply chain software significa controllare ogni artefatto tra un commit del codice e la produzione. Nelle pipeline containerizzate si riduce a quattro controlli: un registro privato con RBAC, scansione CVE, firma crittografica e una policy che blocca le immagini non firmate o vulnerabili al momento del deploy.
Perché gli attacchi alla supply chain ora prendono di mira le tue immagini container
SolarWinds, Log4Shell, xz-utils: la pipeline di build è il nuovo perimetro
Gli incidenti di sicurezza software più significativi degli ultimi anni non sono iniziati con una violazione del firewall o una password rubata. Sono iniziati all'interno della supply chain software stessa.
- SolarWinds: il sistema di build è stato compromesso per iniettare codice dannoso in aggiornamenti software firmati, raggiungendo agenzie governative degli Stati Uniti e migliaia di clienti aziendali a valle.
- Log4Shell: un componente open source vulnerabile, sepolto in un albero delle dipendenze condiviso da innumerevoli progetti, è diventato una grave vulnerabilità che gli attaccanti hanno sfruttato contemporaneamente in migliaia di organizzazioni non correlate.
- xz-utils: l'ambiente di build di un manutentore di pacchetti affidabile è diventato un vettore di attacco, grazie a un attaccante abbastanza paziente da sfruttare anni di fiducia accumulata.
Il modello è lo stesso in tutti e tre i casi. Il processo di build, non l'applicazione in esecuzione, è stato il punto di compromissione.
Un'immagine container è l'ultimo artefatto prima che l'output di build raggiunga la produzione. È anche l'ultimo punto pratico in cui intercettare un componente compromesso e le sue dipendenze prima che un exploit faccia danni.
Perché Docker Hub e i registri pubblici non sono sufficienti
Un registro pubblico è pubblico per impostazione predefinita, a meno che non si paghi per repository privati. Non dispone di RBAC per team, di applicazione di policy CVE né di verifica della firma al pull.
Non si tratta di una lacuna funzionale che si può correggere. Si tratta di un tipo di prodotto diverso.
I registri pubblici esistono per distribuire software open source a qualsiasi utente che lo desideri. L'autore del pacchetto e l'utente del pacchetto non si incontrano mai e nessuno dei due può verificare molto sull'altro.
Controllare esattamente quali immagini software i cluster Kubernetes della tua organizzazione possono scaricare è un problema completamente diverso.
Nemmeno un registro privato generico senza una postura di sicurezza documentata riduce il rischio della catena di fornitura del software. Il rischio è concreto: un attacco che inserisce un componente dannoso in un'immagine infetta ogni cluster che la scarica.
Tale rischio si aggrava con ogni team che condivide il registro. Senza una scansione sistematica, senza un livello di policy e senza una traccia di controllo su chi ha eseguito il push di cosa, quando e se fosse firmato, hai spostato le immagini da un registro pubblico senza ridurre il rischio.
L'aspetto della conformità: ISO 27001, SOC 2 e settori regolamentati
I team di sicurezza ottengono raramente un budget per questo lavoro finché un audit non lo impone. Gli audit di conformità trattano le immagini di container non scansionate come un rilievo critico, non come un suggerimento.
La sicurezza è una postura che si mantiene, non un prodotto che si acquista, e un revisore testa la postura piuttosto che l'elenco degli strumenti. La sicurezza della supply chain del software viene valutata come un insieme di pratiche, e ogni pratica necessita di prove.
ISO 27001, SOC 2 e la maggior parte degli standard di sicurezza dei settori regolamentati, molti sviluppati con agenzie governative ed enti di orientamento del settore, prevedono una scansione delle vulnerabilità e un controllo degli accessi documentati e sistematici su qualsiasi software che arrivi in produzione. Le immagini di container sono artefatti di produzione come qualsiasi altro.
Le immagini di container memorizzano anche codice applicativo, configurazione e talvolta variabili d'ambiente. Le autorizzazioni del registro rappresentano quindi un controllo di accesso sulla proprietà intellettuale del software sensibile.
Queste sono esattamente il tipo di best practice di sicurezza che un revisore si aspetta di vedere documentate, non date per scontate.
La pratica raccomandata in ogni insieme di linee guida pubblicate, dalla CISA alla CNCF, è la stessa, e vale la pena apprenderla prima che un audit vi costringa a farlo:
• Rendete ogni controllo una pratica documentata con un responsabile designato.
• Proteggete l'ambiente di build con la stessa cura di quello di runtime.
• Mantenete le dipendenze aggiornate in modo che le vulnerabilità note non si accumulino.
I revisori richiedono prove per ciascuno di questi punti, e l'hub Identity, Security & Operations di OVHcloud copre i servizi che le generano.
I quattro controlli di cui ogni pipeline containerizzata ha bisogno
Un framework come SLSA (Supply-chain Levels for Software Artifacts) offre ai team un modo strutturato per misurare quanto siano maturi questi controlli. Non è necessario adottare un framework completo per ottenere il vantaggio pratico.
I livelli SLSA sono principalmente utili come linguaggio condiviso con revisori e partner, e vale la pena imparare SLSA solo per questo. Un partner esterno dichiara il proprio livello, tu lo confronti con il tuo e nessuno invia un lungo questionario.
I fornitori ne pubblicano sempre più spesso uno, quindi chiedere a un partner il proprio è una normale domanda di approvvigionamento.
L'analisi statica, o SAST, viene eseguita sul codice sorgente prima di qualsiasi compilazione. Individua una classe di vulnerabilità diversa rispetto alla scansione delle immagini e si colloca prima nella catena, insieme all'analisi della composizione del software sulle dipendenze.
SAST e scansione delle immagini sono complementari, non sostitutivi. Nessuno dei due rileva ciò che l'altro è progettato per trovare. Tre livelli coprono l'intera catena:
1. Esegui la SAST sul tuo codice sorgente.
2. Esegui l'analisi della composizione del software sulle dipendenze esterne.
3. Esegui la scansione delle immagini sull'artefatto compilato.
Saltane uno dei tre e lascerai un'intera classe di vulnerabilità non misurata, indipendentemente da ciò che riportano gli altri strumenti.
I quattro controlli seguenti intervengono nel momento in cui una build produce un'immagine di container, l'artefatto centrale della catena.
Archivia le immagini in un registro privato controllato da RBAC
Il controllo fondamentale di una supply chain software sicura è un registro chiuso per impostazione predefinita, con RBAC per progetto o per team. Non un bucket condiviso su cui tutti possono eseguire il push, e non un registro pubblico con immagini visibili per impostazione predefinita.
Gli account robot svolgono il resto del lavoro:
• Limita ogni account robot a un singolo progetto.
• Assegna ai passaggi di build autorizzazioni di push di sola scrittura e ai passaggi di distribuzione autorizzazioni di pull di sola lettura.
• Esegui un progetto per team, in modo che un progetto compromesso rimanga circoscritto.
• Applica una policy centrale a ogni progetto, sottoposta a audit centralizzato.
• Mantieni le credenziali personali e di amministrazione completamente fuori dalle build automatizzate.
Scansiona ogni immagine per CVE al push e al pull
La scansione delle vulnerabilità deve avvenire in due punti:
• Al push, in modo che una nuova immagine venga scansionata nel momento in cui viene creata.
• Al pull, in modo che un controllo delle policy venga eseguito nuovamente prima che un'immagine meno recente venga distribuita rispetto a un database di vulnerabilità più recente.
Un'immagine che a marzo era pulita potrebbe presentare tre vulnerabilità note a giugno, e solo un controllo al momento del pull le rileverà.
La scansione asincrona al push non rallenta la build. La scansione viene eseguita in parallelo mentre la pipeline continua e i risultati sono disponibili prima che l'immagine venga promossa verso la produzione.
Firmate gli artefatti con Cosign o Notary v2
La firma di un'immagine registra crittograficamente chi l'ha creata e conferma che non è stata manomessa durante il transito. Stabilisce una catena di fiducia dal sistema di compilazione al cluster.
La fiducia è ciò che un attaccante sta realmente prendendo di mira. La backdoor di xz-utils ha funzionato perché la fiducia in un manutentore si era accumulata per anni e gli attaccanti sono abbastanza pazienti da sfruttare un manutentore piuttosto che un firewall.
Cosign, parte del progetto Sigstore, e Notary v2 sono oggi i due approcci open source dominanti per la firma delle immagini di container.
Senza una firma e una policy che ne verifichi la presenza, non c'è modo di dimostrare dopo un incidente che l'immagine in esecuzione in produzione sia l'esatto artefatto creato dalla vostra pipeline. Un'immagine non firmata e una manomessa sono indistinguibili al momento del deploy.
Applica una policy di distribuzione prima che le immagini raggiungano Kubernetes
La scansione e la firma contano solo se qualcuno le impone. Un controller di ammissione Kubernetes, con Kyverno o OPA Gatekeeper come due scelte comuni, controlla ogni immagine al momento del deploy e rifiuta tutto ciò che non rispetta la policy:
• CVE critiche non risolte.
• Una firma Cosign mancante o non valida.
• Un'immagine proveniente da un registro non approvato.
Questo è il controllo che rende gli altri applicabili, e quello che un attacco deve sconfiggere. Trasforma la scansione delle immagini da una metrica riportata in un blocco rigido, in modo che nessuna immagine non scansionata raggiunga la produzione, che è l'effettivo requisito di conformità.
I due punti di applicazione sono complementari. Il registro blocca il push, il cluster blocca il deploy e un attacco che supera uno dei due incontra comunque l'altro. Entrambi si trovano sopra un cluster che non devi gestire personalmente quando utilizzi Managed Kubernetes Service di OVHcloud.
Questi quattro controlli tecnici si affiancano, non sostituiscono, alle pratiche organizzative che riducono il rischio in modo più ampio. Pratiche di questo tipo sono economiche rispetto a un incidente, e ognuna è una pratica che un revisore può verificare.
Queste sono le pratiche che trasformano un design sicuro in un sistema sicuro, e ognuna è una pratica centrale, non un extra opzionale:
• Aggiorna regolarmente le dipendenze e i componenti di terze parti per proteggerti da exploit noti.
• Limita l'accesso ai sistemi di build sensibili e alle chiavi di firma.
• Educa i dipendenti ed esegui corsi di sensibilizzazione sulla sicurezza, affinché gli ingegneri riconoscano un pacchetto compromesso o un tentativo di phishing contro un account di un manutentore.
• Conduci esercitazioni basate su un piano di risposta agli incidenti, affinché un team sappia come rispondere rapidamente quando un controllo fallisce.
• Verifica continuamente l'integrità del software invece di darla per scontata, affinché ogni artefatto rimanga protetto da un controllo piuttosto che dall'abitudine.
Qualsiasi potenziale lacuna di sicurezza in questo elenco è solitamente una lacuna di processo, non di strumenti.
Ogni componente software che integri, e ogni componente transitivo sottostante, è una decisione che qualcuno ha preso una volta e che raramente viene riesaminata. Un'applicazione moderna include centinaia di tali componenti, la maggior parte dei quali proviene da una parte esterna che nessuno ha mai incontrato.
L'inventario dei componenti è quindi la pratica da cui dipende tutto il resto. La gestione delle dipendenze, ovvero sapere quale software e quali componenti provengono da terze parti, è ciò che rende utile un SBOM (software bill of materials) una volta che ne hai uno.
Un SBOM elenca ogni componente e ogni versione, il che trasforma un nuovo avviso CVE in una query di cinque minuti invece che in una settimana di ricerche archeologiche. Senza di esso, la risposta onesta alla domanda se tu sia esposto è che nessuno lo sa.
Come OVHcloud Managed Private Registry colma il divario
Harbor sotto il cofano: CNCF-graduated, standard OCI, open source
Managed Private Registry è un'istanza completamente gestita di Harbor, una tecnologia open source graduata CNCF creata per l'archiviazione di container e Helm chart, con la sicurezza come funzionalità di primo livello piuttosto che come componente aggiuntivo.
L'hosting autonomo di Harbor significa eseguire e applicare patch a PostgreSQL, Redis, ai servizi core di Harbor e allo scanner, oltre a TLS e agli aggiornamenti di ciascuno di questi componenti.
OVHcloud rimuove questo livello operativo. Tu crei un registro, esegui il push delle immagini e configuri la policy, mentre l'infrastruttura Harbor sottostante è responsabilità di OVHcloud. Ciò libera il tuo team di sicurezza informatica per la modellazione delle minacce e la resilienza della supply chain, invece di applicare patch a un database.
Poiché Harbor è open source e basato su standard, non esiste alcun lock-in proprietario. Le immagini risiedono nel formato standard OCI, quindi la migrazione verso un Harbor self-hosted o un altro registro conforme a OCI non richiede passaggi di conversione né formati di pull proprietari da eliminare.
Tale trasparenza è di per sé una proprietà di sicurezza. Una comunità globale di revisori, non un singolo fornitore, esamina il codice che esegue il tuo registro.
Un progetto centrale con molti revisori rileva un commit dannoso più rapidamente di uno chiuso, e le informazioni sulle minacce riguardanti le vulnerabilità di Harbor o Trivy ti raggiungono attraverso gli stessi canali pubblici su cui fanno affidamento tutti gli altri utenti.
Scansione delle vulnerabilità con Trivy: Rilevamento delle CVE al push e al pull
OVHcloud Managed Private Registry include Trivy, lo scanner integrato di Harbor, attivato a livello di progetto.
Configura la scansione al push in modo che ogni immagine venga controllata non appena arriva, quindi imposta una soglia di gravità per le CVE. Avvisare su HIGH, bloccare su CRITICAL è una policy iniziale consigliata.
Una scansione al momento del pull ricontrolla quindi un'immagine più vecchia rispetto a un database di vulnerabilità più recente.
Una policy di distribuzione di Harbor impedisce il pull di immagini con CVE CRITICAL non risolte nei namespace di produzione, il che rende il risultato della scansione azionabile anziché informativo.
Firma dell'immagine con Cosign e Notary v2
Il servizio è basato su Harbor, quindi supporta la scansione delle vulnerabilità e l'archiviazione dei grafici Helm documentate per il prodotto.
La firma dell'immagine stessa viene eseguita tramite i comuni strumenti open source Cosign nella tua pipeline CI/CD, puntando al registro OVHcloud anziché a un servizio di firma proprietario.
Applicazione delle policy: blocca le immagini con CVE critiche prima del deploy
La policy lato registro, che blocca le CVE CRITICAL e richiede una firma valida, è solo metà della storia dell'applicazione.
L'altra metà viene eseguita in Kubernetes stesso. Una policy di ammissione Kyverno o OPA Gatekeeper rifiuta qualsiasi immagine priva di una firma Cosign valida, o con una vulnerabilità grave non risolta, indipendentemente da come sia stata distribuita o da quale attore.
Insieme forniscono un blocco delle CVE applicato tramite policy end-to-end. È una configurazione che imposti deliberatamente, non una garanzia automatica.
Archiviazione degli Helm chart (conforme a OCI)
Gli Helm chart sono archiviati nello stesso formato conforme a OCI delle immagini dei container, nella stessa struttura di progetto, con gli stessi account RBAC e robot.
I team che impacchettano i deployment come Helm chart ottengono un unico registro per entrambi i tipi di artefatti, invece di un repository di chart separato da proteggere e mantenere.
Connessione della tua pipeline CI/CD (GitHub Actions, GitLab CI, Tekton)
Account robot: push di sola scrittura per le build, pull di sola lettura per i deployment
Crea un progetto Harbor per team o applicazione, quindi rilascia account robot limitati esattamente a ciò di cui ogni fase ha bisogno: push di sola scrittura per la fase di build, pull di sola lettura per la fase di deployment.
Non incorporare mai credenziali di amministratore o personali, o il file chiave di un account
robot, in una definizione di build. Un account robot di sola lettura compromesso è un incidente circoscritto. Una credenziale di amministratore trapelata nelle mani di un attore esterno non lo è.
Per le chiavi di firma Cosign nello specifico, OVHcloud Key Management Service supporta il bring-your-own-key con archiviazione basata su HSM FIPS 140-2, che mantiene le chiavi lontane dai laptop degli sviluppatori e dai runner CI.
Esempio di GitHub Actions: compilazione, scansione, firma e push
Una singola fase copre l'intero controllo:
1. Crea l'immagine.
2. Eseguine il push con un account robot di sola scrittura.
3. Attendi il risultato della scansione Trivy.
4. Firma con Cosign solo se la scansione supera la soglia CVE configurata.
Questa sequenza mantiene un blocco rigido tra l'esistenza di un'immagine e il fatto che un'immagine sia abbastanza affidabile da essere firmata, invece di firmare incondizionatamente al momento della compilazione.
Lo stesso schema si applica indipendentemente dal fatto che la compilazione venga eseguita su GitHub Actions, GitLab CI o Tekton. Cambia solo la sintassi per chiamare il registro e lo scanner, indipendentemente dal linguaggio di programmazione in cui è scritta la tua applicazione.
Policy di ammissione Kyverno su Managed Kubernetes Service
Su OVHcloud Managed Kubernetes Service, una policy Kyverno, definita come un file di policy Kubernetes standard, controlla ogni specifica di pod in arrivo per verificare la presenza di una firma Cosign valida e rifiuta il deployment se la firma manca o non è valida.
Combinato con la policy CVE lato registro, questo chiude il cerchio tra ciò che costruisci e ciò che il cluster può eseguire. Un'immagine non firmata o non scansionata non si avvia mai, chiunque abbia richiesto il deploy.
Supply chain sovrana: perché la giurisdizione del tuo registro è importante
Le immagini container trasportano IP e con esse l'esposizione al CLOUD Act
Un'immagine container raggruppa codice applicativo, livelli di configurazione e talvolta variabili d'ambiente: una parte significativa della proprietà intellettuale della tua organizzazione. Un registro centrale è il luogo in cui si concentra tale proprietà intellettuale, motivo per cui la sua giurisdizione è importante. Memorizzare tale immagine presso un provider con sede negli Stati Uniti, anche se dotato di data center nell'UE, la pone sotto la giurisdizione del CLOUD Act statunitense, poiché l'esposizione segue la società madre, non il luogo di archiviazione. La stessa logica si applica a qualsiasi deployment su AWS ECR, Google Artifact Registry o Docker Hub: La giurisdizione del CLOUD Act statunitense si applica indipendentemente dalla regione.
Sede centrale europea, nessuna società madre statunitense, GDPR per giurisdizione
Un'immagine container raggruppa codice applicativo, livelli di configurazione e talvolta variabili d'ambiente: una parte significativa della proprietà intellettuale della tua organizzazione.
Un registro centrale è il luogo in cui si concentra tale proprietà intellettuale, motivo per cui la sua giurisdizione è importante.
Memorizzare quell'immagine presso un fornitore con sede negli Stati Uniti, anche se dotato di data center nell'UE, la pone sotto la giurisdizione del CLOUD Act statunitense, poiché l'esposizione segue la società madre piuttosto che il luogo di archiviazione.
Lo stesso vale per qualsiasi registro gestito da un fornitore con sede negli Stati Uniti: La giurisdizione del CLOUD Act statunitense si applica indipendentemente dalla regione.
Sede centrale europea, nessuna società madre statunitense, GDPR per giurisdizione
OVHcloud è un operatore europeo senza società madre statunitense, quindi non c'è alcuna esposizione strutturale al CLOUD Act su tutto ciò che è archiviato nel registro.
L'infrastruttura del registro opera secondo il GDPR per giurisdizione piuttosto che per impegno politico.
La protezione legale deriva dal luogo in cui si trovano l'azienda e l'infrastruttura, non da una promessa contrattuale sovrapposta a un'infrastruttura che un'autorità straniera potrebbe comunque obbligare a cedere.
Percorso end-to-end: Da Managed Private Registry a Managed Kubernetes Service
Crea un progetto Managed Private Registry, esegui il push di un'immagine e attiva la scansione e la firma. MKS Free copre lo sviluppo e lo staging senza costi, così puoi convalidare l'intera catena di policy prima che il traffico di produzione ne dipenda. Per cluster di produzione multipli, settori regolamentati o pool di nodi GPU, un Solutions Architect di OVHcloud ti aiuterà a dimensionarlo. L'hub di orchestrazione dei container è il posto dove imparare il resto.
Disponibilità 3-AZ a Parigi e Milano, SLA di disponibilità del 99,99% su MKS Standard
Il registro viene eseguito in 3-AZ a Parigi con alta disponibilità integrata. Il guasto di una singola zona non interrompe né le build né i deployment, il che è importante perché un'interruzione del registro blocca entrambi.
Il Managed Kubernetes Service Standard viene eseguito in 3-AZ a Parigi e Milano con un SLA di disponibilità del 99,99%, in modo che il registro e il cluster che ne trae le immagini condividano lo stesso livello di disponibilità, invece che uno dei due rappresenti l'anello debole.
MKS Free per iniziare, MKS Standard per la produzione
Il servizio Kubernetes gestito dispone di un livello gratuito per lo sviluppo e la messa in scena, sufficiente a convalidare l'intera catena di fornitura del software: registro, scansione, firma e policy di ammissione, prima di impegnarsi su un cluster di produzione.
Il blocco della versione sui file di policy mantiene tale convalida riproducibile.
Quando sei pronto per il traffico di produzione, MKS Standard aggiunge il livello 3-AZ con un SLA di disponibilità del 99,99% e le stesse policy Kyverno o OPA Gatekeeper vengono trasferite invariate su entrambi i livelli.
I team che gestiscono diversi cluster aggiungono Managed Rancher Service sopra di essi per un unico piano di controllo.
Inizia subito: attiva il tuo registro e distribuisci immagini sicure oggi stesso
Crea un progetto Managed Private Registry, esegui il push di un'immagine e attiva la scansione e la firma. MKS Free copre lo sviluppo e lo staging senza costi, così puoi convalidare l'intera catena di policy prima che il traffico di produzione ne dipenda. Per cluster di produzione multipli, settori regolamentati o pool di nodi GPU, un Solutions Architect di OVHcloud ti aiuterà a dimensionarlo. L'hub Container orchestration è il posto giusto per imparare il resto.