Gestione dei problemi relativi agli incidenti
Da una prospettiva di conformità, la creazione, l'archiviazione e l'aggiornamento di problemi di incidente (vulnerabilità, CVE) come parte delle pipeline Continuous Integration e Continuous Compliance sono essenziali per la raccolta di prove.
Durante l'esecuzione della pipeline PR con la raccolta delle prove abilitata, delle pipeline CI e CC, il collect-evidence script crea problemi di incidenti,
li collega alle prove raccolte e li archivia nel repository dei problemi di incidenti.
Lo script collect-evidence utilizza le funzioni del comando cacao incident process, che elabora i risultati della scansione forniti e crea nuovi problemi
di incidente nel repository fornito per vulnerabilità o aggiorna i problemi di incidente esistenti in base alle coppie soggetto - incidente. Pertanto, i problemi di incidente sono collegati agli asset e creati in base al risultato di specifici
strumenti. Per ulteriori informazioni, vedi Differenza tra l'elaborazione dei problemi nelle pipeline CI e CC.
Elaborazione dei problemi di incidente nella pipeline PR
La pipeline PR con la raccolta delle prove abilitata può creare problemi di incidenti quando si incontrano vulnerabilità o CVE. Per abilitare la raccolta delle prove nella pipeline PR, consultare:Raccolta delle prove nella pipeline PR
La gestione dei problemi nella pipeline PR è simile a quella della pipeline CI. L'unica differenza sta nella logica di autoclavaggio.
Un problema creato da una pipeline di PR può essere autocluso solo da una pipeline di PR in esecuzione sulla stessa PR. Il problema non può essere autocluso da una pipeline di PR quando:
- Il problema viene trovato da una pipeline di PR in esecuzione su qualsiasi altra PR.
- Il problema viene rilevato da qualsiasi pipeline CI o CC.
Elaborazione problema incidente
Anche se le pipeline CI e CC hanno passi comuni, l'elaborazione del problema di queste pipeline presenta alcune differenze:
- I problemi di incidente creati durante la pipeline IC non portano una data di scadenza, mentre i problemi di incidente creati durante la pipeline CC lo fanno.
- I problemi di incidente creati durante la pipeline CI vengono trovati durante la creazione, mentre i problemi di incidente creati durante la pipeline CC vengono trovati nell'ambiente di produzione.
Le figure da 1 a 6 mostrano i possibili casi di utilizzo basati su queste differenze.
Ciclo di vita del problema
Il ciclo di vita del problema si estende dalle RdA del codice alle scansioni di produzione.
Caso di utilizzo 1: vulnerabilità rilevata nella build
La nuova build introduce una vulnerabilità, che non è accettata. La distribuzione è bloccata a meno che la richiesta di modifica non sia una CR di emergenza approvata manualmente.
Il flusso della pipeline di compilazione in caso di rilevamento di una vulnerabilità e le azioni corrispondenti dell'utente sono illustrate nel diagramma seguente.
Caso di utilizzo 2: vulnerabilità trovata nella build che è anche in produzione
La nuova build contiene una vulnerabilità che si trova anche nella produzione attualmente distribuita. I team dispongono di una sequenza temporale per risolvere il problema, ma è ancora possibile distribuire nuove funzioni o correzioni.
La pipeline CC imposta la sequenza temporale per correggere eventuali vulnerabilità di questo tipo rilevate in produzione. Avrà esito negativo solo quando la sequenza temporale per correggere la vulnerabilità è scaduta. Il flusso è illustrato nel seguente diagramma.
Caso di utilizzo: 2A: la vulnerabilità rilevata in produzione consente RdA
La vulnerabilità nella produzione non impedisce la fusione delle RdA.
Caso d'uso 3: falsi positivi ed esenzioni
Se il team classifica un problema come falso positivo o riceve un'eccezione di sicurezza relativa a una vulnerabilità, il problema può essere contrassegnato come "Esente". Il problema può quindi essere gestito come un problema non bloccante. Per mantenere un audit trail, le richieste di modifica mantengono visibili i problemi.
Caso di utilizzo 4: chiusura automatica dei problemi fissi
L'esecuzione periodica della pipeline CC può chiudere i problemi aperti e con una data di scadenza impostata. Inoltre, la vulnerabilità rilevante non può essere trovata nelle scansioni.
Il seguente diagramma spiega il diagramma di flusso della pipeline CC che rileva quali problemi chiudere e quali problemi creare nuovi.
Gestione delle scadenze relative ai problemi legati agli incidenti
Quando vengono rilevati problemi relativi a un incidente nell'ambiente di produzione, viene automaticamente aggiunta la proprietà " Due Date " per specificare il periodo di tolleranza entro il quale il problema deve essere
risolto. La durata del periodo di dilazione è determinata dalla gravità della vulnerabilità rilevata.
Casi più comuni relativi alla data di scadenza
Gli scenari seguenti descrivono le modalità di gestione delle scadenze:
- Assegnazione iniziale della data di scadenza: quando la pipeline CC rileva un problema in produzione, calcola e imposta automaticamente una data di scadenza in base alla gravità del problema.
- Proroga della scadenza: se hai bisogno di più tempo per risolvere un problema, puoi prorogare la scadenza previa approvazione da parte di un referente per la sicurezza. Per ulteriori dettagli, consultare la sezione “Rinvio della data di scadenza ”.
- Problemi in ritardo: anche quando i problemi sono in ritardo, le pipeline CI possono comunque procedere con le distribuzioni, purché la nuova build non peggiori l'ambiente di produzione (approccio basato esclusivamente sulla gestione del rischio). Ciò consente ai team di continuare a rilasciare nuove funzionalità mentre lavorano per risolvere i problemi di sicurezza.
Per ulteriori informazioni sulla personalizzazione dei periodi di tolleranza, vedi Configurazione dei periodi di tolleranza personalizzati sulla pipeline CC.
Etichettatura dei problemi di incidente
I problemi di incidente creati dalle pipeline di integrazione continua (CI) o di conformità continua (CC) possono avere etichette predefinite.
Etichette per problemi di incidente rilevati da Code Risk Analyzer
Code Risk Analyzer (CRA) rileva più tipi di vulnerabilità, come la dipendenza dell'app e la vulnerabilità delle immagini.
Il tipo di vulnerabilità può essere il seguente: name os, python, js, golang o java.
Se il tipo di vulnerabilità è di tipo os, al problema viene allegata un'etichetta os-vulnerability. Per qualsiasi altro tipo di vulnerabilità, al problema è allegata un'etichetta app-vulnerability.
Etichette per problemi di incidente con correzioni disponibili
Per i problemi di incidente creati dalla pipeline di integrazione continua (CI) o dalla pipeline di conformità continua (CC), lo scanner potrebbe avere informazioni di correzione come parte del risultato della scansione. Se sono disponibili
informazioni sulla correzione, viene aggiunta un'etichetta fix-available al problema dell'incidente con un collegamento alla descrizione della correzione all'interno della descrizione del problema.
L'assenza dell'etichetta fix-available non significa che il problema non può essere risolto perché non tutti gli scanner includono le informazioni di correzione nel risultato di scansione. Lo scanner suggerisce le informazioni
di correzione, e tali informazioni provengono da qualsiasi origine dello scanner questi dati "di correzione". Alcuni scanner potrebbero non avere dizionari "fix" aggiornati o non contenere informazioni per una fix.
Problemi di incidente con data di scadenza
Quando si utilizza lo script collect - evidence, i problemi di incidente vengono creati e allegati alla prova raccolta. Se i problemi vengono rilevati in produzione, possono avere un periodo di tempo specificato in cui devono essere corretti in modo che le distribuzioni non siano bloccate. L'intervallo di tempo fornito per risolvere il problema in produzione è denominato periodo di tolleranza. Tuttavia, per una migliore leggibilità, Data di scadenza è ora disponibile nei problemi di incidente in modo che gli utenti conoscano la data di scadenza della correzione senza calcolarla dal periodo di dilazione.
Se un problema come la vulnerabilità o il CVE si trova in produzione e lo stesso problema si trova anche in una build, la build non peggiora la situazione. La funzione può essere distribuita e il team può concentrarsi sulla risoluzione del problema in produzione.
Configurazione dei periodi di tolleranza personalizzati sulla pipeline CC
La pipeline Continuous Compliance (CC) calcola le date di scadenza dei problemi di incidente in base alla severità di un problema. È possibile modificare i valori del periodo di tolleranza predefiniti e sostituirli con valori personalizzati.
La pipeline calcola il periodo di tolleranza in base alla seguente tabella:
| Severità | Periodo di proroga |
|---|---|
| Informativo | 180 giorni |
| Basso | 180 giorni |
| Medio | 90 giorni |
| Alto | 30 giorni |
| Critico | 30 giorni |
Per modificare la configurazione predefinita, crea una nuova proprietà nelle proprietà di ambiente della pipeline CC denominate grace-period-configuration. Questa proprietà di ambiente deve essere una stringa JSON e deve corrispondere
al seguente formato:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
Se la proprietà dell'ambiente non corrisponde al formato previsto o non è una stringa JSON valida, la pipeline utilizza i valori predefiniti.
La proprietà di ambiente grace-period-configuration imposta le date di scadenza per i problemi che non hanno già una data di scadenza impostata. Per i problemi con una data di scadenza impostata, la riconfigurazione di grace-period-configuration non aggiorna tali date di scadenza.
Calcolo della data di scadenza
La data di rilevamento è quando la pipeline di conformità continua (CC) viene eseguita e rileva il problema nell'ambiente di produzione. Se il problema esiste, CC lo aggiorna con la Data di scadenza calcolata da quel momento.
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
Formato data di scadenza
La data di scadenza è in formato ISO 8601 e viene visualizzata come AAAA - MM - GG.
Esempio: Due Date: 2022-04-01
Casi di utilizzo
-
È stata rilevata una vulnerabilità in una delle immagini di base in produzione dalla pipeline CC. Il team riceve una notifica di un problema di incidente con un periodo di tolleranza impostato in base alla severità della vulnerabilità. Il periodo di dilazione è il numero di giorni in cui il team deve distribuire una fix.
-
Il team crea una nuova release con una nuova funzionalità. La build trova un CVE associato con l'immagine di base utilizzata per l'applicazione. Il team esegue manualmente la pipeline CC, che esegue la scansione delle risorse utente già in produzione. L'esecuzione CC manuale rileva lo stesso CVE nella stessa applicazione in produzione e aggiunge il periodo di dilazione al problema dell'incidente. Il team può ora creare e distribuire senza essere bloccato.
Differenze tra l'elaborazione dei problemi nelle pipeline CI e CC
I problemi relativi agli incidenti vengono creati nelle pipeline CI e CC:
- Un problema creato in IC significa che è stato trovato durante la generazione.
- Un problema creato in CC indica che è stato trovato nell'ambiente di produzione.
Una data di scadenza può essere aggiunta automaticamente ai problemi solo se sono correlati a problemi rilevati nell'ambiente di produzione. Ciò significa che solo la pipeline CC può aggiungere la data di scadenza a un problema. Se l'IC trova il problema e la data di scadenza non è disponibile, il valore della data di scadenza è n / a.
Elaborazione dei risultati in problemi
I problemi rilevati vengono creati in base ai risultati degli strumenti specifici. Lo script collect-evidence tenta di elaborare i file dei risultati negli allegati e creare un elenco di problemi.
I problemi sono collegati ad asset, che possono essere commit in un repository o un'immagine docker con un digest.
Viene creato un problema per ogni ID problema - un ID problema è composto dai componenti seguenti:
- Asset collegato
- Lo strumento che ha rilevato la vulnerabilità
- L'identificativo di vulnerabilità (ad esempio, l'ID CVE)
Ad esempio, se CVE-2022-001 viene trovato da due strumenti separati, il processo crea oggi due problemi.
Strumenti supportati
La gestione degli incidenti supporta i risultati provenienti da vari strumenti di scansione integrati nelle pipeline di DevSecOps. Per l'elenco aggiornato degli strumenti di scansione supportati e delle relative funzionalità, consultare la sezione " Strumenti di scansione supportati ".
Strumenti non supportati o formati dei risultati
Se lo script collect-evidence riceve un allegato da uno strumento non supportato o il formato del file dei risultati non viene riconosciuto durante l'elaborazione, lo script ignora la creazione di problemi e utilizza il file
dei risultati come un semplice allegato alla prova.
Contenuto problema
- Problema è il nome del problema o della vulnerabilità.
- Data di scadenza mostra la data di scadenza della correzione oppure n / a se non è disponibile alcuna data di scadenza.
- Oggetto è l'asset a cui è collegato il problema.
- URL è il link alla versione esatta della risorsa.
- Tipo di strumento è lo strumento che ha prodotto il contenuto per il problema
Per i problemi creati su Git Repos and Issue Tracking, la data di scadenza viene impostata nel campo della data di scadenza nativa di GitLab invece che nella descrizione del problema.
La descrizione del problema contiene la data e l'ora in cui il problema è stato rilevato per la prima volta. Ad esempio, First found on 2022-04-07. La data è nel formato YYYY-MM-DD. Le ubicazioni in cui si verifica
il problema sono elencate nei commenti del problema.
Proroga della scadenza relativa a un problema legato a un incidente
È possibile prorogare la data di scadenza di un problema relativo a un incidente qualora sia necessario più tempo per implementare una soluzione. Ciò richiede l'approvazione di un referente per la sicurezza, al fine di garantire un adeguato controllo delle vulnerabilità di sicurezza.
Procedura per la proroga delle scadenze
- Richiedi una valutazione al tuo referente per la sicurezza, spiegando perché l'estensione è necessaria.
- Una volta ottenuta l'approvazione, aggiorna la data di scadenza:
- Per Git Repos and Issue Tracking: modificare il campo "
Due date" nei campi dei metadati della segnalazione. - Per GitHub Enterprise: modifica il campo "
Due date" nella descrizione del ticket.
- Per Git Repos and Issue Tracking: modificare il campo "
- Fai riferimento all'approvazione del responsabile della sicurezza nella segnalazione, aggiungendo un commento con un link alla documentazione relativa alla revisione o all'approvazione.
Assicurarsi di fare riferimento alla revisione focale di sicurezza nel problema, ad esempio fornire un link ad esso in un commento.
Eccezioni di sicurezza
Se si verifica un problema legato a un'eccezione di sicurezza, è possibile prorogare la data di scadenza in modo che coincida con la data di scadenza dell'eccezione stessa. Ciò garantisce che la raccolta delle prove e il monitoraggio della conformità proseguano in modo adeguato fino alla scadenza dell'eccezione.
Avvisi slack per problemi in sospeso e scaduti per pipeline CC
La pipeline CC (Continuous Compliance) può impostare le date di scadenza per i problemi di incidente. La pipeline può anche notificare agli utenti i problemi che si avvicinano alle date di scadenza e le date di scadenza scadute utilizzando Slack, se l'integrazione Slack è abilitata.
Per ulteriori informazioni, vedi Configurazione di una toolchain CI(Continuous Integration). Per ulteriori informazioni sulle date di scadenza, vedi [Problemi di incidente con data di scadenza](/docs/devsesbirri? topic = devsesbirri - incident - issues#devsecops- devsesbirri - issues - scade - date.
I problemi notificati sono classificati come segue:
- Problemi con date di scadenza in sospeso entro un periodo di tempo specifico: problemi aperti, con date di scadenza e con scadenza entro un periodo di tempo.
- Problemi con date di scadenza passate: i problemi che sono aperti, hanno date di scadenza e la data è passata.
I periodi di tempo sono overdue, due in 1 day, due in 2 days, due in 5 days e due in 10 days.
Un esempio di questa funzione è il seguente:
Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>
L'elenco aggregato viene ordinato con i problemi scaduti per primi e i problemi con le date di scadenza più vicine vengono elencati prima di quelli con una data di scadenza successiva.
La fase cc-finish nella pipeline CC esegue la query dei problemi in base ai criteri e attiva un avviso Slack.