Salvaguarda le build

Questo documento descrive le best practice per proteggere le build. Il termine "codice edificio" può riferirsi a diversi tipi di operazioni, ad esempio:

  • Ottimizzazione o offuscamento del codice: ad esempio, lo strumento open source di Google Closure Compiler analizza e analizza JavaScript, rimuove il codice non più valido, riscrive e riduce al minimo i dati rimasti. Verifica inoltre che il codice non presenti errori comuni relativi a JavaScript.
  • Compilazione del codice in codice intermedio: ad esempio, puoi compilare codice Java in un file di classe Java (.class) o codice C++ in un file oggetto (.obj).
  • Compilazione di codice e collegamento, creazione di una libreria o di un file eseguibile: ad esempio, compilazione di codice C++ in una libreria condivisa (.so) o in un file eseguibile di Windows (.exe).
  • Pacchettizzazione del codice in un formato distribuibile o di cui è possibile eseguire il deployment: gli esempi includono la creazione di file Java WAR (.war) da file di classe Java, la creazione di un'immagine Docker o la creazione di una distribuzione creata in Python (.whl).

A seconda del linguaggio di programmazione utilizzato e dell'ambiente in cui esegui il deployment, la build potrebbe contenere diverse combinazioni di queste operazioni. Ad esempio, una build potrebbe pacchettizzare il codice Python in una distribuzione creata e caricarlo in un archivio di artefatti come Artifact Registry o PyPI in modo da poterlo utilizzare come dipendenza in Cloud Functions. Puoi anche containerizzare il codice Python ed eseguire il deployment dell'immagine container su Cloud Run o Google Kubernetes Engine.

Le procedure descritte in questo documento si concentrano sulla creazione di codice per la pacchettizzazione o il deployment in ambienti di runtime anziché sulla compilazione del codice.

Utilizza build automatizzate

Una compilazione automatica o una compilazione con script definisce tutti i passaggi nello script di build o nella configurazione della build, compresi i passaggi per recuperare il codice sorgente e quelli per creare il codice. L'unico comando manuale, se presente, è quello per eseguire la build.

Ad esempio, uno script di build può essere:

  • Un cloudbuild.yaml di Cloud Build.
  • Un makefile che puoi eseguire con lo strumento make.
  • Un file di flusso di lavoro delle azioni GitHub in formato YAML archiviato nella tua directory .github/workflows/.

Le build automatizzate offrono coerenza nei passaggi della build. Tuttavia, è anche importante eseguire le build in un ambiente coerente e attendibile.

Sebbene le build locali possano essere utili a scopo di debug, il rilascio di software da build locali può introdurre molti problemi di sicurezza, incongruenze ed infficienze nel processo di compilazione.

  • Consentire le build locali consente a un utente malintenzionato con intento dannoso di modificare il processo di compilazione.
  • Le incoerenze negli ambienti locali e nelle pratiche degli sviluppatori rendono difficile riprodurre le build e diagnosticare i relativi problemi.

Le build manuali rendono il processo inefficiente sfruttando più risorse dell'infrastruttura come computing, archiviazione e reti. Nei requisiti per il framework SLSA, le build automatizzate sono un requisito per SLSA di livello 1 e l'utilizzo di un servizio di build anziché di ambienti di sviluppo per le build è un requisito per il livello 2 di SLSA.

Cloud Build è il servizio di compilazione gestito su Google Cloud. Utilizza un file di configurazione della build per fornire i passaggi per le build in Cloud Build. Puoi configurare le build per recuperare dipendenze, eseguire test delle unità, analisi statiche e test di integrazione, nonché creare artefatti con strumenti di creazione come Docker, Gradle, Maven, Go e Python. Cloud Build è completamente integrato con altri servizi CI/CD su Google Cloud come Artifact Registry e Cloud Deploy, nonché con ambienti di runtime come GKE e Cloud Run. Inoltre, fornisce l'integrazione con i principali sistemi di gestione del codice sorgente, come GitHub e Bitbucket.

Genera provenienza della build

La provenienza della build è una raccolta di dati verificabili relativi a una build.

I metadati di provenienza includono dettagli come i digest delle immagini create, le località delle origini di input, la Toolchain di build e la durata della build.

La generazione della provenienza della build ti aiuta a:

  • Verifica che un artefatto creato sia stato creato da una località di origine attendibile e da un sistema di compilazione attendibile.
  • Identifica il codice inserito da una posizione di origine o da sistema di compilazione non attendibili.

Puoi utilizzare i meccanismi di avviso e dei criteri per utilizzare in modo proattivo i dati sulla provenienza della build. Ad esempio, puoi creare criteri che consentono solo il deployment di codice creato da origini verificate.

Per il livello 1 di SLSA, la provenienza della build deve essere disponibile per i consumatori degli artefatti creati. Per il livello 2 di SLSA, anche i dati sulla provenienza della build devono essere:

  • Generati dal servizio di build o leggibili direttamente dal servizio di build.
  • Verificabile da un consumatore per verificarne l'autenticità e l'integrità. A questo scopo, utilizza una firma digitale generata dal servizio che crea i dati di provenienza della build.

Per il livello 3 di SLSA, i contenuti relativi alla provenienza devono includere anche:

  • Il punto di ingresso della definizione della build.
  • Tutti i parametri della build sono sotto il controllo dell'utente.

Cloud Build può generare la provenienza della build per le immagini container che forniscono una garanzia di build SLSA di livello 3. Per maggiori informazioni, consulta la pagina Visualizzare la provenienza delle build.

Utilizza un ambiente di build temporaneo

Gli ambienti temporanei sono ambienti temporanei pensati per durare per una singola chiamata a build. Dopo la build, l'ambiente viene cancellato o eliminato. Le build temporanee assicurano che il servizio e i passi di build vengano eseguiti in un ambiente temporaneo, ad esempio un container o una VM. Anziché riutilizzare un ambiente di build esistente, il servizio di build esegue il provisioning di un nuovo ambiente per ogni build e poi lo elimina al termine del processo di compilazione.

Gli ambienti temporanei assicurano build chiare perché non esistono file residui o impostazioni di ambiente di build precedenti che possono interferire con il processo di build. Un ambiente non temporaneo offre ai malintenzionati l'opportunità di inserire file e contenuti dannosi. Un ambiente temporaneo riduce anche l'overhead di manutenzione e le incoerenze nell'ambiente di build.

Cloud Build configura un nuovo ambiente di macchine virtuali per ogni build e lo distrugge dopo la build.

Limita l'accesso al servizio di compilazione

Segui il principio di sicurezza del privilegio minimo concedendo le autorizzazioni minime richieste al servizio di build e alle risorse della build. Devi inoltre utilizzare un'identità non umana per eseguire le build e interagire con altri servizi per conto della build.

Se utilizzi Cloud Build:

  • Concedi le autorizzazioni minime richieste ai membri della tua organizzazione.
  • Personalizza le autorizzazioni per l'account di servizio che agisce per conto di Cloud Build in modo che disponga solo delle autorizzazioni necessarie per il tuo utilizzo. Modifica le autorizzazioni dell'account di servizio Cloud Build predefinito oppure valuta la possibilità di utilizzare un account di servizio personalizzato.
  • Utilizza il criterio dell'organizzazione Integrazioni consentite di Cloud Build per controllare i servizi esterni autorizzati a richiamare i trigger di build.

  • Posiziona Cloud Build in un perimetro di servizio utilizzando Controlli di servizio VPC. Il perimetro consente la libera comunicazione tra i servizi Google Cloud all'interno del perimetro, ma limita la comunicazione lungo il perimetro in base a regole da te specificate. Inoltre, il perimetro riduce il rischio di esfiltrazione di dati.

    Cloud Build supporta i Controlli di servizio VPC solo per le build eseguite in un pool privato.

Proteggere le credenziali

Le build spesso includono connessioni ad altri sistemi come il controllo della versione, gli archivi di artefatti e gli ambienti di deployment. La protezione delle credenziali che utilizzi nelle build aiuta a impedire l'accesso non autorizzato ai sistemi nella catena di fornitura del software e l'esfiltrazione di dati.

Evita di archiviare le credenziali hardcoded direttamente nel controllo della versione o nella configurazione della build. Archivia invece le credenziali in un archivio chiavi sicuro.

In Google Cloud, Secret Manager archivia in modo sicuro chiavi API, password e altri dati sensibili. Puoi configurare Cloud Build in modo che utilizzi i secret archiviati in Secret Manager.

Gestisci le tue dipendenze

L'integrità delle tue applicazioni si basa sull'integrità del codice che sviluppi e delle eventuali dipendenze utilizzate. Devi inoltre considerare dove pubblichi le dipendenze, chi può accedere in lettura e scrittura ai repository di artifact e i criteri per origini attendibili degli artefatti della build di cui esegui il deployment nei tuoi ambienti di runtime.

Per scoprire di più sulla gestione delle dipendenze, consulta Gestire le dipendenze.

In Cloud Build, utilizzi cloud builder per eseguire i comandi. I builder sono immagini container in cui sono installati strumenti e linguaggi comuni. Puoi utilizzare immagini container pubbliche di registri pubblici come Docker Hub, builder forniti da Cloud Build, builder offerti dalla community e builder personalizzati creati da te. Puoi anche utilizzare i buildpack come builder, inclusi i buildpack di Google Cloud.

Esamina i builder che utilizzi nelle build di Cloud Build, scopri chi li fornisce e decidi se ti fidi della tua catena di fornitura del software. Per mantenere un maggiore controllo sul codice in un builder, puoi creare builder personalizzati anziché utilizzare builder da un'origine pubblica.

Ridurre le opportunità di modificare la build

Esistono molti altri fattori che possono influenzare una build, tra cui:

  • Build eseguite contemporaneamente e in grado di influenzarsi a vicenda oppure una build che persiste e influisce su una build successiva.
  • Build che accettano parametri utente diversi dal punto di ingresso della build e dalla posizione di origine di primo livello.
  • Build che specificano le dipendenze con intervalli o dipendenze modificabili (ad esempio, utilizzando un'immagine con il tag latest). Questi approcci costituiscono un rischio che le build utilizzino versioni errate o indesiderate delle dipendenze.

Le pratiche seguenti aiutano a mitigare questi rischi:

  • Esegui ogni build in un ambiente temporaneo.
  • Evita di eseguire build con parametri aggiuntivi in modo che gli utenti non possano influenzare le variabili definite negli script di build.
  • Limita l'accesso al servizio di build e alle risorse della build.
  • Fai riferimento a versioni immutabili delle dipendenze invece di identificatori, ad esempio tag che possono puntare a una versione diversa dell'artefatto in futuro. Per ulteriori informazioni sulle dipendenze, consulta Gestione delle dipendenze.

Segui le best practice per la creazione dei container

Consulta le best practice per la creazione dei container per scoprire di più sui modi per creare immagini container più affidabili e meno vulnerabili agli attacchi, tra cui:

  • Pacchettizzazione di applicazioni singole
  • Processi di gestione
  • Ottimizzazione della cache di build Docker
  • Rimuovendo gli strumenti non necessari e riducendo il più possibile le dimensioni delle immagini
  • Analisi delle vulnerabilità con Artifact Analysis. Puoi analizzare le immagini archiviate in Artifact Registry o localmente prima di archiviarle.
  • Best practice per la codifica
  • Considerazioni sulla sicurezza per l'utilizzo delle immagini pubbliche

Software Delivery Shield

Software Delivery Shield è una soluzione end-to-end per la sicurezza della catena di fornitura del software completamente gestita. 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 la strategia di sicurezza della catena di fornitura del software. Visualizza insight sulla sicurezza per le applicazioni create nell'interfaccia utente di Cloud Build nella console Google Cloud. Ciò include:

  • Il livello SLSA, che identifica il livello di maturità della sicurezza della catena di fornitura del software.
  • Vulnerabilità, istruzioni SBOM (Bill of Materials del software) e Vulnerability Exploitability eXchange (VEX) per gli artefatti della build.
  • Provenienza della build, ovvero una raccolta di metadati verificabili relativi a una build. Include dettagli come le sintesi delle immagini create, le posizioni delle origini di input, la Toolchain di build, i passi di build e la durata della build.

Per istruzioni sulla visualizzazione degli insight sulla sicurezza per le applicazioni create, consulta Creare un'applicazione e visualizzare gli insight sulla sicurezza.

Passaggi successivi