I vettori di attacco per le catene di fornitura del software sono i vari modi in cui qualcuno può compromettere intenzionalmente o accidentalmente il tuo software.
I rischi del software vulnerabile includono la perdita di credenziali o dati riservati, il danneggiamento dei dati, l'installazione di malware e le interruzioni delle applicazioni. Questi problemi comportano perdite di tempo, denaro e fiducia dei clienti.
I punti di ingresso per le minacce riguardano l'intero ciclo di vita del software e possono provenire dall'interno o dall'esterno della tua organizzazione.
La legenda del diagramma include due insiemi di minacce:
- Le lettere da A a H indicano i vettori di attacco nella catena di fornitura del software che sono descritti come minacce nel framework Supply-chain Levels for Software Artifacts (SLSA).
- I numeri da 1 a 4 indicano vettori di attacco aggiuntivi che il framework SLSA non descrive direttamente.
Google Cloud fornisce un insieme modulare di funzionalità e strumenti che incorporano le best practice per mitigare entrambi gli insiemi di minacce.
Le sottosezioni di 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 programmazione sicura può portare alla scrittura di codice che include involontariamente vulnerabilità. Anche le workstation degli sviluppatori non sicure possono introdurre codice dannoso o non sicuro. Le mitigazioni includono:
- Impostazione delle policy per le workstation degli sviluppatori. Cloud Workstations fornisce workstation completamente gestite e preconfigurate che puoi personalizzare in base alle tue esigenze.
- Scansione locale del codice. Cloud Code source protect (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 eseguire la scansione delle immagini container alla ricerca di vulnerabilità dei pacchetti di sistema operativo e di linguaggio.
- Formazione sulle pratiche per rendere il codice più sicuro.
A: invia codice dannoso al repository di origine. Questo include non solo il codice dannoso, ma anche il codice che introduce involontariamente vulnerabilità a un attacco come lo scripting cross-site. Le mitigazioni includono:
- Richiedi la revisione umana per le modifiche al codice sorgente.
- Utilizza 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 del codice sorgente. Limitare l'accesso al sistema di controllo del codice sorgente e ad altri sistemi nella pipeline di build e utilizzare l'autenticazione a più fattori contribuisce a mitigare questo rischio.
Quando valuti l'integrità dell'origine, esamina anche gli script e le configurazioni di supporto che utilizzi per creare ed eseguire il deployment del software. Includili nei processi di revisione del codice e del sistema di controllo del codice sorgente, in modo da ridurre il rischio di vulnerabilità in questi file.
Per scoprire di più sulla protezione della tua origine, consulta Proteggere l'origine.
Minacce di build
Queste minacce compromettono il software quando lo crei o lo pacchettizzi oppure inducono i consumatori del tuo software a utilizzare una versione errata.
- C: crea la build con codice sorgente non proveniente dal sistema di controllo del codice sorgente attendibile.
Le mitigazioni che contribuiscono a ridurre questo rischio includono:
- Utilizza servizi di build, come Cloud Build, che generano informazioni sulla provenienza in modo da poter convalidare che le build utilizzino un'origine attendibile.
- Posiziona l'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione dei dati dalle build. Per i Google Cloud servizi, utilizza i Controlli di servizio VPC.
- Archivia e utilizza copie attendibili delle dipendenze open source di cui hai bisogno in uno store di artefatti privato come Artifact Registry.
- D: comprometti 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 ne hanno bisogno. In Google Cloud puoi concedere i ruoli predefiniti appropriati o creare ruoli personalizzati.
- Utilizza 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 dei dati dalle build. Per i Google Cloud servizi, utilizza i Controlli di servizio VPC.
- F: pacchettizza e pubblica software creato al di fuori del processo ufficiale. I sistemi di compilazione che generano e firmano la provenienza della build ti consentono di convalidare che il 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 mitigazioni che contribuiscono a ridurre questo rischio includono:
- Archivia e utilizza copie attendibili delle dipendenze open source di cui hai bisogno in store di artefatti privati come Artifact Registry.
- Convalida la provenienza della build e dell'origine.
- Limita le autorizzazioni di caricamento ad account non umani dedicati e agli amministratori del repository. Su Google Cloud, i service account 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 non collegato in modo permanente a una versione di build specifica può causare diversi problemi:
- Le build non sono riproducibili perché le dipendenze utilizzate da una build la prima volta possono essere diverse da quelle utilizzate per le esecuzioni future della stessa build.
- Una dipendenza potrebbe essere risolta in una versione compromessa o in una versione con modifiche che interrompono il software. I malintenzionati possono sfruttare questa incertezza per fare in modo che la 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: comprometti il processo di deployment. Se utilizzi un processo di deployment continuo, la compromissione di questo processo può introdurre modifiche indesiderate al software che fornisci agli utenti. Puoi mitigare 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 delivery continua e la promozione tra gli ambienti.
3: esegui il deployment di software compromesso o non conforme. L'applicazione delle policy di deployment può contribuire a mitigare questo rischio. Puoi utilizzare l'Autorizzazione binaria per convalidare che le immagini container siano conformi ai criteri delle policy e bloccare il deployment delle immagini container da origini non attendibili.
4: vulnerabilità ed errori di configurazione nel software in esecuzione.
- Vengono regolarmente scoperte nuove vulnerabilità, il che significa che i nuovi risultati possono modificare il livello di rischio per la sicurezza delle applicazioni in produzione.
- Alcune configurazioni aumentano il rischio di accesso non autorizzato, ad esempio l'esecuzione come utente root o la possibilità di escalation dei privilegi durante l'esecuzione di un container.
La dashboard della security posture GKE mostra informazioni su vulnerabilità e problemi di configurazione nei workload in esecuzione.
In Cloud Run, puoi anche visualizzare informazioni sulla sicurezza relative alle revisioni di cui hai eseguito il deployment, incluse le vulnerabilità note nelle immagini container di cui hai eseguito il deployment.
Per scoprire di più sulla protezione dell' origine, consulta Proteggere le build e Proteggere i deployment.
Minacce di dipendenza
Le dipendenze includono le dipendenze dirette nelle build e tutte le dipendenze transitive, ovvero l'albero ricorsivo delle dipendenze a valle delle dipendenze dirette.
Nel diagramma, E indica l'utilizzo di una dipendenza errata nella build. Una dipendenza errata può includere:
- Qualsiasi software da cui dipende la tua applicazione, inclusi i componenti sviluppati internamente, il software commerciale di terze parti e il software open source.
- Vulnerabilità derivanti da uno qualsiasi degli altri vettori di attacco. Ad esempio:
- Un attaccante ottiene l'accesso al sistema di controllo del codice sorgente e modifica la versione di una dipendenza utilizzata dal tuo progetto.
- La build include un componente sviluppato da un altro team della tua organizzazione. Il team crea e pubblica il componente direttamente dai propri ambienti di sviluppo locali e introduce accidentalmente una vulnerabilità in una libreria che utilizza solo localmente per test e 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.
Per scoprire come mitigare i rischi, consulta le best practice per le dipendenze.
Mitigare le minacce
L'integrità complessiva della catena di fornitura è forte solo quanto la sua parte più vulnerabile. La mancata considerazione di un vettore d'attacco aumenta il rischio di attacco in quella parte della catena di fornitura.
Allo stesso tempo, non è necessario cambiare tutto in una volta sola. L'effetto dell'atto cumulativo, più comunemente noto come modello a formaggio svizzero, si applica alla sicurezza della catena di fornitura del software. Ogni mitigazione implementata riduce il rischio e, quando combini le mitigazioni nella catena di fornitura, aumenti la protezione da diversi tipi di attacchi.
- Valuta la tua security posture utilizzando framework e strumenti che ti aiutano a valutare la capacità della tua organizzazione di rilevare, rispondere e correggere le minacce.
- Scopri le best practice per proteggere la catena di fornitura del software, e Google Cloud i prodotti progettati per supportare queste pratiche.
- Incorpora Google Cloud le funzionalità di sicurezza nei processi di sviluppo, build, e deployment per migliorare la security posture della catena di fornitura del software del software. Puoi implementare i servizi gradualmente, in base alle tue priorità e all'infrastruttura esistente.
Passaggi successivi
- Valuta la tua security posture.
- Scopri le best practice per proteggere la catena di fornitura del software.