Origine salvaguardia

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

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

Sebbene la maggior parte dei team oggi 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 esplora le considerazioni sulla sicurezza della catena di fornitura del software per configurare 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 modifiche immutabili è un requisito SLSA di livello 2. Consigliamo l'allineamento con il livello 2 di SLSA come livello di base di partenza per la catena di fornitura del software.

Al livello 3 di SLSA, le piattaforme di origine e build rispettano i requisiti di sicurezza più rigorosi, tra cui la cronologia dell'origine verificata e i criteri di conservazione delle origini. Il livello 4 di SLSA aggiunge recensioni a due persone ai requisiti della fonte.

Usa il controllo della versione per più origini dell'applicazione

L'archiviazione dell'origine dell'applicazione nel controllo della versione è una prassi ben consolidata quando sono necessarie revisioni storiche e audit. Tuttavia, esistono anche altri tipi di origini che usufruiscono del controllo della versione, tra cui configurazione, criteri e dati. Sono inclusi i file che:

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

Ecco alcuni esempi:

  • Infrastruttura as a 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 nel modulo i moduli Terraform che creano repository Artifact Registry.
  • Gestione della configurazione: è simile a Infrastructure as a Code, ma si concentra sulla gestione della configurazione delle applicazioni con strumenti come Ansible, Puppet e Chef. Archivia e gestisci i file di configurazione dell'applicazione nel tuo sistema di controllo della versione.
  • Configurazioni di database e script di migrazione: archivia la configurazione e gli script per i database di prodotto e per l'analisi o il logging.
  • Notebook Jupyter: sono disponibili diversi modi per lavorare con i blocchi note archiviati in GitHub, tra cui [estensione per 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 criteri di Keepkeeper che consentono o negano il comportamento di deployment in GKE o criteri di sentiment che impediscono a Terraform di eseguire il provisioning di un'infrastruttura che viola i criteri.

Il controllo della versione è una delle funzionalità tecniche identificate dalla ricerca DevOps DORA che determina prestazioni di distribuzione e organizzazione superiori del software. 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 rispondere rapidamente ai difetti.

Configurazione del repository

I repository sono l'unità logica fondamentale per l'organizzazione del codice e dei ruoli, delle autorizzazioni, delle integrazioni e delle approvazioni correlati.

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

  • La configurazione del repository non è standardizzata, quindi diventa difficile assicurare che la sicurezza dei 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, inclusa la possibilità di eseguire unioni con nessun altro revisore.
  • L'integrazione di repository con l'analisi del codice, la creazione di server, il monitoraggio dei problemi, i servizi di notifica e altre parti dell'infrastruttura CI/CD può essere un lavoro considerevole. La disponibilità di un metodo standard di creazione e configurazione dei repository permette 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 sicuro per la sicurezza. Ad esempio, puoi configurare moduli Terraform che incorporano i requisiti di sicurezza dell'applicazione a cui è destinato il repository. Le applicazioni di sicurezza elevata richiedono un numero maggiore e diverso di approvatori di unione rispetto alle app di sicurezza inferiore.
  • Crea un modo per gli amministratori di repository per scegliere da un set di modelli di configurazione di repository che generano una nuova configurazione di repository anziché configurare ogni repository da zero. Questi modelli devono riflettere i diversi livelli di sicurezza delle tue applicazioni e venire sincronizzati con le identità utente richieste per ogni livello di sicurezza. In pratica, ciò significa utilizzare un sistema IAM (controllo di identità e accessi) che rifletta le applicazioni e l'infrastruttura dell'organizzazione e gli utenti responsabili di questi ultimi.
  • Richiedi una gestione centralizzata dell'identità con autenticazione a più fattori per gli utenti dei repository.
    • La gestione centralizzata delle identità garantisce che, quando gli utenti lasciano l'organizzazione o passano a nuovi team, mantenga il privilegio minimo per la gestione delle origini.
    • L'autenticazione a più fattori riduce in modo significativo il rischio di phishing e altri tipi di attacchi alla tua fonte. L'autenticazione a due fattori è uno dei requisiti di livello 4 di SLSA per gli approvatori di codice.
  • Limita i proprietari del 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 più elevati nell'organizzazione. Se possibile, rimuovi la possibilità per i proprietari di repository di eseguire unioni senza un secondo visualizzatore.

Revisione del codice

La revisione del codice è il modo principale in cui le organizzazioni mantengono la qualità e la sicurezza del loro software. La revisione del codice cerca di gestire varie modalità di errore, tra cui:

  • Introduzione del codice con difetti software o design flessibile.
  • API poco 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.

Alcuni modi per mitigare i rischi includono:

  • Implementa i test continui durante tutto il ciclo di vita del software. I test automatici che si attivano quando confermi il commit dell'origine nel sistema di controllo della versione consentono agli sviluppatori di ricevere rapidamente un 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 utilizzo ridotto avrà requisiti di sicurezza inferiori rispetto a un'applicazione critica per l'azienda.
  • Assegna revisori in base alle competenze tecniche e al livello di fiducia richiesto per la modifica dell'impegno. Il revisore dovrebbe essere un esperto nella lingua esaminata, nei sistemi con cui interagisce il codice e nei rischi per la sicurezza di questa classe di applicazioni. Il requisito di competenza tecnica presenta molte dimensioni. Ad esempio:
    • Il codice è leggibile?
    • È sicuro?
    • Utilizza librerie di terze parti appropriate?
    • Esiste un processo di protezione delle librerie di terze parti?
    • Il codice è componibile?
    • La progettazione dell'API segue le best practice?
  • Le recensioni non devono essere un passo burocratico, ma un dialogo continuo sulle best practice. Crea elenchi di controllo, guide di stile e standard di progettazione in ogni parte del tuo stack tecnologico, insieme a programmi didattici per i nuovi sviluppatori. Alcuni IDE, come VS Code e IntelliJ, forniscono log che possono segnalare automaticamente errori di pubblicità programmatica o stilistica. I team di sviluppatori aiutano gli sviluppatori a creare codice più coerente e consentono ai revisori di concentrarsi maggiormente sui problemi che non sono facili da identificare con i controlli automatici.

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

  • Esegui revisioni del codice con richieste di pull di ramo di funzionalità non appena un singolo sviluppatore è pronto. Non aspettare che una nuova release venga testata 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 aiuta a identificare i problemi appena possibile. L'API On-Demand Scanning in Google Cloud ti consente di eseguire la scansione locale dei container per rilevare le vulnerabilità.

  • Integra test automatizzati precedenti all'unione in modo che gli sviluppatori possano identificare e correggere le modifiche che causeranno problemi nell'applicazione. Scopri di più sui test continui.

Unisci approvazioni

Nelle pipeline CI/CD integrate continuamente, l'unione del codice in un ramo di produzione può comportare modifiche a valle, tra cui build e implementazione automatizzate. Per questo motivo, proteggere chi può unire è una parte fondamentale della sicurezza dei deployment del software. Le considerazioni includono:

  • Configura i proprietari di rami protetti nei tuoi rami di produzione. Il numero e l'identità di coloro che sono autorizzati a unire devono essere appropriati ai requisiti di sicurezza dell'applicazione. Il livello 4 di SLSA richiede due approvatori fortemente autenticati, ma il numero di approvatori deve essere appropriato per i contenuti del repository.
  • Controlla attentamente le identità dei proprietari dei repository perché nella maggior parte dei sistemi di controllo della versione, le operazioni di unione possono essere eseguite autonomamente.
  • Separa i processi di approvazione e deployment per le implementazioni con più repository e più artefatti.

Strumenti per proteggere lo sviluppo

Software Delivery Shield è una soluzione di sicurezza end-to-end completamente gestita per la catena di fornitura del software. Fornisce un insieme completo e modulare di funzionalità e strumenti nei servizi Google Cloud che sviluppatori, DevOps e team di sicurezza possono utilizzare per migliorare la strategia di sicurezza della catena di fornitura del software. I seguenti componenti di Software Delivery Shield 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 di sicurezza di eseguire il provisioning, scalare, gestire e proteggere facilmente i propri ambienti di sviluppo e consente agli sviluppatori di accedere agli ambienti di sviluppo con configurazioni coerenti e strumenti personalizzabili.

    Cloud Workstations aiuta a trasferire la sicurezza migliorando la strategia di sicurezza degli ambienti di sviluppo delle applicazioni. Presenta funzionalità di sicurezza come Controlli di servizio VPC, traffico in entrata o in uscita privato, aggiornamento forzato delle immagini e criteri di accesso a Identity and Access Management. Per ulteriori informazioni, consulta la documentazione di Cloud Workstations.

  • Protezione della sorgente di Cloud Code (anteprima)

    Cloud Code fornisce il supporto dell'IDE per creare, sottoporre a 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. La protezione dell'origine di Cloud Code offre agli sviluppatori feedback in tempo reale per la sicurezza, come l'identificazione di dipendenze vulnerabili e la generazione di report sulle licenze, mentre lavorano negli IDE. Fornisce un feedback rapido e utile che consente agli sviluppatori di apportare modifiche al codice all'inizio del processo di sviluppo del software.

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

Passaggi successivi