Proteggi la tua supply chain del software dalla compilazione al deployment

Impedisci a immagini container non scansionate, non firmate o vulnerabili di raggiungere la produzione. Questa guida mostra come i controlli del registro privato, la scansione delle vulnerabilità, la firma degli artefatti e le policy di ammissione di Kubernetes creino un workflow applicabile lungo la supply chain del software. 
IniziaManaged Private Registry
Illustrazione nomi di dominio

Verifica ogni componente nella tua pipeline

La sicurezza della supply chain del software consiste nel verificare costantemente ogni dipendenza, pacchetto e artefatto all’interno di una pipeline CI/CD. La fiducia deve coprire il codice sorgente, i pacchetti pubblici, la tecnologia esterna, i componenti di terze parti, gli elementi di compilazione, i registri e la release finale. Una minaccia può penetrare attraverso dipendenze alterate o processi compromessi. Inizia identificando ogni componente rivolto al cliente rispetto a un framework riconosciuto, come la guida NIST o i principi SSCS. I team possono quindi apprendere dove mancano le prove, applicare pratiche di codifica sicura e firmare gli output con Cosign. Questo approccio basato su framework ti consente di imporre l'assurance lungo tutta la catena invece di fare affidamento su un unico punto di controllo. Ogni parte può tracciare ciò che è entrato nella compilazione, come è stato gestito e quali prove supportano il deployment.
[object Object]

Costruisci l'assurance della release su controlli verificabili

Progetti Private Harbor, policy Trivy, firma Cosign e giurisdizione europea
Community@2x.png
Limita l'accesso al registro
Cyber Security@2x.png
Blocca le vulnerabilità note
Magnifying Glass Check@2x.png
Verifica l'origine e la resilienza

Proteggi ogni fase che gli attaccanti possono prendere di mira

Cos'è la sicurezza della supply chain in un ambiente containerizzato moderno?

Cos'è la sicurezza della supply chain in un ambiente containerizzato moderno? Protegge il percorso dal codice sorgente e dalle dipendenze di terze parti attraverso sistemi di build, archiviazione delle immagini ed endpoint di deployment. La sicurezza della supply chain del software tratta questi processi come collegati, poiché un attacco a un'estremità può indebolire ogni controllo successivo.

Protezione del repository di origine

Un repository di origine è un obiettivo chiaro. Un malintenzionato potrebbe rubare le credenziali, alterare il codice, disabilitare una regola di revisione o introdurre una dipendenza che sembri legittima. Fonti di download controllate, revisione tra pari obbligatoria e rami protetti costituiscono la prima linea di difesa. I team dovrebbero anche bloccare le versioni delle dipendenze e verificare checksum, licenze e origini invece di accettare input variabili per ogni build. Questi controlli riducono il rischio di importare software dannoso o non autorizzato da terze parti.

Percorsi di attacco all'infrastruttura di build

L'infrastruttura di build presenta diversi percorsi di attacco. Runner compromessi, segreti esposti o immagini di base mutabili possono modificare un artefatto dopo che gli sviluppatori ne hanno approvato l'origine. Isola i processi di build, usa credenziali a breve durata e registra gli input esatti. Questo approccio supporta la sicurezza delle immagini container rendendo più facile tracciare modifiche al codice impreviste.

Controlli dal registro al cluster

Il percorso dal registro al cluster necessita di controlli indipendenti. Un utente malintenzionato potrebbe sostituire un'immagine approvata, riutilizzare un vecchio tag o sfruttare autorizzazioni di distribuzione eccessive. L'accesso con privilegi minimi limita ciò che ogni identità può pubblicare o recuperare. I riferimenti immutabili collegano i manifest a immagini precise, mentre Kyverno può rifiutare le release prive di prove attendibili o che violano i requisiti di sicurezza.

Una gestione efficace della supply chain del software inizia con un inventario. Registra le librerie di prima e terza parte, le immagini di base, le licenze e gli strumenti di build utilizzati da ogni applicazione. Collega ogni distinta base del software (SBOM) al progetto, al commit e all'esecuzione della pipeline che ha prodotto il relativo artefatto. Questa relazione aiuta i team di sicurezza informatica a identificare i servizi interessati quando un componente sensibile viene compromesso. Scegli uno strumento che esporti prove leggibili dalla macchina e confronti le release tramite automazione. L'inventario dovrebbe svilupparsi insieme al software, piuttosto che dipendere da un lavoro manuale periodico. Assegna un referente per le questioni relative alle dipendenze, alle eccezioni e alla risoluzione, in modo che la responsabilità rimanga chiara.
Esegui i test di sicurezza con sufficiente anticipo per fornire agli sviluppatori risultati azionabili. L'automazione della pipeline può esaminare le dipendenze del codice sorgente, i layer dei container e la configurazione prima della promozione. Definisci le soglie di scansione CVE in base all'esposizione del carico di lavoro e all'impatto aziendale, quindi inoltra i risultati negativi al team responsabile. Un controllo fallito dovrebbe bloccare la progressione invece di generare un avviso non letto. Registra il problema, il pacchetto interessato, la gravità e la risposta approvata. Questa prova aiuta a proteggere la qualità della release mantenendo coerenti le decisioni sulla sicurezza della supply chain del software tra le varie applicazioni.
La firma delle immagini dimostra quale processo controllato ha approvato un artefatto. Firma ogni immagine tramite digest immutabile dopo il superamento dei test richiesti, quindi conserva la provenienza che identifica la revisione di origine, il builder e il flusso di lavoro. Evita di firmare solo i tag mutabili, poiché un tag può in seguito fare riferimento a contenuti diversi. Separa le autorizzazioni di firma dall'accesso generale degli sviluppatori e della pipeline. La verifica dovrebbe utilizzare identità attendibili o chiavi pubbliche definite dalla tua organizzazione. Un processo di build compromesso non può quindi creare prove accettabili a meno che non soddisfi anche la policy di firma.
Un admission controller di Kubernetes fornisce il punto decisionale finale prima che i carichi di lavoro entrino in un cluster. Configuralo per rifiutare immagini non firmate, registri non approvati, criteri di vulnerabilità non superati o provenienza mancante. Kyverno e OPA Gatekeeper possono esprimere queste condizioni come policy sottoposte a controllo di versione. Testa ogni regola su carichi di lavoro rappresentativi prima dell'applicazione in produzione. Inizia in modalità di audit per trovare eccezioni legittime, quindi imposta i controlli maturi in modalità di blocco. Mantieni un percorso di eccezione autorizzato con un proprietario, una motivazione e una data di scadenza. Il cluster può quindi valutare le prove di rilascio in modo coerente, anche quando un controllo precedente viene ignorato o configurato in modo errato.
Una gestione efficace della supply chain del software inizia con un inventario. Registra le librerie di prima e terza parte, le immagini di base, le licenze e gli strumenti di build utilizzati da ogni applicazione. Collega ogni distinta base del software (SBOM) al progetto, al commit e all'esecuzione della pipeline che ha prodotto il relativo artefatto. Questa relazione aiuta i team di sicurezza informatica a identificare i servizi interessati quando un componente sensibile viene compromesso. Scegli uno strumento che esporti prove leggibili dalla macchina e confronti le release tramite automazione. L'inventario dovrebbe svilupparsi insieme al software, piuttosto che dipendere da un lavoro manuale periodico. Assegna un referente per le questioni relative alle dipendenze, alle eccezioni e alla risoluzione, in modo che la responsabilità rimanga chiara.

Assegna la responsabilità tra quattro priorità di governance

Codice affidabile e governance dei fornitori

Un responsabile designato dovrebbe definire i criteri per le fonti e i fornitori affidabili, supportato dalle risorse di approvvigionamento, ingegneria e sicurezza. Usa SLSA come guida per una maggiore integrità della build e provenienza senza presupporre un particolare livello di conseguimento. Adatta le revisioni alle dimensioni dell'organizzazione e al rischio della catena di fornitura del software.

Applicazione delle policy e infrastruttura conforme

I responsabili della sicurezza e della piattaforma dovrebbero tradurre gli obblighi di conformità in un'applicazione misurabile delle policy su codice, cloud e infrastruttura. Definisci chi può approvare le eccezioni, quali prove deve fornire e come i controlli soddisfano i requisiti interni.

Documentazione, audit e prove

Assegna una risorsa responsabile per mantenere la documentazione relativa a decisioni, dipendenze e modifiche ai controlli. Audit regolari dovrebbero verificare se i record corrispondono alla pratica operativa. Fornisci ai revisori un supporto sufficiente per risalire al proprietario di un problema, al rilascio interessato e alla risoluzione.

Prontezza agli incidenti e responsabilità di rimedio

Un responsabile della sicurezza deve coordinare i ruoli di risposta prima che un malintenzionato li metta alla prova. Predisponi un piano per affrontare eventuali problemi, che comprenda le fasi di valutazione iniziale, contenimento, comunicazione con le parti interessate e ripristino. Ogni azione necessita di un responsabile, risorse di supporto e tempistiche adeguate all'esposizione al rischio dell'organizzazione.

Gestisci Harbor attraverso quattro pilastri di sicurezza

Controlla l'accesso in modo preciso

Harbor supporta l'RBAC a livello di progetto e di team per separare i carichi di lavoro e le responsabilità aziendali. Crea account robot con autorizzazioni limitate per le attività di push e pull nell'ambito del CI/CD, anziché condividere credenziali generiche degli utenti. Abbina ogni identità a uno scopo, aggiorna la sua chiave segreta e rimuovi gli accessi non utilizzati. Questa pratica limita l'impatto dell'esposizione delle credenziali proteggendo al contempo la pubblicazione quotidiana.

Rileva continuamente i componenti non sicuri

Combina controlli Trivy continui con l'analisi della composizione del software (SCA) e la gestione delle dipendenze. Questi strumenti rilevano vulnerabilità note, pacchetti obsoleti e indicatori di codice dannoso all'interno di ogni componente. Produci un report chiaro per ogni rilascio, includendo gravità, posizione e stato di risoluzione. I team possono quindi distinguere i risultati bloccanti dalle eccezioni accettate e notare quando nuove informazioni influenzano gli artefatti archiviati.

Connetti i flussi di lavoro di sviluppo

Integra la piattaforma con GitLab CI, Tekton e altri flussi di lavoro di sviluppo approvati. Mantieni le decisioni sulle policy vicine alla pipeline in modo che un controllo fallito restituisca un feedback utile prima della promozione. I riferimenti alla gestione del codice sorgente (SCM) dovrebbero collegare ogni artefatto al suo commit, all'esecuzione della build e al proprietario. I team DevSecOps hanno quindi un registro coerente invece di prove separate sparse tra i sistemi.

Prepara la risposta operativa

Mantieni un piano di risposta agli incidenti per credenziali compromesse, immagini non sicure e controlli falliti. Definisci chi sospende la distribuzione, rimuove una versione interessata, indaga sull'accesso e approva il ripristino. Gli avvisi necessitano di un responsabile e di un percorso di risposta previsto; generarli da soli non riduce il rischio. Esegui esercitazioni per confermare che i team di sicurezza e di piattaforma siano in grado di trovare il report pertinente, isolare il contenuto e comunicare le decisioni. Questo pilastro operativo trasforma il rilevamento in un'azione tempestiva attraverso la piattaforma di distribuzione.

Preserva prove affidabili per ogni rilascio

La visibilità del rilascio dipende da prove che mostrano chi ha prodotto un artefatto, da dove proviene e come è stato testato. Genera e conserva i risultati di Trivy, i dati della distinta base del software e le firme per ogni immagine e set di grafici Helm. Ciò consente all'organizzazione di identificare ogni tipo di contenuto e indagare su un potenziale problema di sicurezza. Integra i controlli con GitLab CI per automatizzare il feedback degli sviluppatori prima che il software entri nell'ambiente controllato. Un test coerente supporta anche la consapevolezza della sicurezza mostrando perché un rilascio non è riuscito. Proteggi le chiavi di firma Cosign tramite OVHcloud Key Management Service, utilizzando l'archiviazione basata su HSM FIPS 140-2. La gestione centralizzata delle chiavi aiuta ad assicurare che ogni firma generata sia legata a materiale crittografico controllato anziché a un segreto di pipeline esposto.
[object Object]
Applica la tua policy di rilascio dei container con OVHcloud
Costruisci un percorso controllato dall'output CI/CD al deployment Kubernetes con Managed Private Registry e Managed Kubernetes Service. Valuta come la convalida del registro, le prove di rilascio e l'applicazione a livello di cluster possano bloccare immagini non scansionate, non firmate o vulnerabili prima della produzione. Scopri Managed Private Registry, quindi valuta l'integrazione Kubernetes per i tuoi carichi di lavoro, il modello di policy e le responsabilità operative.
Esplora il percorso del registro