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 legati al software vulnerabile includono la perdita di credenziali o dati riservati, la corruzione dei dati, l'installazione di malware e interruzioni delle applicazioni. Questi problemi comportano la perdita 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 serie di minacce:
- Le lettere da A a H indicano i vettori di attacco nella catena di fornitura del software, descritti come minacce di minacce nel framework SLSA (Supply chain Levels for Software Artifacts).
- I numeri da 1 a 4 indicano i vettori di attacco aggiuntivi che il framework SLSA non descrive direttamente.
Software Delivery Shield, una soluzione per la sicurezza della catena di fornitura del software completamente gestita su Google Cloud, incorpora best practice per aiutarti a mitigare entrambi gli insiemi di minacce.
Le sottosezioni di questo documento descrivono le minacce nel contesto di origine, build, deployment e dipendenze.
Minacce origine
Queste minacce hanno un impatto sull'integrità del codice sorgente.
1: scrivi codice non sicuro. La mancanza di pratiche di codifica sicure può portare alla scrittura del codice che include involontariamente delle vulnerabilità. Anche le workstation per sviluppatori non sicure possono introdurre codice dannoso o non sicuro. Le mitigazioni includono:
- Impostazione di criteri per le workstation degli sviluppatori. Cloud Workstations fornisce workstation preconfigurate completamente gestite che puoi personalizzare per soddisfare i tuoi requisiti.
- 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 pratiche per rendere il codice più sicuro.
R: invia il codice non valido al repository di codice sorgente. Non solo include codice dannoso, ma anche codice che introduce involontariamente vulnerabilità a un attacco come il cross-site scripting. Le mitigazioni includono:
- Richiesta di revisione da parte di persone fisiche per modifiche al codice sorgente.
- Utilizzo di strumenti di scansione 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 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 consente di mitigare questo rischio.
Durante la valutazione dell'integrità del codice sorgente, 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 rischiare la presenza di vulnerabilità in questi file.
Consulta Salvaguardia delle fonti per scoprire di più sulla protezione della tua fonte.
Creare minacce
Queste minacce compromettono il tuo software quando lo crei o lo pacchetti, oppure quando inducono con l'inganno i consumatori del tuo software a utilizzare una versione non valida.
- C: la build utilizza un'origine che non proviene dal sistema di controllo del codice sorgente attendibile.
Le mitigazioni che contribuiscono a ridurre questo rischio includono:
- Utilizzare servizi di build, come Cloud Build, che generano informazioni sulla provenienza in modo da poter verificare che le build utilizzino un'origine attendibile.
- Collocare la tua infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione dei dati dalle tue build. Per i servizi Google Cloud, utilizza Controlli di servizio VPC.
- Archiviazione e utilizzo di copie attendibili di dipendenze open source necessarie in un archivio di artefatti privato come Artifact Registry.
- D: comprometti il sistema di compilazione. Le mitigazioni che aiutano 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 i ruoli predefiniti appropriati o creare ruoli personalizzati.
- Utilizzare servizi di build gestiti come Cloud Build. Cloud Build esegue build di build temporanee configurando un ambiente VM per ogni build e distruggendolo dopo la build.
- Posiziona la tua infrastruttura CI/CD in un perimetro di rete per impedire l'esfiltrazione dei dati dalle tue build. Per i servizi Google Cloud, utilizza Controlli di servizio VPC.
- F: pacchettizza e pubblica software creato al di fuori del processo ufficiale. Crea sistemi che generano e Firmano la provenienza della build. Ti consentono di convalidare che il tuo software è stato creato da un sistema di compilazione attendibile.
- G: compromettono il repository in cui è archiviato il software per gli utenti interni o esterni. Le mitigazioni che aiutano a ridurre questo rischio
includono:
- Archiviazione e utilizzo di copie attendibili di dipendenze open source necessarie in archivi di artefatti privati come Artifact Registry.
- Convalida della provenienza della build e dell'origine.
- Limitazione delle autorizzazioni di caricamento ad account non umani dedicati e agli amministratori di 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 usate la prima volta da una build possono essere diverse da quelle utilizzate dalla build per le esecuzioni future della stessa build.
- Una dipendenza potrebbe risolversi in una versione compromessa o in una versione con modifiche che danneggiano il software. I malintenzionati possono sfruttare questa incertezza per far sì che la tua build scelga la versione di un pacchetto anziché quella che intendevi utilizzare. Una serie di best practice per le dipendenze può aiutare a ridurre i rischi della confusione tra dipendenze.
2: compromettere il processo di deployment. Se utilizzi un processo di deployment continuo, la compromissione di tale processo può introdurre modifiche indesiderate al software che fornisci agli utenti. Puoi mitigare i rischi 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 continua e la promozione tra ambienti.
3: esegui il deployment di software compromesso o non conforme. L'applicazione dei criteri di deployment può contribuire a mitigare questo rischio. Puoi utilizzare Autorizzazione binaria per verificare che le immagini container siano conformi ai criteri dei criteri e bloccare il deployment di immagini container da fonti non attendibili.
4: Vulnerabilità ed errori di configurazione nel software in esecuzione.
- Le nuove vulnerabilità vengono scoperte regolarmente, il che significa che i nuovi risultati possono modificare il livello di rischio per la sicurezza per le tue applicazioni in produzione.
- Alcune configurazioni aumentano il rischio di accessi non autorizzati, ad esempio l'esecuzione come utente root o l'escalation dei privilegi al momento dell'esecuzione di un container.
La dashboard della strategia di sicurezza di GKE mostra 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 delle revisioni di cui hai eseguito il deployment, incluse le vulnerabilità note nelle immagini container di cui hai eseguito il deployment.
Consulta Salvaguardia delle build per scoprire di più sulla protezione dell'origine e Salvaguardia dei 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 la struttura ricorrente delle dipendenze a valle delle dipendenze dirette.
Nel diagramma, la lettera E indica l'utilizzo di una dipendenza errata nella build. Una cattiva dipendenza può includere:
- Qualsiasi software da cui dipende l'applicazione, inclusi componenti sviluppati internamente, software commerciali di terze parti, software open source.
- Vulnerabilità provenienti da uno degli altri vettori d'attacco. Ad esempio:
- Un utente malintenzionato ottiene l'accesso al sistema di controllo del codice sorgente e modifica la versione di una dipendenza utilizzata nel progetto.
- La build include un componente sviluppato da un altro team della tua organizzazione. Pubblica la build e pubblica il componente direttamente dai propri ambienti di sviluppo locali e introducono accidentalmente una vulnerabilità in una libreria che usano 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 in uso se recuperano la dipendenza direttamente dal repository pubblico.
Consulta le best practice per le dipendenze per scoprire come ridurre i rischi.
Mitigare le minacce
L'integrità complessiva della catena di fornitura è valida 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 devi modificare tutto in una volta. 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 riduce il rischio e, quando le combini nella catena di fornitura, aumenti la protezione da diversi tipi di attacchi.
- Valuta la tua postura 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 catena di fornitura del software e i prodotti Google Cloud progettati per supportarle.
- Utilizza Software Delivery Shield per proteggere il tuo software in tutta la catena di fornitura del software su Google Cloud. Puoi implementare i servizi gradualmente, 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.
- Scopri di più su Software Delivery Shield.