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 divulgazione di credenziali o dati riservati, il danneggiamento dei dati, l'installazione di malware e interruzioni delle applicazioni. Questi problemi comportano perdite di tempo, denaro e fiducia dei clienti.
I punti di ingresso per le minacce coprono l'intero ciclo di vita del software e possono avere origine all'interno o all'esterno della tua organizzazione.
La legenda del diagramma include due gruppi 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 i tipi 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 sicure può portare a scrivere codice che include involontariamente vulnerabilità. Le workstation degli sviluppatori non sicure possono anche introdurre codice dannoso o non sicuro. Le misure di mitigazione includono:
- Impostazione dei criteri per le workstation degli sviluppatori. Cloud Workstations fornisce workstation preconfigurate e completamente gestite 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 analizzare le immagini container alla ricerca di vulnerabilità del sistema operativo e dei pacchetti di linguaggio.
- Formazione sulle pratiche per rendere il codice più sicuro.
A: invia codice dannoso al repository di origine. Ciò include non solo codice dannoso, ma anche codice che introduce involontariamente vulnerabilità a un attacco come lo scripting cross-site. Le misure di mitigazione includono:
- Richiedere la revisione umana 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 di origine. 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à dell'origine, esamina anche gli script e le configurazioni di supporto che utilizzi per creare ed eseguire il deployment del software. Includili nel tuo sistema di controllo del codice sorgente e nei processi di revisione del codice, in modo da ridurre il rischio di vulnerabilità in questi file.
Per scoprire di più sulla protezione della tua fonte, consulta Proteggere la fonte.
Creare minacce
Queste minacce compromettono il tuo software durante la creazione o il packaging oppure inducono i consumatori del tuo software a utilizzare una versione dannosa.
- C: build con origine non proveniente dal sistema di controllo del codice sorgente attendibile.
Le mitigazioni che contribuiscono a ridurre questo rischio includono:
- Utilizzo di servizi di build, come Cloud Build, che generano informazioni sulla provenienza in modo da poter verificare che le tue build utilizzino una fonte attendibile.
- Posizionamento dell'infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione di dati dalle build. Per i servizi Google Cloud , utilizza i Controlli di servizio VPC.
- Archiviazione e utilizzo di copie attendibili delle dipendenze open source necessarie in un archivio 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 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 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 i Controlli di servizio VPC.
- F: impacchettare e pubblicare 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 unsistema di compilazioned attendibile.
- G: comprometti il repository in cui memorizzi il software per i tuoi utenti interni o esterni. Le mitigazioni che contribuiscono a ridurre questo rischio
includono:
- Archiviazione e utilizzo di copie attendibili delle dipendenze open source necessarie in archivi di artefatti privati come Artifact Registry.
- Convalida della provenienza della build e dell'origine.
- Limitando le autorizzazioni di caricamento ad account non umani dedicati e agli 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 non collegato in modo permanente a una versione specifica della build può causare diversi problemi:
- Le build non sono riproducibili perché le dipendenze che una build utilizza la prima volta possono essere diverse da quelle che utilizza 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 funzionamento del software. I 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: Comprometti la procedura di deployment. Se utilizzi un processo di distribuzione continua, comprometterlo può introdurre modifiche indesiderate al software che fornisci ai tuoi 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 continuous delivery e la promozione tra gli ambienti.
3: deployment di software compromesso o non conforme. L'applicazione dei criteri di implementazione può contribuire a mitigare questo rischio. Puoi utilizzare l'autorizzazione binaria per verificare che le immagini container siano conformi ai criteri e bloccare il deployment di immagini container da fonti 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 tue applicazioni in produzione.
- Alcune configurazioni aumentano il rischio di accesso non autorizzato, ad esempio l'esecuzione come utente root o l'escalation dei privilegi durante l'esecuzione di un container.
La dashboard sulla 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 delle revisioni di cui è stato eseguito il deployment, incluse le vulnerabilità note nelle immagini container di cui è stato eseguito il deployment.
Consulta Proteggere le build per scoprire di più sulla protezione della tua origine e Proteggere i deployment per scoprire di più sulla protezione dei deployment.
Minacce alle dipendenze
Le dipendenze includono le dipendenze dirette nelle build, nonché tutte le dipendenze transitive, ovvero l'albero ricorsivo delle dipendenze a valle delle dipendenze dirette.
Nel diagramma, E indica l'utilizzo di una dipendenza non valida nella build. Una dipendenza errata può includere:
- Qualsiasi software da cui dipende la tua applicazione, inclusi i componenti che sviluppi internamente, software commerciale di terze parti e 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 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. Creano e pubblicano il componente direttamente dai loro ambienti di sviluppo locali e introducono accidentalmente una vulnerabilità in una libreria che utilizzano 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.
Consulta le best practice per le dipendenze per scoprire come mitigare i rischi.
Mitigazione delle minacce
L'integrità complessiva della catena di fornitura è forte solo quanto la sua parte più vulnerabile. Trascurare un vettore di 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 cumulativo degli atti, più comunemente noto come modello del formaggio svizzero, si applica alla sicurezza della catena di fornitura del software. Ogni mitigazione che implementi riduce il rischio e, quando combini le mitigazioni nella catena di fornitura, 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 Google Cloud prodotti progettati per supportare queste pratiche.
- Incorpora Google Cloud funzionalità di sicurezza nei processi di sviluppo, compilazione e deployment per migliorare la security posture della tua catena di fornitura del software. Puoi implementare i servizi in modo graduale, in base alle tue priorità e all'infrastruttura esistente.
Passaggi successivi
- Valuta la tua strategia di sicurezza.
- Scopri le best practice per proteggere la catena di fornitura del software.