Minacce alla catena di fornitura del software

I vettori di attacco per le catene di approvvigionamento del software sono i vari modi in cui qualcuno può compromettere intenzionalmente o accidentalmente il tuo software.

I rischi del software vulnerabile includono la fuga di credenziali o dati riservati, la corruzione dei dati, l'installazione di malware e l'interruzione delle applicazioni. Questi problemi comportano perdita di tempo, denaro e fiducia dei clienti.

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

Punti di contatto per gli attacchi alla catena di fornitura del software

La legenda del diagramma include due insiemi di minacce:

Google Cloud fornisce un insieme modulare di funzionalità e strumenti che incorporano le best practice per la mitigazione di entrambi i tipi di minacce.

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

Minacce alla fonte

Queste minacce influiscono sull'integrità del codice sorgente.

  • 1: scrivi codice non sicuro. La mancanza di pratiche di programmazione sicure può portare a scrivere codice che include involontariamente vulnerabilità. Anche le stazioni di lavoro degli sviluppatori non sicure possono introdurre codice dannoso o non sicuro. Le misure di mitigazione includono:

    • Impostazione dei criteri per le stazioni di lavoro degli sviluppatori. Cloud Workstations fornisce stazioni di lavoro preconfigurate e completamente gestite che puoi personalizzare in base alle tue esigenze.
    • Scansione locale del codice. Source protect di Cloud Code (anteprima privata) fornisce feedback sulla sicurezza in tempo reale, incluse informazioni su vulnerabilità e licenze per le dipendenze. Gli sviluppatori possono anche utilizzare l'API On-Demand Scanning per analizzare le immagini container alla ricerca di vulnerabilità del sistema operativo e dei pacchetti di linguaggio.
    • Formazione sulle best practice per rendere il codice più sicuro.

  • A: invia codice dannoso al repository di origine. Non è incluso solo il codice dannoso, ma anche il codice che introduce involontariamente vulnerabilità a un attacco come lo cross-site scripting. Le misure di mitigazione includono:

    • Richiesta di revisione da parte di persone fisiche per le modifiche al codice sorgente.
    • Utilizzo di strumenti di scansione e linting del codice che si integrano con IDE e sistemi di controllo del codice sorgente.

  • B: comprometti il sistema di controllo dei file sorgente. Limitare l'accesso al sistema di controllo dell'origine e ad altri sistemi nella pipeline di build e utilizzare l'autenticazione a più fattori contribuisce a mitigare questo rischio.

Quando valuti l'integrità del codice sorgente, esamina anche gli script e le configurazioni di supporto che utilizzi per compilare ed eseguire il deployment del software. Includi li nel tuo sistema di controllo dei file sorgente e nelle procedure di revisione del codice, in modo da ridurre il rischio derivante dalle vulnerabilità in questi file.

Per scoprire di più su come proteggere la fonte, consulta Proteggere l'origine.

Creare minacce

Queste minacce compromettono il software durante la compilazione o il pacchettizzamento oppure ingannano i consumatori del software facendo loro utilizzare una versione non valida.

  • C: compilazione con codice sorgente non proveniente dal sistema di controllo del codice sorgente attendibile. Le misure di mitigazione che contribuiscono a ridurre questo rischio includono:
    • Utilizzo di servizi di compilazione, come Cloud Build, che generano informazioni sull'origine in modo da poter verificare che le tue compilazioni utilizzino una fonte attendibile.
    • Posiziona l'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione di dati dalle build. Per i servizi Google Cloud, utilizza Controlli di servizio VPC.
    • Archiviazione e utilizzo di copie attendibili delle dipendenze open source di cui hai bisogno in un magazzino di artefatti privato come Artifact Registry.
  • D: comprometti il sistema di compilazione. Le misure di mitigazione 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 assegnare ruoli predefiniti appropriati o creare ruoli personalizzati.
    • Utilizza servizi di compilazione gestiti come Cloud Build. Cloud Build esegue build temporanee configurando un ambiente VM per ogni build e distruggendolo al termine della build.
    • Posiziona l'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione di dati dalle build. Per i servizi Google Cloud, utilizza Controlli di servizio VPC.
  • F: pacchettizza e pubblica il software creato al di fuori della procedura ufficiale. I sistemi di build che generano e firmano la provenienza della build ti consentono di verificare che il tuo software sia stato creato da un sistema di compilazione attendibile.
  • G: comprometti il repository in cui memorizzi il software per gli utenti interni o esterni. Le misure di mitigazione che contribuiscono a ridurre questo rischio includono:
    • Archiviazione e utilizzo di copie attendibili delle dipendenze open source di cui hai bisogno in archivi di artefatti privati come Artifact Registry.
    • Convalida della provenienza della build e dell'origine.
    • Limitare le 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: la risoluzione delle dipendenze specificando un intervallo di versioni o un tag che non è associato in modo permanente a una versione di build specifica può comportare diversi problemi:

    • Le build non sono riproducibili perché le dipendenze utilizzate la prima volta possono essere diverse da quelle utilizzate per le esecuzioni future della stessa build.
    • Una dipendenza potrebbe risolvere in una versione compromessa o con modifiche che interrompono il software. Gli utenti malintenzionati possono sfruttare questa incertezza per fare in modo che la tua build scelga la loro versione di un pacchetto anziché quella che intendevi utilizzare. Una serie di best practice per le dipendenze può contribuire a mitigare i rischi di confusione delle dipendenze.

  • 2: compromette la procedura di deployment. Se utilizzi un processo di deployment continuo, la compromissione di questo processo può introdurre modifiche indesiderate al software che offri agli utenti. Puoi ridurre il rischio limitando l'accesso al servizio di deployment e testando le modifiche negli ambienti di pre-produzione. Cloud Deploy può aiutarti a gestire il processo di distribuzione e promozione continua tra gli ambienti.

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

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

    • Vengono scoperte regolarmente nuove vulnerabilità, il che significa che i nuovi risultati possono cambiare il livello di rischio per la sicurezza delle tue applicazioni in produzione.
    • Alcune configurazioni aumentano il rischio di accesso non autorizzato, ad esempio l'esecuzione come utente root o l'autorizzazione dell'escalation dei privilegi durante l'esecuzione di un contenitore.

    La dashboard della postura di sicurezza di GKE mostra informazioni su vulnerabilità e problemi di configurazione nei workload in esecuzione.

    In Cloud Run puoi anche visualizzare approfondimenti sulla sicurezza sulle revisioni di cui è stato eseguito il deployment, incluse le vulnerabilità note nelle immagini dei contenitori di cui è stato eseguito il deployment.

Consulta Proteggere le build per scoprire di più sulla protezione del codice sorgente e Proteggere i deployment per scoprire di più sulla protezione dei deployment.

Minacce di dipendenza

Le dipendenze includono le dipendenze dirette nelle build e tutte le dipendenze transitive, ovvero l'albero ricorsivo delle dipendenze che si trovano a valle delle dipendenze dirette.

Nel diagramma, E indica l'utilizzo di una dipendenza non valida nella build. Una dipendenza sbagliata può includere:

  • Qualsiasi software di cui dipende la tua 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 malintenzionato ottiene l'accesso al tuo sistema di controllo dell'origine e modifica la versione di una dipendenza utilizzata dal tuo progetto.
    • La build include un componente sviluppato da un altro team della tua organizzazione. Compila e pubblica il componente direttamente dai propri ambienti di sviluppo locale e introduce accidentalmente una vulnerabilità in una libreria che utilizza solo localmente 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 di consumo se recuperano la dipendenza direttamente dal repository pubblico.

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

Mitigazione delle minacce

L'integrità complessiva della catena di approvvigionamento è forte soltanto quanto la sua parte più vulnerabile. Se trascuri un vettore di attacco, aumenti il rischio di attacco in quella parte della catena di approvvigionamento.

Allo stesso tempo, non è necessario cambiare tutto contemporaneamente. L'effetto cumulativo, più comunemente noto come modello di formaggio svizzero, si applica alla sicurezza della catena di fornitura del software. Ogni misura di mitigazione che implementi riduce il rischio e, se le combini nella tua catena di approvvigionamento, aumenti la protezione contro diversi tipi di attacchi.

  • Valuta la tua strategia di sicurezza utilizzando framework e strumenti che ti aiutano 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 del software e i prodotti Google Cloud progettati per supportare queste pratiche.
  • Incorpora le funzionalità di sicurezza di Google Cloud nei tuoi processi di sviluppo, compilazione e deployment per migliorare la strategia di sicurezza della tua catena di fornitura del software. Puoi implementare i servizi gradualmente, in base alle tue priorità e all'infrastruttura esistente.

Passaggi successivi