Migliori pratiche per le catene di strumenti " DevSecOps "

Le sezioni seguenti descrivono le migliori pratiche per ciascuna catena di strumenti " DevSecOps ": integrazione continua (CI), CI per l’infrastruttura come codice ( IaC ), distribuzione continua (CD) e conformità continua (CC).

Migliori pratiche per la catena di strumenti di integrazione continua (CI)

La catena di strumenti CI di DevSecOps segue queste pratiche:

  • Esegue detect-secrets sui repository delle applicazioni per prevenire la fuga di informazioni riservate nel codice sorgente delle applicazioni.
  • Esegue i test unitari e i test dell'applicazione sul codice dell'applicazione.
  • Esegue scanner di codice statici sui repository delle applicazioni per individuare vulnerabilità di sicurezza nel codice sorgente.
  • Esegue controlli di conformità utilizzando strumenti di analisi come Code Risk Analyzer su tutti i repository delle applicazioni, inclusa l'analisi delle vulnerabilità e la verifica della distinta base (BOM) su tutte le dipendenze dei pacchetti.
  • Raccoglie i dati di conformità relativi alle revisioni tra pari per tutte le richieste di pull integrate dall'ultima build.
  • Crea un'immagine del container ad ogni commit su Git, assegnando un tag basato sul numero di build, sul timestamp e sull'ID del commit per garantire la tracciabilità.
  • Firma l'immagine del container creata.
  • Esegue una scansione dell'immagine del container alla ricerca di vulnerabilità di sicurezza.
  • Distribuisce l'artefatto compilato in un ambiente di sviluppo ed esegue una scansione dinamica (scansioni tramite API e interfaccia utente di ZAP) sull'applicazione in esecuzione per individuare eventuali vulnerabilità di runtime.
  • Esegue i test di accettazione e di integrazione sull'artefatto distribuito nell'ambiente di sviluppo.
  • Al termine di ogni esecuzione della pipeline, raccoglie tutte le prove (risultati delle scansioni, risultati dei test, registri, dati delle revisioni tra pari e dati relativi all'esecuzione della pipeline) in un archivio delle prove.

Migliori pratiche per l'integrazione continua (CI) nella catena di strumenti dell'infrastruttura come codice ( IaC )

La catena di strumenti " DevSecOps " per " IaC " segue queste pratiche:

  • Esegue il comando detect-secrets sui repository IaC per prevenire la fuga di informazioni riservate nella configurazione di Terraform.
  • Esegue i test unitari sulla configurazione IaC ad ogni commit su Git.
  • Esegue una scansione statica del codice sui repository IaC, utilizzando strumenti specifici per Terraform quali tflint per il linting e l’applicazione delle best practice, nonché terraform fmt e terraform validate per garantire la coerenza della formattazione e la validità della configurazione.
  • Esegue controlli di conformità sui repository di IaC utilizzando gli strumenti di IaC-specific (come Code Risk Analyzer o checkov) per individuare eventuali problemi di conformità.
  • Crea un file Tar contenente la configurazione di Terraform ad ogni commit su Git.
  • Firma l'artefatto Tar generato.
  • Distribuisce la configurazione di IaC in un ambiente di sviluppo utilizzando IBM Cloud Schematics o la CLI di Terraform.
  • Esegue i test di accettazione e di integrazione sulla configurazione implementata nell'ambiente di sviluppo.
  • Aggiunge gli artefatti generati al repository dell'inventario per garantirne la tracciabilità e la distribuzione agli ambienti a valle.
  • Al termine di ogni esecuzione della pipeline, raccoglie tutte le prove (risultati delle scansioni, risultati dei test, dati di firma, registri e dati relativi all'esecuzione della pipeline) in un archivio delle prove.

Migliori pratiche per la catena di strumenti di distribuzione continua (CD) finalizzata alla distribuzione di un’applicazione sicura

Per distribuire un'applicazione sicura, la catena di strumenti CD di DevSecOps segue queste procedure:

  • Utilizza una pull request di promozione sul repository dell'inventario per definire l'ambito della distribuzione e calcolare il delta della distribuzione, ovvero l'insieme degli artefatti che sono stati modificati dall'ultima distribuzione completata.
  • Verifica che tutte le richieste di pull nell'ambito dell'attuale distribuzione siano state sottoposte a revisione tra pari e approvate prima di procedere. Blocca l'implementazione se una qualsiasi pull request non è stata approvata.
  • Verifica che ogni artefatto la cui distribuzione è prevista sia correttamente firmato. Blocca l'implementazione se manca una firma valida.
  • Calcola la distinta base (BOM) della distribuzione a partire dal delta della distribuzione e raccoglie un riepilogo delle prove sia dall'esecuzione della pipeline CI associata sia dall'esecuzione corrente della pipeline CD.
  • Crea una richiesta di modifica nel sistema di gestione delle modifiche configurato e allega la distinta base di implementazione, il riepilogo delle prove e i dati relativi alla conformità alla revisione tra pari.
  • Approva automaticamente la richiesta di modifica se tutti i criteri di conformità sono soddisfatti. Supporta l'approvazione manuale o l'assegnazione di tag di emergenza quando i criteri non sono pienamente soddisfatti.
  • Distribuisce gli artefatti dall'inventario all'ambiente di destinazione (ad esempio, l'ambiente di staging o quello di produzione) una volta che la richiesta di modifica è stata approvata o contrassegnata come urgente.
  • Esegue i test di accettazione e di integrazione dopo la distribuzione per verificare che la distribuzione sia andata a buon fine e che l'applicazione funzioni come previsto.
  • Se si verifica un errore durante la fase di distribuzione o di test di accettazione, esegue automaticamente il rollback della distribuzione nell'ambito della stessa esecuzione della pipeline, mantenendo nell'inventario l'ultimo stato corretto conosciuto.
  • Chiude la richiesta di modifica con un " close_category " (Richiesta di modifica) di tipo " Successful " o " Successful with issues" e sposta il tag di inventario " <target-environment>_latest " sul commit distribuito.
  • Al termine di ogni esecuzione della pipeline, raccoglie e carica tutti i file di log, gli artefatti e le prove nell'archivio delle prove.
  • Facoltativamente, assegna alle pull request unite l'etichetta " deploy:{region}:{env} " dopo una distribuzione riuscita, per garantire la tracciabilità end-to-end della distribuzione senza richiedere l'accesso ai dettagli della pipeline.

Migliori pratiche per la catena di strumenti dedicata alla conformità continua (CC)

La catena di strumenti CC di DevSecOps segue queste pratiche:

  • Esegue detect-secrets su tutti i repository di codice sorgente dell'inventario per individuare eventuali fughe di informazioni riservate nel codice sorgente dell'applicazione.
  • Esegue una scansione statica del codice ( SonarQube o un'implementazione personalizzata) su tutti i repository di codice sorgente presenti nell'inventario.
  • Esegue una scansione dinamica per il test della sicurezza dell'applicazione (OWASP ZAP) sull'applicazione distribuita, al fine di individuare eventuali vulnerabilità in fase di esecuzione.
  • Esegue controlli di conformità utilizzando strumenti (come Code Risk Analyzer) su tutti i repository di origine presenti nell'inventario, inclusi la scansione delle vulnerabilità, i controlli " CIS " sui manifesti di distribuzione di Kubernetes, i controlli BOM su tutte le dipendenze dei pacchetti e la verifica della protezione dei rami.
  • Esegue la scansione di tutte le immagini dei container distribuite alla ricerca di vulnerabilità di sicurezza.
  • Crea o aggiorna le segnalazioni relative a ogni singolo CVE, vulnerabilità o avviso rilevato durante l'esecuzione della pipeline e assegna una data di scadenza a ciascuna segnalazione.
  • Raccoglie le prove relative a ciascuna fase nell'archivio delle prove, allega i risultati della scansione e della verifica alle segnalazioni corrispondenti e aggiorna lo stato di conformità di tutti gli artefatti sottoposti a scansione.