Proteggere le build

Questo documento descrive le best practice per proteggere le tue build. Il codice edificio può fare riferimento 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 inutilizzato e riscrivi e riduci al minimo ciò che rimane. Inoltre, controlla la presenza di errori comuni di JavaScript nel codice.
  • Compilazione del codice in codice intermedio: ad esempio, puoi compilare il codice Java in un file di classe Java (.class) o il codice C++ in un file oggetto (.obj).
  • Compilazione del codice e collegamento, creazione di una libreria o di un file eseguibile: ad esempio, compilation del codice C++ in una libreria condivisa (.so) o in un file eseguibile Windows (.exe).
  • Imballaggio del codice in un formato distribuibile o di cui è possibile eseguire il deployment: ad esempio, la creazione di file WAR (.war) Java da file di classi Java, la creazione di un'immagine Docker o la creazione di una distribuzione compilata in Python (.whl).

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

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

Utilizzare le build automatiche

Una build automatica o build basata su script definisce tutti i passaggi di compilazione nello script di compilazione o nella configurazione di compilazione, inclusi i passaggi per recuperare il codice sorgente e quelli per compilare il codice. L'unico comando manuale, se presente, è il comando per eseguire creare.

Ad esempio, uno script di build può essere:

  • Un'cloudbuild.yaml di Cloud Build.
  • Un Makefile che esegui con lo strumento make.
  • un file del flusso di lavoro delle azioni GitHub in formato YAML Directory .github/workflows/.

Le build automatiche forniscono coerenza nei passaggi della build. Tuttavia, è importante eseguire le build in un ambiente coerente e affidabile.

Sebbene le build locali possano essere utili per il debug, il rilascio del software dalle build locali può introdurre molti problemi di sicurezza, incoerenze inefficienze nel processo di compilazione.

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

Le build manuali rendono il processo inefficiente sfruttando più infrastrutture di risorse come computing, archiviazione e reti. Nella requisiti per il framework SLSA, le build automatiche sono requisito per il livello 1 di SLSA e l'utilizzo di un servizio di build al posto dello sviluppatore per le build è un requisito per il livello 2 di SLSA.

Cloud Build è il servizio di build gestito in Google Cloud. Utilizza un file di configurazione della build per fornire la build passaggi per Cloud Build. Puoi configurare le build per recuperare le dipendenze, eseguire test delle unità, analisi statiche e test di integrazione e 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é ambienti di runtime come GKE Cloud Run Fornisce inoltre l'integrazione con i principali codici sorgente come GitHub e Bitbucket.

Generare la provenienza della build

Provenienza build è una raccolta di dati verificabili su una build.

I metadati della provenienza includono dettagli come i digest delle immagini create, le posizioni delle origini di input, la toolchain di compilazione e la durata della compilazione.

Generare la provenienza della build ti aiuta a:

  • Verifica che un artefatto creato sia stato creato da una posizione di origine attendibile e da un sistema di compilazione affidabile.
  • Identificare il codice iniettato da una posizione di origine o da un sistema di compilazione non attendibile.

Puoi usare meccanismi di avviso e criteri per utilizzare in modo proattivo la provenienza della build e i dati di Google Cloud. Ad esempio, puoi creare criteri che consentono solo il deployment di codice creati da fonti verificate.

Per SLSA livello 1, la provenienza della build deve essere disponibile per i consumatori del modello artefatti. Per il livello 2 di SLSA, i dati sulla provenienza della compilazione devono inoltre essere:

  • Generati dal servizio di build o leggibili direttamente dal servizio di build.
  • Verificabile da un consumatore per verificarne l'autenticità e l'integrità. Questa operazione dovrebbe essere eseguita con una firma digitale generata dal servizio che crea la build la provenienza dei dati.

Per il livello 3 dell'SLSA, i contenuti sulla provenienza devono includere anche:

  • Il punto di contatto della definizione di build.
  • Tutti i parametri di build sotto il controllo di un utente.

Cloud Build può generare la provenienza della build per le immagini container che forniscono l'assicurazione della build di livello SLSA 3. Per ulteriori informazioni, vedi Visualizzazione della provenienza della build.

Utilizza un ambiente di build temporaneo

Gli ambienti temporanei sono temporanei pensati per durare singola chiamata build. Dopo la build, l'ambiente viene cancellato o eliminato. Le build temporanee assicurano che il servizio e i passaggi di build vengono eseguite in un ambiente temporaneo, ad esempio un container o una VM. Invece di riutilizzare un ambiente di build esistente, il servizio di build esegue il provisioning di un nuovo ambiente per ogni build, per poi distruggerla al termine del processo di compilazione.

Gli ambienti temporanei garantiscono build pulite poiché non sono presenti file residui o impostazioni dell'ambiente di build precedenti che possono interferire con la build e il processo di sviluppo. Un ambiente non temporaneo offre agli utenti malintenzionati l'opportunità di inserire file e contenuti dannosi. Un ambiente temporaneo riduce inoltre di manutenzione e riduce le incoerenze nell'ambiente di build.

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

Limitare l'accesso al servizio di compilazione

Rispetta il principio di sicurezza del privilegio minimo concedendo le autorizzazioni minime necessarie al servizio di compilazione e alle risorse di compilazione. Dovresti usano anche un'identità "non umana" per eseguire build e interagire per conto della build.

Se utilizzi Cloud Build:

  • Concedi le autorizzazioni minime richieste ai membri del tuo dell'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 del dominio predefinito account di servizio Cloud Build 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 che possono invocare gli attivatori 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 attraverso il perimetro in base alle regole specificate. La riduce anche 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, i depositi di elementi e gli ambienti di deployment. Protezione delle credenziali che che utilizzi nelle tue build contribuisce a impedire l'accesso non autorizzato ai sistemi nelle tue la catena di fornitura del software e l'esfiltrazione dei dati.

Evita di memorizzare le credenziali hardcoded direttamente nel controllo versione o nella configurazione di compilazione. 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 per utilizzare i secret archiviati in Secret Manager.

Gestisci le dipendenze

L'integrità delle applicazioni si basa sull'integrità sia del codice che sviluppi e le eventuali dipendenze che usi. Devi anche considerare dove pubblichi le dipendenze, chi ha accesso in lettura e scrittura ai repository di artefatti e i criteri per le origini attendibili degli artefatti di compilazione che esegui il deployment negli ambienti di runtime.

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

In Cloud Build, puoi utilizzare cloud builder per eseguire tramite comandi SQL. I builder sono immagini container in cui sono installati linguaggi e strumenti comuni. Puoi utilizzare immagini container pubbliche da registri pubblici come Docker Hub, builder forniti da Cloud Build, builder forniti dalla community e builder personalizzati che crei. Puoi puoi usare anche i buildpack come builder, ad esempio i buildpack di Google Cloud.

Esamina i builder che utilizzi nelle build di Cloud Build, scopri chi li fornisce e decidi se ti fidi del tuo software della catena di fornitura. Per mantenere un maggiore controllo sul codice in un builder, puoi Creare generatori personalizzati anziché usarli da una fonte pubblica.

Riduci le opportunità di modificare la compilazione

Esistono diversi altri fattori che possono influire su una build, tra cui:

  • Build eseguite contemporaneamente e in grado di influenzare l'una sull'altra. una build che persiste e influisce su una build successiva.
  • Build che accettano parametri utente diversi dal punto di ingresso della build e posizione di primo livello.
  • Build che specificano dipendenze con intervalli o dipendenze modificabile (ad esempio utilizzando un'immagine con il tag latest). Questi di deployment creano il rischio per le build di usare versioni errate o indesiderate delle dipendenze.

Le seguenti pratiche contribuiscono 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 compilazione.
  • Limita l'accesso al servizio di build e alle risorse della build.
  • Fai riferimento a versioni immutabili delle dipendenze anziché a identificatori come i tag che in futuro possono puntare a una versione diversa dell'elemento. Per ulteriori informazioni sulle dipendenze, consulta Gestione delle dipendenze.

Software Delivery Shield

Software Delivery Shield è una soluzione di sicurezza della catena di fornitura del software end-to-end e 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 security posture della supply chain del software. Mostra gli insight sulla sicurezza per le applicazioni create nell'interfaccia utente di Cloud Build nella console Google Cloud. tra cui:

  • Il livello SLSA, che identifica il livello di maturità della sicurezza della catena di fornitura del software.
  • Vulnerabilità, bill of materials (SBOM) del software e dichiarazioni Vulnerability Exploitability eXchange (VEX) per gli artefatti di compilazione.
  • Build provenienza, ovvero una raccolta di metadati verificabili su un creare. Include dettagli quali la sintesi delle immagini create, la le località delle origini di input, la toolchain di creazione, i passaggi e la durata della build.

Per istruzioni sulla visualizzazione degli insight sulla sicurezza per le applicazioni create, vedi Crea un'applicazione e visualizza insight sulla sicurezza.

Passaggi successivi