Pipeline di conformità continua

La pipeline di conformità continua (pipeline CC) esegue periodicamente la scansione delle risorse distribuite e dei relativi repository di origine.

La pipeline CC elabora le voci dal repository inventory utilizzando il valore environment-tag per determinare quale è lo stato distribuito più recente da esaminare. Dopo la scansione e l'esecuzione dei controlli sulle risorse utente e sui repository di origine, la pipeline crea un nuovo problema di incidente o aggiorna i problemi di incidente esistenti nel repository di incidenti. Infine, utilizzando questi problemi e i risultati, la pipeline raccoglie le prove e le riassume per aggiornare lo stato di conformità degli artefatti trovati.

Fasi e attività

La tabella seguente elenca i compiti eseguiti in una pipeline CC. Inoltre la tabella fornisce anche una panoramica di ciascuna di queste fasi:

Attività o fase: fa riferimento al nome dello stage come definito nel file di configurazione .pipeline-config.yaml.
Breve descrizione: fornisce una breve spiegazione delle azioni eseguite durante l'esecuzione della fase.
Personalizzazione consentita: indica se gli utenti hanno la flessibilità di modificare o sostituire il comportamento predefinito dello stage inserendo uno script personalizzato nel file .pipeline-config.yaml.
Implementazione di riferimento predefinita: indica se ilDevSecOps le pipeline vengono fornite con un'implementazione predefinita o predefinita per la fase. In particolare, per alcune fasi come unit-tests O setup, ILDevSecOps la pipeline non offre alcuna implementazione pronta all'uso. Invece, agli utenti viene richiesto di fornire script o codice personalizzati in base ai requisiti dell'applicazione.
Raccolta di prove: indica se la fase esegue la raccolta di prove standard. QuandoDevSecOpsTubatura fornire un'implementazione di riferimento per una fase, la raccolta delle prove viene eseguita immediatamente. Tuttavia, se l'utente sceglie di modificare o sostituire questi stage predefiniti, deve assicurarsi che le proprie implementazioni personalizzate includano una raccolta di prove appropriata. La stessa responsabilità ricade sugli utenti per le fasi in cui ilDevSecOps la pipeline non fornisce un'implementazione pronta all'uso, rendendo necessaria la raccolta delle prove. La colonna indica l'entità (Utente / Pipeline) responsabile dell'esecuzione della raccolta di prove.
Ignora consentito (applicabile alla versione> = v10): indica se gli utenti possono scegliere di non eseguire questa fase impostando la proprietà ignora su true in .pipeline-config.yaml. Tuttavia, si consiglia cautela quando si utilizza questa funzione, specialmente per le fasi progettate per raccogliere le prove. Saltare tali fasi potrebbe portare alla mancanza di evidenze essenziali per la build.

Fasi e attività del processo di conformità continua
Attività o fase	Descrizione breve	Personalizzazione consentita in `.pipeline-config.yaml`	Implementazione di riferimento predefinita	Raccolta prove	Ignora consentito
`start`	Configura l'ambiente della pipeline.	No	Sì	Pipeline	No
`setup`	Impostare l'ambiente di build e di test.	Sì	No	No	No
`detect-secrets`	Eseguire la scansione dei segreti di rilevamento sul codice dell'applicazione.	Sì	Sì	Pipeline	No
`static-scan`	Eseguire il codice di scansione statica sul codice dell'applicazione.	Sì	Sì	Pipeline	Sì
`dynamic-scan`	Esegui scansione dinamica sull'applicazione.	Sì	Sì	Pipeline	Sì
`compliance-checks`	Esegui le scansioni di Code Risk Analyzer e altri controlli di conformità sui repository dell'app.	Sì	Sì	Pipeline	Sì
`scan-artifact`	Esegui la scansione delle risorse utente create.	Sì	Sì	Pipeline	Sì
`finish`	Raccogli, crea e carica i file di log, le risorse utente e le prove nel locker delle prove.	Sì	Sì	Pipeline	Sì

Per ulteriori informazioni su come personalizzare gli stage utilizzando il file .pipeline-config.yaml, vedi gli elenchi Script personalizzati e Parametri pipeline.

Fasi ed evidenze

La tabella seguente fornisce una relazione tra i vari tipi di prove e le fasi specifiche del processo di raccolta.

Fasi dell'integrazione continua e relative evidenze
Attività o fase	Tipo di Dimostrazione
`start`	NA
`setup`	NA
`detect-secrets`	`com.ibm.detect_secrets`
`static-scan`	`com.ibm.static_scan`
`compliance-checks`	`com.ibm.code_bom_check`, `com.ibm.code_cis_check`, `com.ibm.code_vulnerability_scan`, `com.ibm.branch_protection`
`dynamic-scan`	`com.ibm.dynamic_scan`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`finish`	`com.ibm.pipeline_logs`, `com.ibm.pipeline_run_data`

Per ulteriori informazioni su come raccogliere le prove all'interno delle fasi utente personalizzabili utilizzando lo script collect-evidence, consultare script di raccolta - prova.

Elaborazione dell'inventario per risorse utente e repository

La fase iniziale clona l'inventario ed elabora le voci più recenti nell'ambiente di produzione. È possibile specificare questo ambiente fornendo i seguenti parametri pipeline:

Artefatti e repository della pipeline di conformità continua
Nome	Immettere	Descrizione	Obbligatoria o facoltativa
`environment-tag`	text	Tag che rappresenta l'ultimo ambiente di destinazione nell'inventario. Esempio: `prod_latest` o `us-south_prod_latest`	Obbligatorio
`environment-branch`	text	Nome ramo che rappresenta l'ambiente di destinazione nell'inventario. Esempio: `prod`	Obsoleto - preferire invece `environment-tag`
`region-prefix`	text	Nome della regione come prefisso per la tag `latest` per l'ambiente di destinazione. Esempio: `us-south`	Obsoleto - preferire invece `environment-tag`

Le voci di inventario contengono risorse distribuite e origini repository. La pipeline elabora e raccoglie le voci di inventario e le registra per l'esecuzione della pipeline utilizzando i seguenti comandi pipelinectl:

La fase iniziale clona anche i repository trovati, ogni repository e ogni coppia di commit. Quindi, ad esempio, repo1 con commit sha1 vengono clonati in una cartella, ma la pipeline clona lo stesso repo1 con commit sha2 in una cartella separata.

La pipeline registra le risorse utente e i repository per la pipeline eseguita utilizzando una semplice notazione di denominazione e incrementando l'indice, come i seguenti esempi:

repo-1, repo-2, repo-3
artifact-1 artifact-2, artifact-3

Puoi elencare queste voci negli stage personalizzati utilizzando i seguenti comandi pipelinectl:

Se richiami le informazioni del ramo nella tua pipeline CC utilizzando il pipelinectl comando load_repo "$repo" branch, restituisce sempre master come ramo. Pertanto, utilizzare commit hashes anziché i rami.

Fase di impostazione

La fase di configurazione nella pipeline CC esegue lo script che si trova nella fase setup definita da .pipeline-config.yaml. Puoi stabilire in quale pipeline lo script è in esecuzione utilizzando il seguente comando:

get_env pipeline_namespace

Questo comando restituisce cc, cd, ci o pr, a seconda della pipeline in esecuzione. In questo modo, è possibile riutilizzare lo script di configurazione tra le pipeline, se necessario.

Rileva scansione segreti

Lo strumento IBM Rileva segreti identifica dove i segreti sono visibili nel codice dell'applicazione. Ulteriori informazioni sulla configurazione del tuo repository per la scansione sono disponibili qui.

Scansione del codice statico

La fase di scansione del codice statico esegue uno strumento di analisi del codice statico sui codebase del repository dell'applicazione specificati.

La pipeline CC fornisce i repository trovati nell'inventario per lo scanner.

Puoi utilizzare uno dei seguenti metodi per aggiungere codice statico alla tua pipeline:

Fornire il nome di un'istanza SonarQube già in esecuzione, URL, e le credenziali aggiungendo lo strumento SonarQube alla propria toolchain. L'attività static-scan esegue una scansione sui repository specificati.
Aggiungi il tuo codice allo stage personalizzato static-scan nel tuo file .pipeline-config.yaml per un'implementazione personalizzata.

Scansione dinamica

La fase di scansione dinamica esegue uno strumento di test di sicurezza dell'applicazione dinamico per individuare le vulnerabilità nell'applicazione distribuita.

Aggiungere il proprio codice di scansione dinamica allo stage personalizzato di scansione dinamica nel file .pipeline-config.yaml per un'implementazione personalizzata.

Per ulteriori informazioni sulla configurazione della scansione dinamica utilizzando OWASP-ZAP, vedi Configurazione della scansione ZAP per la pipeline CC.

Scansioni e verifiche di conformità

Scansioni e controlli di conformità
Scansione o controllo	Descrizione
Scansione vulnerabilità di Code Risk Analyzer	Trova le vulnerabilità per tutte le dipendenze del pacchetto app, le immagini di base del contenitore e i pacchetti del sistema operativo. Utilizza lo strumento Code Risk Analyzer.
Verifica CIS di Code Risk Analyzer	Esegue i controlli di configurazione sui manifest di distribuzione Kubernetes. Utilizza lo strumento Code Risk Analyzer.
Verifica BOM (Bill of Material) di Code Risk Analyzer	Il BOM per un repository specificato che cattura il pedigree di tutte le dipendenze. Questo BOM viene raccolto in diverse granularità. Ad esempio, il BOM cattura l'elenco delle immagini di base utilizzate nella build, l'elenco dei package dalle immagini di base e l'elenco dei package di applicazione installati sull'immagine base. Il BOM funge da ground truth per i risultati analitici e può potenzialmente essere utilizzato per applicare i gate della politica. Utilizza lo strumento Code Risk Analyzer.

Questi script vengono eseguiti su tutti i repository dell'applicazione di cui la pipeline è a conoscenza. La pipeline CC utilizza l'interfaccia pipelinectl save_repo per registrare i repository trovati nelle voci di inventario, quindi utilizza i comandi list_repos e load_repo per iterare i repository e inviarli agli scanner.

Per ulteriori informazioni sull'output previsto dagli stage di script utente, consultare Script personalizzati.

Scansione e firma della risorsa utente

La fase di scansione della risorsa utente fornisce il funzionamento predefinito per le immagini Docker, con un passo personalizzabile:

Scansione Container Registry Vulnerability Advisor

La pipeline CC utilizza l'interfaccia pipelinectl save_artifact per registrare le risorse trovate nelle voci di inventario, quindi esegue l'iterazione su tali risorse, utilizzando i comandi list_artifacts e load_artifact.

Per iniziare con questa fase, fornisci le tue risorse per la pipeline utilizzando l'interfaccia pipelinectl. Non è necessario aggiornare gli script di build e la configurazione di .pipeline-config.yaml.

Per utilizzare un processo di scansione diverso o per elaborare le risorse utente diverse dalle immagini Docker in icr.io, puoi personalizzare queste fasi utilizzando la configurazione .pipeline-config.yaml nel tuo progetto.

Raccolta dei dati di conformità durante la creazione

La pipeline CC tenta di elaborare i risultati delle verifiche e delle scansioni, suddividendo i risultati in singoli problemi per ogni CVE, vulnerabilità o avviso trovato. I problemi rilevati dalla pipeline CC sono contrassegnati con un'etichetta continuous-compliance-check che identifica i problemi rilevati nell'ambiente prod.

La pipeline raccoglie le prove su tutti i controlli e le scansioni e le memorizza nel locker delle prove. Il programma di raccolta di prove salva anche i file di log della pipeline, i dati della pipeline stessi, contenenti le definizioni Tekton. I problemi creati in base alla scansione e verificare che i risultati siano allegati alla prova.