Fonte di protezione

Questo documento descrive le best practice per la gestione del codice sorgente del software.

Un passaggio fondamentale che i team software svolgono per gestire la propria origine è l'adozione di un sistema di controllo della versione (VCS). I sistemi di controllo della versione forniscono cronologia e verificabilità delle modifiche. I sistemi di controllo delle versioni ospitate come GitHub offrono vantaggi aggiuntivi come disponibilità, stabilità, controlli di sicurezza, strumenti integrati di revisione del codice e integrazione con altri servizi cloud.

Sebbene la maggior parte dei team utilizzi oggi il controllo della versione, ci sono molti modi per configurare un sistema di controllo della versione e le sue integrazioni con altre parti della pipeline CI/CD.

Questo documento illustra le considerazioni sulla sicurezza della catena di fornitura del software per la configurazione di un sistema di controllo della versione. Descrive le best practice in Supply chain Levels for Software Artifacts, un framework per la salvaguardia della catena di fornitura del software. Il framework include requisiti a diversi livelli per aiutarti a implementare modifiche in modo incrementale, inclusi i requisiti delle origini.

Un sistema di controllo della versione con cronologia delle modifiche e revisioni immutabili è un requisito di livello 2 di SLSA. Ti consigliamo di allinearti al livello SLSA 2 come livello di riferimento iniziale per la catena di fornitura del software.

Al livello SLSA 3, le piattaforme di origine e build aderiscono a requisiti di sicurezza più severi, tra cui la cronologia delle fonti verificate e i criteri di conservazione delle fonti. Il livello 4 del programma SLSA aggiunge recensioni di due persone ai requisiti della fonte.

Usa il controllo della versione per altre origini dell'applicazione

L'archiviazione dell'origine dell'applicazione nel controllo della versione è una pratica consolidata quando sono necessari revisioni e controlli storici. Tuttavia, esistono anche altri tipi di origine che traggono vantaggio dal controllo della versione, tra cui configurazione, criteri e dati. Sono inclusi i file che:

  • Impatto sulla disponibilità e sulla sicurezza della tua infrastruttura di computing
  • Richiedi collaborazione per finalizzare
  • Richiedere una procedura di approvazione ripetibile
  • Richiedi una cronologia delle modifiche

Ecco alcuni esempi:

  • Infrastructure-as-code: le organizzazioni che vogliono gestire la propria infrastruttura in modo scalabile e sicuro utilizzano Infrastructure as Code come metodologia chiave. Ad esempio, puoi archiviare moduli Terraform nel controllo della versione che creano repository Artifact Registry.
  • Gestione della configurazione: la gestione della configurazione è simile all'infrastruttura come codice, ma si concentra sulla gestione della configurazione delle applicazioni con strumenti come Ansible, Puppet e Chef. Puoi archiviare e gestire i file di configurazione delle applicazioni nel tuo sistema di controllo della versione.
  • Configurazioni dei database e script di migrazione: archivia la configurazione e gli script per i database del prodotto e per i database di analisi o logging.
  • Blocchi note Jupyter: esistono diversi modi per lavorare con i blocchi note archiviati in GitHub, tra cui [extension for JupyterLab][jlab], Colaboratory e [Vertex AI Workbench][vertex]
  • Criteri di sicurezza: archivia i file dei criteri per l'applicazione automatica dei criteri. Ad esempio, puoi archiviare i criteri Gatekeeper che consentono o negano il comportamento di deployment in GKE o i criteri di Sense che impediscono a Terraform di eseguire il provisioning dell'infrastruttura che viola i criteri.

Il controllo della versione è una delle funzionalità tecniche identificate dalla ricerca DevOps di DORA che consente di ottenere prestazioni dell'organizzazione e di distribuzione del software più elevate. L'archiviazione di script, codice sorgente e file di configurazione nel controllo della versione consente di riprodurre e recuperare gli ambienti, tracciare e controllare le modifiche e risolvere rapidamente i problemi.

Configurazione del repository

I repository sono l'unità logica fondamentale per organizzare il codice e i ruoli, le autorizzazioni, le integrazioni e le approvazioni correlati.

Di seguito sono riportati alcuni problemi che possono verificarsi con la configurazione del repository:

  • La configurazione del repository non è standardizzata, pertanto diventa difficile garantire che la sicurezza del repository sia appropriata per l'applicazione che rappresenta, in particolare nello scenario comune in cui un'organizzazione ha centinaia o migliaia di repository.
  • Chiunque crei il repository diventa un proprietario con autorizzazioni amministrative complete, tra cui la possibilità di eseguire unioni senza altri revisori.
  • L'integrazione di repository con analisi del codice, server di build, tracker dei problemi, servizi di notifica e altre parti dell'infrastruttura CI/CD può essere un lavoro considerevole. La presenza di un metodo standard di creazione e configurazione dei repository consente di risparmiare lavoro ripetitivo e supporta le best practice.

Per risolvere questi problemi, le best practice includono:

  • Configura repository con un processo automatizzato, ripetibile e attento alla sicurezza. Ad esempio, puoi configurare moduli Terraform che incorporano i requisiti di sicurezza dell'applicazione a cui è destinato il repository. Le applicazioni ad alta sicurezza richiedono un numero maggiore e diverso di approvatori dell'unione rispetto alle app con sicurezza inferiore.
  • Crea un modo per consentire agli amministratori di repository di scegliere da un insieme di modelli di configurazione del repository che favoriscono la nuova configurazione dei repository invece di configurare ogni repository da zero. Questi modelli dovrebbero rispecchiare i diversi livelli di sicurezza delle tue applicazioni ed essere sincronizzati con le identità degli utenti richieste per ogni livello di sicurezza. In pratica, questo di solito comporta l'utilizzo di un sistema di controllo di identità e accessi (IAM) gerarchico che rifletta le applicazioni e l'infrastruttura della tua organizzazione e gli utenti che ne sono responsabili.
  • Richiedi la gestione centralizzata delle identità con l'autenticazione a più fattori per gli utenti del repository.
    • La gestione centralizzata delle identità garantisce che quando gli utenti lasciano l'organizzazione o passano a nuovi team, tu mantenga privilegio minimo possibile per la gestione dell'origine.
    • L'autenticazione a più fattori riduce notevolmente il rischio di phishing e altri tipi di attacchi alla tua fonte. L'autenticazione a due fattori è uno dei requisiti di livello 4 dello standard SLSA per gli approvatori di codice.
  • Limita i proprietari dei repository a un numero limitato di dipendenti fidati. Ciò potrebbe richiedere l'integrazione del controllo della versione con un sistema di gestione delle identità e la possibilità di impostare criteri a un livello superiore nell'organizzazione. Se possibile, rimuovi la possibilità per i proprietari dei repository di eseguire unioni senza un secondo revisore.

Revisione del codice

La revisione del codice è il modo principale con cui le organizzazioni mantengono la qualità e la sicurezza del loro software. La revisione del codice tenta di risolvere diverse modalità di errore, ad esempio:

  • Introduzione di codice con difetti del software o un design poco flessibile.
  • API mal definite
  • Introduzione di problemi di sicurezza dovuti a codice non sicuro scritto dallo sviluppatore
  • Introduzione di problemi di sicurezza dovuti all'aggiunta di librerie di terze parti non sicure o che potrebbero diventare non sicure.

Ecco alcuni modi per ridurre i rischi:

  • Implementa l'automazione dei test durante tutto il ciclo di vita del software. I test automatici che si attivano quando esegui il commit dell'origine nel sistema di controllo della versione consentono agli sviluppatori di ricevere rapidamente feedback sui problemi rilevati dai test.
  • Assicurati che il numero e l'identità dei revisori siano appropriati al livello di sicurezza dell'applicazione. Ad esempio, un'app intranet con utilizzo ridotto presenta requisiti di sicurezza inferiori rispetto a un'applicazione business critical rivolta al pubblico.
  • Assegna i revisori in base alle competenze tecniche e al livello di attendibilità richiesto per la modifica del commit. Il revisore deve essere esperto del linguaggio esaminato, dei sistemi con cui il codice interagisce e dei rischi per la sicurezza in questa classe di applicazione. Il requisito di competenze tecniche ha molte dimensioni. Ad esempio:
    • Il codice è leggibile?
    • È sicuro?
    • Utilizza le librerie di terze parti appropriate?
    • È in atto un processo per proteggere le librerie di terze parti?
    • Il codice è componibile?
    • La progettazione dell'API segue le best practice?

  • Le recensioni non devono essere un passaggio burocratico, ma un dialogo continuo sulle best practice. Crea elenchi di controllo, guide di stile e standard di progettazione per ogni parte del tuo stack tecnologico, oltre a programmi formativi per i nuovi sviluppatori. Alcuni IDE come VS Code e IntelliJ forniscono linter che possono segnalare automaticamente errori di pubblicità programmatica o stilistica. I Linter aiutano gli sviluppatori a creare codice più coerente e permettono ai revisori di concentrarsi maggiormente sui problemi non facili da identificare con i controlli automatici.

    Developing Secure Software è un corso online gratuito creato dalla Open Source Security Foundation (OpenSSF). Descrive le pratiche di sviluppo del software fondamentali nel contesto della sicurezza della catena di fornitura del software.

  • Esegui revisioni del codice con richieste di pull dei rami di funzionalità non appena un singolo sviluppatore è pronto. Non aspettare che venga testata una nuova release per eseguire i controlli di sicurezza e la revisione del codice.

  • L'integrazione dell'analisi delle vulnerabilità, inclusa l'analisi delle librerie di terze parti, nelle richieste di pull e negli IDE, aiuta a identificare i problemi il prima possibile. L'API On-Demand Scanning in Google Cloud consente di eseguire la scansione locale dei container per rilevare eventuali vulnerabilità.

  • Integra test automatici di pre-unione in modo che gli sviluppatori possano identificare e correggere le modifiche che comprometteranno l'applicazione. Scopri di più sull'automazione dei test.

Unisci le approvazioni

Nelle pipeline CI/CD integrate in modo continuo, l'unione del codice in un ramo di produzione potrebbe comportare modifiche a valle, comprese creazione e implementazione automatizzate. Per questo motivo, la protezione degli utenti che possono eseguire l'unione è una parte fondamentale della protezione dei deployment del software. Alcune considerazioni includono:

  • Configura proprietari dei rami protetti sui tuoi rami di produzione. Il numero e l'identità degli utenti autorizzati all'unione devono essere adeguati ai requisiti di sicurezza dell'applicazione. Il livello SLSA 4 richiede due approvatori fortemente autenticati, ma il numero di approvatori deve essere adeguato ai contenuti del repository.
  • Controlla rigorosamente le identità dei proprietari dei repository poiché nella maggior parte dei sistemi di controllo delle versioni possono eseguire le unioni autonomamente.
  • Separa i processi di deployment e approvazione per le implementazioni multi-repository e multi-artefatto.

Strumenti per proteggere lo sviluppo

Software Delivery Shield è una soluzione end-to-end e completamente gestita per la sicurezza della catena di fornitura del software. Fornisce un insieme completo e modulare di funzionalità e strumenti per i servizi Google Cloud che sviluppatori, DevOps e team di sicurezza possono utilizzare per migliorare l'approccio alla sicurezza della catena di fornitura del software. I seguenti componenti di Software Delivery Shield contribuiscono a proteggere il codice sorgente del software:

  • Cloud Workstations (anteprima)

    Cloud Workstations fornisce ambienti di sviluppo completamente gestiti su Google Cloud. Consente agli amministratori IT e della sicurezza di eseguire facilmente il provisioning, la scalabilità, la gestione e la protezione dei propri ambienti di sviluppo e permette agli sviluppatori di accedere agli ambienti di sviluppo con configurazioni coerenti e strumenti personalizzabili.

    Cloud Workstations aiuta a spostare la sicurezza nel miglioramento della strategia di sicurezza degli ambienti di sviluppo delle applicazioni. Include funzionalità di sicurezza come i Controlli di servizio VPC, il traffico in entrata o in uscita privato, l'aggiornamento forzato delle immagini e i criteri di accesso di Identity and Access Management. Per ulteriori informazioni, consulta la documentazione di Cloud Workstations.

  • Protezione dell'source protect di Cloud Code (anteprima)

    Cloud Code fornisce supporto IDE per la creazione, il deployment e l'integrazione delle applicazioni con Google Cloud. Consente agli sviluppatori di creare e personalizzare una nuova applicazione da modelli di esempio ed eseguire l'applicazione completata. Source protect Cloud Code fornisce agli sviluppatori un feedback sulla sicurezza in tempo reale, come l'identificazione delle dipendenze vulnerabili e la generazione di report sulle licenze, mentre lavorano nei loro IDE. Fornisce un feedback rapido e utile che consente agli sviluppatori di apportare correzioni al proprio codice all'inizio del processo di sviluppo del software.

    Disponibilità della funzionalità: source protect Cloud Code non è disponibile per l'accesso pubblico. Per ottenere l'accesso a questa funzionalità, consulta la pagina della richiesta di accesso.

Passaggi successivi