Minacce alla catena di fornitura del software

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

I vettori d'attacco per le catene di fornitura software sono i vari modi in cui qualcuno può intenzionalmente o accidentalmente danneggiare il tuo software.

I rischi dei software vulnerabili includono la fuga di credenziali o dati riservati, il danneggiamento dei dati, l'installazione di malware e l'interruzione delle applicazioni. Problemi che si traducono in perdita di tempo, denaro e fiducia dei clienti.

I punti di accesso per le minacce coprono l'intero ciclo di vita del software e possono avere origine all'interno o all'esterno della tua organizzazione.

Un diagramma che mostra i punti di ingresso per gli attacchi alla catena di fornitura del software

La legenda del diagramma include due insiemi di minacce:

  • Le lettere da A a H indicano i vettori di attacco della catena di fornitura del software che vengono descritti come minacce minaccia nel framework Supply Chain Levels for Software Artifacts (SLSA) della catena di fornitura.
  • I numeri da 1 a 4 indicano vettori di attacco aggiuntivi che il framework SLSA non descrive direttamente.

Software Delivery Shield, una soluzione completamente gestita per la sicurezza della catena di fornitura del software su Google Cloud, incorpora le best practice utili per mitigare entrambi gli insiemi di minacce.

Le sottosezioni in questo documento descrivono le minacce nel contesto di origine, build, deployment e dipendenze.

Minacce di origine

Queste minacce influiscono sull'integrità del codice sorgente.

  • 1: scrivi codice non sicuro. La mancanza di pratiche di codifica sicure può causare la scrittura involontaria del codice in alcune parti. Le workstation non sicure degli sviluppatori possono anche introdurre codice dannoso o non sicuro. Le mitigazioni includono:

    • Impostazione dei criteri per le workstation di sviluppo. Cloud Workstations fornisce workstation preconfigurate completamente gestite, che puoi personalizzare per adattarle ai tuoi requisiti.
    • Scansione locale del codice. La protezione dell'origine di Cloud Code (anteprima privata) fornisce un feedback sulla sicurezza in tempo reale, incluse informazioni sulle vulnerabilità e sulle licenze per le dipendenze. Gli sviluppatori possono utilizzare anche l'API On-Demand Scanning per analizzare le vulnerabilità dei container del sistema operativo e delle pacchetti di linguaggio.
    • Informazioni sulle pratiche per rendere più sicuro il codice.
  • A: invia il codice errato al repository di origine. Non include solo codice dannoso, ma anche codice che introduce involontariamente vulnerabilità a un attacco, come lo cross-site scripting. Le mitigazioni includono:

    • Richiesta di revisione da parte di persone fisiche per modifiche al codice sorgente.
    • Utilizzo di strumenti di analisi del codice e analisi tramite lint che si integrano con gli IDE e i sistemi di controllo del codice sorgente.
  • B: compromettere il sistema di controllo dei contenuti. Limitare l'accesso al sistema di controllo del codice sorgente e ad altri sistemi nella pipeline di build e l'uso dell'autenticazione a più fattori aiuta a ridurre questo rischio.

Quando valuti l'integrità della tua origine, esamina anche gli script e la configurazione di supporto che utilizzi per creare ed eseguire il deployment del software. Includili nel sistema di controllo del codice sorgente e nei processi di revisione del codice, in modo da poter rischiare le vulnerabilità in questi file.

Consulta Salvaguardia della fonte per saperne di più sulla protezione della fonte.

Crea minacce

Queste minacce compromettono il software quando lo crei o crei un pacchetto o inducono con l'inganno i consumatori a utilizzare il software sbagliato.

  • C: crea con origini non provenienti dal sistema di controllo dell'origine attendibile. Le mitigazioni che contribuiscono a ridurre questo rischio includono:
    • L'utilizzo di servizi di compilazione, come Cloud Build, che generano informazioni sulla provenienza in modo da poter verificare che le build utilizzano l'origine attendibile.
    • Posizionare l'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione di dati dalle tue build. Per i servizi Google Cloud, utilizza i controlli di servizio VPC.
    • Archiviazione e utilizzo di copie attendibili di dipendenze open source necessarie in un archivio di artefatti privato, ad esempio Artifact Registry.
  • D: compromettere il sistema di compilazione. Le mitigazioni che contribuiscono a ridurre questo rischio includono:
    • Segui il principio del privilegio minimo limitando l'accesso diretto al sistema di compilazione alle persone che lo richiedono. In Google Cloud puoi concedere ruoli predefiniti appropriati o creare ruoli personalizzati.
    • Utilizzare servizi di build gestiti come Cloud Build. Cloud Build esegue build temporanee configurando un ambiente VM per ogni build ed eliminandolo dopo la build.
    • Posiziona l'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione di dati dalle tue build. Per i servizi Google Cloud, utilizza i controlli di servizio VPC.
  • F: pacchettizza e pubblica software creato all'esterno del processo ufficiale. I sistemi di compilazione che generano e firmano la provenienza delle build consentono di verificare che il software sia stato creato da un sistema di compilazione affidabile.
  • G: compromette il repository in cui archivi il software per gli utenti interni o esterni. Le mitigazioni che contribuiscono a ridurre questo rischio includono:
    • Archiviazione e utilizzo di copie attendibili di dipendenze open source necessarie in un archivio privato, ad esempio Artifact Registry.
    • Convalida della provenienza della build e dell'origine.
    • Limitazione delle autorizzazioni di caricamento ad account non umani dedicati e ad amministratori del repository. Su [Google Cloud, gli account di servizio agiscono per conto di servizi e applicazioni.

Minacce di deployment e runtime

  • H: risolvere le dipendenze specificando un intervallo di versioni o un tag non collegato definitivamente a una versione di build specifica può causare diversi problemi:

    • Le build non sono riproducibili perché le dipendenze utilizzate da una build per la prima volta possono essere diverse dalle dipendenze utilizzate dalla build per le esecuzioni future della stessa build.
    • Una dipendenza potrebbe risolvere una versione compromessa o una versione con modifiche che causano l'interruzione del software. I malintenzionati possono approfittare di questa incertezza per far sì che la tua build scelga la versione di un pacchetto invece della versione che volevi usare. Diverse best practice per le dipendenze possono aiutare a ridurre i rischi di dipendenza dalla dipendenza.
  • 2: compromette il processo di deployment. Se utilizzi un processo di deployment continuo, la sua compromissione può introdurre modifiche indesiderate al software che distribuisci agli utenti. Puoi mitigare il rischio limitando l'accesso al tuo servizio di deployment e testando le modifiche negli ambienti di pre-produzione. Google Cloud Deploy può aiutarti a gestire il processo di distribuzione continua e la promozione tra i diversi ambienti.

  • 3: esegui il deployment di software compromesso o non conforme. L'applicazione dei criteri di deployment può aiutare a ridurre questo rischio. Puoi utilizzare l'autorizzazione binaria per verificare che le immagini container siano conformi ai criteri dei criteri e bloccare il deployment delle immagini container da origini non attendibili.

  • 4: vulnerabilità e configurazione errata nel software in esecuzione.

    • Nuove vulnerabilità vengono scoperte regolarmente, il che significa che nuovi risultati possono modificare il livello di rischio per le applicazioni in produzione.
    • Alcune configurazioni aumentano il rischio di accesso non autorizzato, ad esempio l'esecuzione come utente root o l'escalation dei privilegi all'esecuzione di un container.

    La dashboard per la strategia di strategia di sicurezza GKE mostra le informazioni sulle vulnerabilità del sistema operativo e sui problemi di configurazione nei carichi di lavoro in esecuzione.

    In Cloud Run, puoi anche visualizzare insight sulla sicurezza sulle revisioni di cui hai eseguito il deployment, comprese le vulnerabilità note nelle immagini container di cui hai eseguito il deployment.

Vedi Salvaguardie build per saperne di più sulla protezione della tua origine e Misure di protezione per scoprire di più sulla protezione dei deployment.

Minacce di dipendenza

Le dipendenze includono dipendenze dirette nelle build. Tutte le dipendenti transitorie, l'albero ricorsivo delle dipendenze a valle delle dipendenze dirette.

Nel diagramma, E indica l'uso di una dipendenza errata nella build. Una cattiva dipendenza può includere:

  • Qualsiasi software da cui dipende l'applicazione, inclusi i componenti sviluppati internamente, il software commerciale di terze parti e il software open source.
  • Vulnerabilità provenienti da uno qualsiasi degli altri vettori di attacco. Ad esempio:
    • Un utente malintenzionato accede al tuo sistema di controllo del codice sorgente e modifica la versione di una dipendenza che utilizzi.
    • La build include un componente sviluppato da un altro team della tua organizzazione. Pubblicano la build e pubblicano il componente direttamente dai propri ambienti di sviluppo locale e introducono accidentalmente una vulnerabilità in una libreria che usano localmente solo per i test e il debug.
  • Rimozione intenzionale di una dipendenza open source da un repository pubblico. La rimozione può causare l'interruzione delle pipeline che utilizzano, se recuperano la dipendenza direttamente dal repository pubblico.

Consulta le best practice per le dipendenze per scoprire come ridurre i rischi.

Mitigazione delle minacce

L'integrità complessiva della tua catena di fornitura è importante solo quanto la sua parte più vulnerabile. Il trascurare un vettore aumenta il rischio di attacco in quella parte della tua catena di fornitura.

Allo stesso tempo, non è necessario modificare tutto contemporaneamente. L'effetto dell'azione cumulativa, più comunemente noto come modello di formaggio svizzero, si applica alla sicurezza della catena di fornitura del software. Ogni mitigazione implementata implementa il rischio, e quando combini le mitigazioni nella tua catena di fornitura aumenti la protezione contro diversi tipi di attacchi.

  • Valuta il tuo livello di sicurezza utilizzando framework e strumenti che ti aiutino a valutare la capacità della tua organizzazione di rilevare, rispondere e risolvere le minacce.
  • Scopri le best practice per proteggere la tua catena di fornitura software e i prodotti Google Cloud progettati per supportare queste pratiche.
  • Utilizza Software Delivery Shield per proteggere il tuo software nella catena di fornitura del software su Google Cloud. Puoi implementare i servizi gradualmente, in base alle tue priorità e all'infrastruttura esistente.

Passaggi successivi