Fasi e attività

La tabella riportata di seguito elenca le attività eseguite in una pipeline RdA. 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 le pipeline DevSecOps sono dotate di un'implementazione predefinita o predefinita per lo stage. In particolare, per alcune fasi come unit-tests o setup, la pipeline DevSecOps non offre alcuna implementazione immediata. 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. Quando DevSecOps Pipeline fornisce un'implementazione di riferimento per una fase, la raccolta delle prove viene eseguita in modo immediato. 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 la pipeline DevSecOps non fornisce un'implementazione pronta all'uso, rendendo necessaria la raccolta di 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.

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

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.

Scansioni e verifiche di conformità

| Verifica della conformità del repository | Controlla che le impostazioni di protezione delle filiali siano corrette. |

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 sull'output previsto dagli stage di script utente, consultare Script personalizzati.

Lavori attività

Utilizzo delle modifiche PR/MR per il repo di configurazione della pipeline

Se la linea di comando della PR deve considerare le modifiche dei file/script di configurazione provenienti dalla PR/MR, il repo e il ramo di configurazione devono essere vuoti e possono essere impostati come segue:

• Le variabili env one-pipeline-repo, one-pipeline-config-repo e pipeline-config-repo sono vuote o non specificate nelle variabili env
• Le variabili env one-pipeline-config-branch e pipeline-config-branch sono vuote o non specificate nelle variabili env.

Unisci richieste di pull con problemi

Puoi utilizzare i diritti di amministratore per unire le richieste di pull con controlli dello stato non riusciti al repository. Tuttavia, queste richieste di pull registrano un failure come prova per l'attività non riuscita. Questo risultato è incluso nel riepilogo delle prove e nella descrizione della richiesta di modifica e influisce sul punteggio di conformità finale nel Security and Compliance Center.

Consentire la raccolta di prove nella pipeline delle PR

La pipeline PR supporta la raccolta delle prove e la gestione dei problemi. Per impostazione predefinita, la pipeline PR non raccoglie prove e non apre alcun problema, ma gli utenti possono optare per questa funzione. Per abilitare la raccolta delle prove e la gestione dei problemi, impostare la variabile d'ambiente collect-evidence-in-pr come uno dei seguenti enum:

• none: (predefinito) Impostare collect-evidence-in-pr a none, per impedire la raccolta di prove nella pipeline PR.
• all: Impostare collect-evidence-in-pr su all per raccogliere tutte le prove indipendentemente dallo stato della pipeline PR. Le questioni saranno aperte, aggiornate o chiuse secondo lo script collect-evidence.
• success: Impostare collect-evidence-in-pr a success per raccogliere le prove solo se l'intera pipeline PR è stata eseguita con successo. Se la pipeline PR non funziona, le prove non saranno raccolte o pubblicate nell'archivio delle prove e la gestione dei problemi non avrà luogo.

Nota: poiché le pipeline PR vengono generalmente eseguite con una certa frequenza, la scelta della modalità corretta di collect-evidence-in-pr eviterà la raccolta di prove non necessarie. Si suggerisce di selezionare la modalità success durante la fase di sviluppo o nei casi in cui si prevedono guasti, per evitare la raccolta di prove in caso di guasto della conduttura.

Se la pipeline PR attiva una pipeline Async, la modalità collect-evidence-in-pr impostata su success non è supportata. Se la pipeline PR attiva una pipeline async, impostare collect-evidence-in-pr su all per raccogliere le evidenze.

Nota: se il repository dell'applicazione è un repository GitLab e la MR (richiesta di fusione) che si sta contribuendo proviene da un repository biforcuto, l'utente dovrà fornire un valore per la variabile env git-token che ha accesso sia al repository di partenza che a quello di arrivo, per impostare gli stati corretti sulla richiesta di fusione. Ciò significa che il token git deve appartenere a un utente che sia un contributore sia nel repository di base sia nel repository biforcuto e che abbia i permessi per impostare lo stato su un commit.

Affiorano i CVE nelle PR

Quando viene creato un PR e le vulnerabilità vengono trovate dalla pipeline PR, la pipeline aggiunge le informazioni sulla vulnerabilità come la gravità, l'identificatore cve, il pacchetto con la sua descrizione e la correzione, se disponibile, come commento. Ciò consente agli utenti di verificare rapidamente le vulnerabilità da correggere nella PR, invece di dover esaminare i registri della pipeline.

È disponibile un flag di opt-in opt-in-pr-updates per abilitare/disabilitare questa funzione nella pipeline delle PR. È abilitata per impostazione predefinita.

Impostazione di una pipeline PR per gestire le PR di Github Merge Queue

La Merge Queue è una funzione di Github che aiuta ad aumentare la velocità automatizzando le fusioni delle richieste di pull in un ramo occupato e garantendo che il ramo non venga mai interrotto da modifiche incompatibili. Per saperne di più sulla configurazione e sull'uso di Github Merge Queue , cliccate qui.

Panoramica del carico utile PR

Proprietà dell'ambiente estratte dal payload PR

Le seguenti variabili d'ambiente sono attualmente derivate dal payload PR e vengono utilizzate attivamente:

Questi valori vengono iniettati come variabili d'ambiente per semplificare l'accesso durante l'esecuzione nei flussi di lavoro automatizzati.

Il payload PR comprende molti campi aggiuntivi rispetto a quelli elencati sopra. Tuttavia, solo il sottoinsieme estratto viene attualmente utilizzato per scopi operativi. Se necessario, è possibile accedere al carico utile completo per casi d'uso avanzati o per espansioni future.