Origine della misura di sicurezza

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

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

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

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

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

A SLSA livello 3, le piattaforme di origine e di build rispettano requisiti di sicurezza più rigorosi, tra cui la cronologia dell'origine verificata e le norme di conservazione dell'origine. SLSA livello 4 aggiunge le revisioni da parte di due persone ai requisiti di origine.

Utilizzare il controllo della versione per più del codice sorgente dell'applicazione

L'archiviazione del codice sorgente dell'applicazione nel controllo della versione è una pratica consolidata quando sono necessarie revisioni storiche e audit. Tuttavia, esistono altri tipi di origine che traggono vantaggio dal controllo della versione, tra cui configurazione, norme e dati. Sono inclusi tutti i file che:

  • Influenzano la disponibilità e la sicurezza dell'infrastruttura di computing
  • Richiedono la collaborazione per la finalizzazione
  • Richiedono una procedura di approvazione ripetibile
  • Richiedono 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 i moduli Terraform nel controllo della versione che creano repository Artifact Registry.
  • Gestione della configurazione: la gestione della configurazione è simile a Infrastructure as Code, ma si concentra sulla gestione della configurazione delle applicazioni con strumenti come Ansible, Puppet e Chef. Archivi e gestisci i file di configurazione dell'applicazione nel sistema di controllo della versione.
  • Configurazioni del database e script di migrazione: archivia la configurazione e gli script per i database dei prodotti e per i database di analisi o logging
  • Blocchi note Jupyter: esistono diversi modi per lavorare con i blocchi note archiviati in GitHub, inclusa l'estensione per JupyterLab, Colaboratory e Vertex AI Workbench
  • Norme di sicurezza: archivia i file delle norme per l'applicazione automatica delle norme. Ad esempio, puoi archiviare le norme di Gatekeeper che consentono o negano il comportamento di deployment in GKE o le norme di Sentinel che impediscono a Terraform di eseguire il provisioning dell'infrastruttura in violazione delle norme.

Il controllo della versione è una delle funzionalità tecniche identificate dalla ricerca DORA DevOps che potenzia la distribuzione del software e le prestazioni dell'organizzazione. L'archiviazione di script, codice sorgente e file di configurazione nel controllo della versione consente di riprodurre e recuperare gli ambienti, monitorare e controllare le modifiche e rispondere rapidamente ai difetti.

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.

I problemi che possono verificarsi con la configurazione del repository includono:

  • La configurazione del repository non è standardizzata, quindi 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.
  • Chi crea il repository diventa proprietario con autorizzazioni amministrative complete, inclusa la possibilità di eseguire unioni senza altri revisori.
  • L'integrazione dei repository con l'analisi del codice, i server di build, i tracker dei problemi, i servizi di notifica e altre parti dell'infrastruttura CI/CD può richiedere un lavoro considerevole. Disporre di un modo standard per creare e configurare i repository consente di risparmiare lavoro ripetitivo e supporta le best practice.

Per risolvere questi problemi, le best practice includono

  • Configura i repository con una procedura automatica, ripetibile e attenta alla sicurezza. Ad esempio, puoi configurare i moduli Terraform che incorporano i requisiti di sicurezza dell'applicazione per cui è destinato il repository. Le applicazioni ad alta sicurezza richiedono approvatori di unione più numerosi e diversi rispetto alle app a bassa sicurezza.
  • Crea un modo per consentire agli amministratori dei repository di selezionare un insieme di modelli di configurazione dei repository che guidano la configurazione di nuovi repository anziché configurare ogni repository da zero. Questi modelli devono riflettere i diversi livelli di sicurezza delle applicazioni ed essere sincronizzati con le identità utente richieste per ogni livello di sicurezza. In pratica, in genere si utilizza un sistema di controllo dell'accesso e dell'identità (IAM) gerarchico che riflette le applicazioni e l'infrastruttura dell'organizzazione e gli utenti 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, venga mantenuto il privilegio minimo per la gestione del codice sorgente.
    • L'autenticazione a più fattori riduce significativamente il rischio di phishing e altri tipi di attacchi al codice sorgente. L'autenticazione a due fattori è uno dei requisiti di SLSA livello 4 per gli approvatori del codice.
  • Limita i proprietari dei repository a un piccolo numero di dipendenti fidati. Ciò potrebbe richiedere l'integrazione del controllo della versione con un sistema di gestione delle identità e lo spostamento della possibilità di impostare le norme a un livello superiore dell'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 in cui le organizzazioni mantengono la qualità e la sicurezza del proprio software. La revisione del codice tenta di risolvere varie modalità di errore, ad esempio:

  • Introduzione di codice con difetti software o una progettazione inflessibile.
  • API mal definite
  • Introduzione di problemi di sicurezza a causa di 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 mitigare il rischio:

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

  • Le revisioni non devono essere un passaggio burocratico, ma una conversazione continua sulle best practice. Crea checklist, guide di stile e standard di progettazione per ogni parte dello stack tecnologico, insieme a programmi di formazione per i nuovi sviluppatori. Alcuni IDE, come VS Code e IntelliJ, forniscono linter che possono contrassegnare automaticamente gli errori programmatici o stilistici. I linter aiutano gli sviluppatori a creare codice più coerente e consentono ai revisori del codice di concentrarsi maggiormente sui problemi che non sono facili da identificare con i controlli automatici.

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

  • Esegui le revisioni del codice con le richieste di pull dei rami delle funzionalità non appena un singolo sviluppatore è pronto. Non attendere fino a poco prima che una nuova release venga inserita nel test per eseguire controlli di sicurezza e revisione del codice.

  • L'integrazione dell'analisi delle vulnerabilità, inclusa l'analisi delle librerie di terze parti, nelle richieste di pull e negli IDE consente di identificare i problemi il prima possibile. L'API On-Demand Scanning ti con Google Cloud sente di analizzare i container a livello locale per rilevare eventuali vulnerabilità.

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

Approvazioni di unione

Nelle pipeline CI/CD integrate in modo continuo, l'unione del codice in un ramo di produzione può comportare modifiche downstream, tra cui la build e l'implementazione automatiche. Per questo motivo, proteggere chi può eseguire l'unione è una parte fondamentale della protezione dei deployment software. Ecco alcune considerazioni:

  • Configura i proprietari dei rami protetti nei rami di produzione. Il numero e l'identità delle persone autorizzate a eseguire l'unione devono essere appropriati per i requisiti di sicurezza dell'applicazione. SLSA livello 4 richiede due approvatori con autenticazione avanzata, ma il numero di approvatori deve essere appropriato per i contenuti del repository.
  • Controlla attentamente le identità dei proprietari dei repository, poiché nella maggior parte dei sistemi di controllo della versione possono eseguire le unioni da soli.
  • Separa i processi di deployment e di approvazione dell'unione per le implementazioni di più repository e più artefatti.

Strumenti per proteggere lo sviluppo

Google Cloud fornisce un insieme di funzionalità e strumenti modulari che puoi utilizzare per migliorare il security posture della catena di fornitura del software. I seguenti componenti aiutano 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, scalare, gestire e proteggere gli ambienti di sviluppo e consente agli sviluppatori di accedere agli ambienti di sviluppo con configurazioni coerenti e strumenti personalizzabili.

    Cloud Workstations aiuta a spostare la sicurezza a sinistra migliorando la security posture degli ambienti di sviluppo delle applicazioni. Dispone di funzionalità di sicurezza come Controlli di servizio VPC, traffico in entrata o in uscita privato, aggiornamento forzato delle immagini e policy di accesso Identity and Access Management. Per saperne di più, consulta la documentazione di Cloud Workstations.

  • Cloud Code Source Protect (anteprima)

    Cloud Code fornisce il supporto IDE per creare, eseguire il deployment e integrare le applicazioni con Google Cloud. Consente agli sviluppatori di creare e personalizzare una nuova applicazione da modelli di esempio ed eseguire l'applicazione completata. Cloud Code Source Protect fornisce agli sviluppatori feedback sulla sicurezza in tempo reale, ad esempio l'identificazione delle dipendenze vulnerabili e la generazione di report sulle licenze, mentre lavorano nei loro IDE. Fornisce feedback rapidi e pratici che consentono agli sviluppatori di apportare correzioni al codice all'inizio del processo di sviluppo software.

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

Passaggi successivi