Origine salvaguardia

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

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

Sebbene la maggior parte dei team utilizzi 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 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 di Supply chain Levels for Software Artifacts, un framework per salvaguardare la catena di fornitura del software. Il framework include requisiti su più livelli per aiutarti a implementare le modifiche in modo incrementale, inclusi i requisiti delle origini.

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

A livello SLSA 3, le piattaforme di origine e di build rispettano requisiti di sicurezza più stringenti, tra cui la cronologia delle origini verificate e i criteri di conservazione delle origini. Il livello 4 di SLSA aggiunge le revisioni da parte di due persone ai requisiti delle origini.

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

L'archiviazione del codice sorgente dell'applicazione nel controllo delle versioni è una pratica consolidata quando sono necessarie revisioni storiche e controlli. Tuttavia, esistono altri tipi di origini che beneficiano anche del controllo della versione, tra cui configurazione, criteri e dati. Sono inclusi i file che:

  • Incidono sulla disponibilità e sulla sicurezza dell'infrastruttura di calcolo
  • Richiedere la collaborazione per la finalizzazione
  • Richiedere una procedura di approvazione ripetibile
  • Richiedere una cronologia delle modifiche

Ecco alcuni esempi:

  • Infrastructure as Code: le organizzazioni che vogliono gestire la propria infrastruttura in modo scalabile e sicuro utilizzano l'Infrastructure as Code come metodologia chiave. Ad esempio, puoi archiviare i moduli Terraform nel controllo della versione che crea 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. Archivi e gestisci i file di configurazione dell'applicazione nel tuo sistema di controllo delle versioni.
  • Configurazioni e script di migrazione del database: archivia la configurazione e gli script sia per i database di prodotto sia per i database di analisi o di logging.
  • Blocchi note Jupyter: esistono diversi modi per lavorare con i blocchi note memorizzati su GitHub, tra cui l'estensione per JupyterLab, Colaboratory e Vertex AI Workbench
  • Criteri di sicurezza: memorizza i file di criteri per l'applicazione automatica dei criteri. Ad esempio, puoi archiviare criteri Gatekeeper che consentono o negano il comportamento di implementazione in GKE o criteri Sentinel che impediscono a Terraform di eseguire il provisioning di un'infrastruttura in violazione dei criteri.

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

Configurazione del repository

I repository sono l'unità logica di base per organizzare il codice e i relativi ruoli, autorizzazioni, integrazioni e approvazioni.

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

  • La configurazione del repository non è standardizzata, pertanto diventa difficile garantire che la sicurezza del repository sia appropriata all'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, inclusa la possibilità di eseguire unioni senza altri revisori.
  • L'integrazione dei repository con l'analisi del codice, i server di compilazione, i tracker dei problemi, i servizi di notifica e altre parti dell'infrastruttura CI/CD può richiedere un lavoro considerevole. Avere 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 un processo automatico, ripetibile e attento alla sicurezza. Ad esempio, puoi configurare moduli Terraform che incorporino i requisiti di sicurezza dell'applicazione a cui è destinato il repository. Le applicazioni ad alta sicurezza richiedono più e diversi approvatori dell'unione rispetto alle app con una sicurezza inferiore.
  • Crea un modo per consentire agli amministratori dei repository di scegliere tra un insieme di modelli di configurazione dei repository che guidano la configurazione dei 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 significa utilizzare un sistema di gestione delle identità e controllo dell'accesso (IAM) gerarchico che rispecchi 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 delle identità centralizzata garantisce che, quando gli utenti lasciano l'organizzazione o passano a nuovi team, tu mantenga il privilegio minimo per la gestione delle origini.
    • L'autenticazione a più fattori riduce notevolmente il rischio di phishing e altri tipi di attacchi alla tua origine. L'autenticazione a due fattori è uno dei requisiti di SLSA di livello 4 per gli approvatori del codice.
  • Limita i proprietari del repository a un numero ristretto di dipendenti fidati. Potrebbe essere necessario integrare il controllo della versione con un sistema di gestione delle identità e spostare la possibilità di impostare i criteri più in alto nell'organizzazione. Se possibile, rimuovi la possibilità per i proprietari del 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 vari modi di errore, come:

  • Introduzione di codice con difetti software o un design inflessibile.
  • API poco definite
  • Introduzione di problemi di sicurezza dovuti a codice non sicuro scritto dall' sviluppatore
  • Introduzione di problemi di sicurezza dovuti all'aggiunta di librerie di terze parti non sicure o che potrebbero diventarlo.

Ecco alcuni modi per mitigare il rischio:

  • Implementa l'automazione dei test durante tutto il ciclo di vita del software. I test automatici che si attivano 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 al livello di sicurezza dell'applicazione. Ad esempio, un'app intranet con un utilizzo ridotto avrà requisiti di sicurezza inferiori a quelli di un'applicazione aziendale critica 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 della lingua in esame, dei sistemi con cui interagisce il codice e dei rischi per la sicurezza in questa classe di applicazioni. Il requisito di competenza tecnica ha molte dimensioni. Ad esempio:
    • Il codice è leggibile?
    • È sicuro?
    • Utilizza librerie di terze parti appropriate?
    • È stata implementata una procedura per la protezione delle librerie di terze parti?
    • Il codice è componibile?
    • Il design dell'API segue le best practice?

  • Le revisioni non devono essere un passaggio burocratico, ma un dialogo continuo sulle best practice. Crea checklist, guide di stile e standard di design per ogni parte del tuo stack tecnologico, oltre a programmi didattici per i nuovi sviluppatori. Alcuni IDE come VS Code e IntelliJ forniscono lint che possono segnalare automaticamente errori programmatici o stilistici. I linters 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.

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

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

  • L'integrazione analisi delle vulnerabilità, inclusa la ricerca di librerie di terze parti, nelle richieste pull e nelle IDE consente di identificare i problemi il prima possibile. L'API On-Demand Scanning in Google Cloud ti consente di eseguire la scansione dei 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 potrebbero interrompere l'applicazione. Scopri di più sull'automazione dei test.

Unire le approvazioni

Nelle pipeline CI/CD integrate continuamente, l'unione del codice in un ramo di produzione può comportare modifiche a valle, tra cui la compilazione e l'implementazione automatiche. Per questo motivo, definire chi può eseguire l'unione è un aspetto fondamentale per garantire la sicurezza dei deployment del software. Le considerazioni includono:

  • Configura i proprietari dei rami protetti nei rami di produzione. Il numero e l'identità di chi è autorizzato a eseguire l'unione devono essere appropriati ai requisiti di sicurezza dell'applicazione. Il livello 4 di SLSA richiede due approvatori con autenticazione forte, ma il numero di approvatori deve essere appropriato ai contenuti del repository.
  • Controlla rigidamente le identità dei proprietari del repository, poiché nella maggior parte dei sistemi di controllo della versione possono eseguire le unioni autonomamente.
  • Separa le procedure di approvazione del deployment e dell'unione per le implementazioni con più repository e più elementi.

Strumenti per la sicurezza dello sviluppo

Google Cloud fornisce un insieme di funzionalità e strumenti modulari che puoi utilizzare per migliorare la security posture della tua supply chain del software. I seguenti componenti 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 consente agli sviluppatori di accedere a questi ambienti con configurazioni coerenti e strumenti personalizzabili.

    Cloud Workstations ti aiuta a spostare la sicurezza a sinistra migliorando la strategia di sicurezza dei tuoi ambienti di sviluppo delle applicazioni. Dispone di 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 saperne di più, consulta la documentazione di Cloud Workstations.

  • Protezione dell'source protect Cloud Code (anteprima)

    Cloud Code fornisce il supporto IDE per creare, eseguire il deployment e integrare 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 di Cloud Code 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 nelle loro IDE. Fornisce un feedback rapido e utile che consente agli sviluppatori di apportare correzioni al loro codice all'inizio del processo di sviluppo software.

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

Passaggi successivi