Pipeline di integrazione continua

La pipeline di integrazione continua crea le risorse distribuibili dai repository delle applicazioni.

Prima di creare una risorsa utente, la pipeline verifica che il codice sia sottoposto a scansione e a test, nello stesso modo in cui vengono elaborate le richieste di pull. Le risorse utente create vengono anche sottoposte a scansione per rilevare eventuali vulnerabilità e firmate nella pipeline prima di essere contrassegnate come pronte per la release e la distribuzione nell'inventario. A differenza della pipeline di richiesta di pull, la pipeline di integrazione continua raccoglie le prove e le risorse utente dei risultati su ciascuna fase della build, come test, scansione e firma. Questi dati sono correlati alle risorse utente create e possono essere tracciati attraverso il processo di distribuzione e la gestione delle modifiche.

Fasi e attività

La tabella seguente elenca i compiti eseguiti in una pipeline CI. 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 compiti dell'integrazione continua
Attività o fase	Descrizione breve	Personalizzazione consentita in `.pipeline-config.yaml`	Implementazione di riferimento predefinita	Raccolta di prove	Ignora consentito
`start`	Configurare l'ambiente della pipeline.	No	Sì	Pipeline	No
`setup`	Configurare l'ambiente di build e di test.	Sì	No	NA	No
`detect-secrets`	Eseguire la scansione di rilevamento segreti sul codice dell'applicazione.	Sì	Sì	Pipeline	No
`test`	Eseguire test di unità e test di applicazione sul codice dell'applicazione.	Sì	No	Utente	Sì
`static-scan`	Eseguire il codice di scansione statico sul codice dell'applicazione.	Sì	Sì	Pipeline	Sì
`compliance-checks`	Eseguire le scansioni di Code Risk Analyzer e altri controlli di conformità sui repository delle applicazioni.	Sì	Sì	Pipeline	Sì
`peer-review`	Raccogliere dati di conformità relativi alle revisioni tra pari per le richieste di pull unite.	Sì	Sì	Pipeline	Sì
`containerize`	Creare le risorse utente.	Sì	No	NA	No
`sign-artifact`	Firma le risorse utente create.	Sì	Sì	Pipeline	No
`deploy`	Distribuisci le risorse utente create nell'ambiente di sviluppo.	Sì	No	NA	No
`dynamic-scan`	Eseguire la scansione dinamica sull'applicazione.	Sì	Sì	Pipeline	Sì
`acceptance-test`	Eseguire i test di accettazione e integrazione sulle risorse utente create distribuite nell'ambiente di sviluppo.	Sì	No	Utente	Sì
`scan-artifact`	Eseguire la scansione delle risorse utente create.	Sì	Sì	Pipeline	Sì
`release`	Aggiungere le risorse utente create all'inventario.	Sì	No	NA	Sì
`finish`	Raccogliere, creare e caricare i file di log, le risorse utente e le prove nel blocco di prove.	Sì	Sì	NA	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`
`test`	`com.ibm.unit_tests`
`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`
`peer-review`	`com.ibm.peer_review`
`containerize`	NA
`sign-artifact`	`com.ibm.cloud.image_signing`
`deploy`	NA
`dynamic-scan`	`com.ibm.dynamic_scan`
`acceptance-test`	`com.ibm.acceptance_tests`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`release`	NA
`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.

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

Lo stage di scansione del codice statico esegue un certo numero di strumenti di analisi del codice statico sui repository dell'applicazione specificati. Viene eseguita la scansione dei repository forniti dal comando pipelinectl save_repo e dal repository dell'applicazione predefinito.

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

Fornisci un nome di istanza di SonarQube già in esecuzione, URL, e le credenziali aggiungendo lo strumento SonarQube alla tua toolchain. L'attività di scansione statica esegue una scansione sui repository specificati.
Se non hai la tua propria istanza SonarQube, la pipeline crea un'istanza SonarQube durante l'esecuzione della pipeline. È possibile accedere a questa istanza dopo che la fase di scansione statica è stata eseguita correttamente.
Utilizzando il parametro opt-in-gosec per eseguire la scansione gosec per i controlli di sicurezza golang.
Aggiungere il proprio codice di scansione statica allo stage personalizzato di scansione statica nel proprio file .pipeline-config.yaml per un'implementazione personalizzata.

Aggiunta della scansione SonarQube alle tue pipeline

Per ulteriori informazioni sull'integrazione di SonarQube con la pipeline di integrazione continua, vedi Configuring SonarQube.

Aggiunta dell'integrazione della scansione gosec alle tue pipeline

Utilizza gosec per esaminare il codice sorgente golang nei tuoi repository scansionati.

Per abilitare la scansione gosec, fornire il parametro seguente e impostare il valore su 1.

parametri di scansione gosec
Nome	Tipo	Descrizione	Obbligatorio o facoltativo
`opt-in-gosec`	text	opzione per abilitare la scansione gosec	facoltativo

Ulteriori informazioni sull'impostazione della scansione gosec nella pipeline di integrazione continua, vedi Configurazione di GoSec

Utilizzo di altri scanner statici

Se invece vuoi utilizzare la tua implementazione di scansione statica, puoi modificare la tua .pipeline-config.yaml file e aggiungi il tuo script personalizzato al static-scan palcoscenico.

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 app installati sull'immagine di base. Il BOM funge da ground truth per i risultati analitici e può essere potenzialmente utilizzato per applicare i gate della politica. Utilizza lo strumento Code Risk Analyzer.
Controllo di conformità del repository	Verifica che le impostazioni di protezione del ramo siano corrette. Ad esempio, il ramo principale / principale deve sempre limitare la forza di spinta. Per ulteriori informazioni, vedi Configurazione del tuo repository Git Repos and Issue Tracking.

Questi script vengono eseguiti su tutti i repository dell'applicazione di cui la pipeline è a conoscenza. Per aggiungere i repository a queste scansioni, utilizza l'interfaccia pipelinectl fornita nella fase di configurazione.

Per ulteriori informazioni sul risultato previsto dalle fasi dello script utente, vedere Script personalizzati.

Nota: le pipeline CI non vengono attivate sui tag perché non supportano funzionalità come branch protection checks o peer review check. Se si sceglie di eseguire una pipeline CI sui tag, assicurarsi di disabilitare le proprietà peer-review-compliance e branch-protection-check impostandole su 0. Tuttavia, si tenga presente che in questo caso la raccolta delle prove non avverrà per questi casi.

Genera

Nella fase di creazione, è possibile creare le proprie risorse utente. Sebbene la pipeline fornisca alcune funzioni predefinite per le risorse di tipo immagine Docker, puoi creare qualsiasi tipo di risorsa utente in questa fase.

Utilizza le variabili di ambiente dall'IU Pipeline per fornire le credenziali, i segreti e i parametri per la tua build. Puoi accedere a tali variabili di ambiente in questo stage e in tutti gli stage personalizzati. Per ulteriori informazioni su come accedere ai parametri e ai segreti nelle fasi di script personalizzati, vedere Script personalizzati.

Scansione e firma della risorsa utente

Le fasi di scansione delle risorse utente e di firma forniscono un funzionamento predefinito per immagini Docker, con passi personalizzabili:

Firma immagine utilizzando la chiave GPG.
Scansione Container Registry Vulnerability Advisor.

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

Per utilizzare un processo di scansione o di firma differente 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.

Distribuisci a dev

Lo stage Deploy distribuisce le risorse utente create in un ambiente di sviluppo.

Scansione dinamica

La scansione dinamica del codice è una forma di scansione delle vulnerabilità black box che consente ai team software di eseguire la scansione delle applicazioni in esecuzione e identificare le vulnerabilità.

La fase di scansione dinamica viene eseguita immediatamente dopo la fase Deploy to dev dopo una distribuzione corretta all'ambiente di sviluppo.

Per impostazione predefinita, la pipeline fornisce supporto per eseguire la scansione ZAP (Zed Attack Proxy), che è uno strumento di test di penetrazione libero e open source gestito sotto l'ombrello di OWASP. Esegue sia le scansioni dinamiche API che UI, entrambe che possono essere eseguite sull'applicazione hello - compliance di esempio.

Per eseguire la scansione dinamica, impostare il parametro della pipeline opt-in-dynamic-scan su un valore non vuoto. Per disabilitare lo stage dall'esecuzione di scansioni dinamiche, impostare il parametro della pipeline opt-in-dynamic-scan su vuoto. Per ulteriori informazioni sull'impostazione dei parametri della pipeline, vedi Parametri della pipeline.

La pipeline IC crea problemi nel repository di problemi in base alla severità. L'etichetta allegata al problema indica la gravità della vulnerabilità.

Scansione API ZAP

L'API ZAP esegue la scansione degli endpoint dell'applicazione alla ricerca di possibili perdite di dati, errori di tipo contenuto, reindirizzamenti esterni, code injection, SQL injection, remote OS command injection e altre vulnerabilità esposte dall'applicazione. Le scansioni ZAP API aiutano gli sviluppatori a proteggere l'applicazione rilevando queste vulnerabilità in una fase o in un ambiente di test e correggendole prima che l'applicazione venga distribuita in un ambiente di produzione.

Le scansioni API ZAP richiedono i seguenti input per eseguire la scansione dell'applicazione:

Swagger Definition File - Descrizione delle API dell' HTTP e e dei relativi parametri associati esposti dall'app.
Chiave API - Token di autenticazione richiesto per l'autenticazione con gli endpoint API.
Endpoint API - Endpoint dalle definizioni swagger di cui si desidera che ZAP esegua la scansione.
URL esclusi - Gli URL che devono essere ignorati dallo scanner ZAP.

ZAP API Scanner utilizza gli input menzionati per eseguire la scansione e produrre un report.

Impostare opt-in-dynamic-api-scan su un valore non vuoto per le scansioni API ZAP da eseguire. Per annullare l'opzione, impostare questo parametro su vuoto.

Scansione UI ZAP

ZAP UI esegue una scansione degli endpoint dell'applicazione alla ricerca di vulnerabilità presenti nelle pagine web stesse, quali cookie non sicuri impostati, impostazioni errate delle intestazioni di cache, inclusioni di file tra domini diversi, impostazioni errate di " CORS " e altre vulnerabilità esposte dall'applicazione.

Le scansioni IU funzionano in modo simile alle scansioni API, ma utilizzano uno script di test IU invece di un file Swagger. Lo script di test IU avvia un browser headless configurato per eseguire il proxy tramite il proxy dello scanner ZAP ed esegue un test IU rispetto all'endpoint IU. Il processo per eseguire i test UI ZAP è il seguente:

Copiare gli script di test nei contenitori dello scanner ZAP.
Eseguire il proxy ZAP.
Eseguire gli script di test zap.

Il proxy ZAP registra il traffico e rileva gli endpoint di cui eseguire la scansione. Una volta completate le scansioni, il proxy produce un report e genera i problemi nello stesso modo della scansione API ZAP.

Impostare opt-in-dynamic-ui-scan su un valore non vuoto per le scansioni API ZAP da eseguire. Per annullare l'opzione, impostare questo parametro su vuoto.

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 scansione API ZAP e sulle scansioni UI ZAP, vedi Configurazione delle scansioni ZAP.

Rilascia nell'inventario

Utilizzare la fase di rilascio dello script utente di inventario per aggiungere risorse utente all'inventario utilizzando il comando CLI cocoa inventory add. Per ulteriori informazioni relative al comando, consultare l'argomento relativo all'aggiunta dell'inventario di cacao.

Se vuoi ignorare l'aggiornamento dell'inventario se ci sono problemi nella pipeline, utilizza le seguenti variabili di ambiente per verificare lo stato della pipeline. Verificare il relativo stato prima di aggiornare l'inventario:

skip-inventory-update-on-failure Variabile di ambiente opt - in dalla pipeline per specificare se l'aggiornamento dell'inventario deve essere eseguito.
one-pipeline-status È impostato su 1 se si verifica un malfunzionamento della fase nell'esecuzione della pipeline.

Puoi utilizzare l'interfaccia pipelinectl per accedere ai tuoi repository e risorse utente utilizzando i comandi list_repos, load_repo, list_artifacts e load_artifact. Per ulteriori informazioni sui comandi, vedi la documentazione pipelinectl.

Raccolta dei dati di conformità sulla build

Quando la pipeline viene eseguita correttamente, è possibile raccogliere le informazioni sulla build.

Le prove vengono raccolte su tutti i controlli, le scansioni, i test e le risorse utente che accedono all'armadietto delle prove. I file di log della pipeline vengono salvati anche nell'locker, insieme ai dati della pipeline stessi, contenenti le definizioni Tekton. I dati di conformità sulle revisioni peer vengono raccolti anche in questa fase. La pipeline utilizza pipelinectl per ricercare i repository con le richieste di pull unite dall'ultima build. Controlla inoltre lo stato della revisione, la salva come risorsa utente e crea la prova in base al risultato.

Lo script finale è un programma di valutazione, che contrassegna lo stato della pipeline in verde o in rosso, in base agli stati della prova. Se contengono errori, l'esecuzione dell'integrazione continua viene contrassegnata in rosso.