Utilizzo dello strumento di scansione delle vulnerabilità Snyk

Tutorial
Kubernetes

Introduzione

Snyk è stato progettato per servire come piattaforma di sicurezza per sviluppatori e con flessibilità in mente. Il suo obiettivo principale è aiutarti a rilevare e correggere le vulnerabilità nel codice sorgente dell’applicazione, nelle dipendenze di terze parti, nelle immagini dei contenitori e nei file di configurazione dell’infrastruttura (ad es. Kubernetes, Terraform, ecc.).

Snyk è diviso in quattro componenti:

  1. Snyk Code – ti aiuta a trovare e correggere le vulnerabilità nel codice sorgente dell’applicazione.
  2. Snyk Open Source – ti aiuta a trovare e correggere le vulnerabilità per qualsiasi libreria o dipendenza di terze parti su cui si basa la tua applicazione.
  3. Snyk Container – ti aiuta a trovare e correggere le vulnerabilità nelle immagini dei contenitori o nei carichi di lavoro di Kubernetes utilizzati nel tuo cluster.
  4. Snyk Infrastructure as Code – ti aiuta a trovare e correggere le errate configurazioni nei manifesti di Kubernetes (Terraform, CloudFormation e Azure sono supportati anche).

Snyk può essere eseguito in modi diversi:

  • Tramite l’interfaccia della riga di comando utilizzando Snyk CLI. Questo è il modo preferito per eseguirlo all’interno di script e varie automazioni, inclusi i pipeline CI/CD.
  • Nel browser come Snyk Web UI. Snyk offre anche una piattaforma basata su cloud che puoi utilizzare per esaminare i report di scansione, ricevere suggerimenti e prendere le azioni necessarie per risolvere i problemi segnalati, ecc. Puoi anche collegare i repository GitHub e eseguire scansioni/audit dall’interfaccia web.
  • Attraverso plugin IDE. In questo modo puoi individuare i problemi in anticipo mentre stai sviluppando utilizzando il tuo IDE preferito (ad esempio Visual Studio Code).
  • Programmaticamente, tramite API Snyk. L’API Snyk è disponibile per i clienti con piani a pagamento e consente di integrarsi con Snyk in modo programmato.

Snyk è gratuito?

Sì, lo strumento è gratuito, tranne l’API Snyk e alcune funzionalità avanzate dell’interfaccia web (come i report avanzati). Vi è inoltre un limite sul numero di test che puoi eseguire al mese.

Vedi i piani tariffari per ulteriori informazioni.

Snyk è open source?

Sì, sicuramente lo sono lo strumento e Snyk CLI. Puoi visitare la pagina principale di Snyk su GitHub per trovare maggiori dettagli sull’implementazione di ciascun componente. Il portale cloud e tutte le funzionalità a pagamento, come l’implementazione dell’API rest, non sono open source.

Un altro importante insieme di concetti che Snyk sta utilizzando sono Targets e Progetti.

I Target rappresentano una risorsa esterna che Snyk ha analizzato tramite un’integrazione, la CLI, l’interfaccia utente o l’API. Esempi di target sono un repository SCM, un carico di lavoro Kubernetes, ecc.

I Progetti, d’altra parte, definiscono gli elementi che Snyk analizza in un determinato Target. Un progetto include:

  • A scannable item external to Snyk.
  • Configurazione per definire come eseguire quella scansione.

Puoi leggere di più sui concetti principali di Snyk qui.

In questa guida utilizzerai Snyk CLI per eseguire un’analisi del rischio per la catena di approvvigionamento delle tue applicazioni Kubernetes (immagini di container, manifesti YAML di Kubernetes). Successivamente, imparerai come prendere le misure appropriate per rimediare alla situazione. Infine, imparerai come integrare Snyk in un pipeline CI/CD per eseguire la scansione delle vulnerabilità nelle prime fasi di sviluppo.

Tabella dei Contenuti

Prerequisiti

Per completare tutti i passaggi di questa guida, avrai bisogno di:

  1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
  2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
  3. Kubectl CLI per l’interazione con Kubernetes. Segui queste istruzioni per connetterti al tuo cluster con kubectl e doctl.
  4. Snyk CLI per interagire con lo scanner di vulnerabilità Snyk.
  5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
  6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

Passaggio 1 – Conoscere la CLI di Snyk

È possibile eseguire la scansione manuale delle vulnerabilità tramite l’interfaccia a riga di comando snyk. La CLI di Snyk è progettata per essere utilizzata in vari script e automazioni. Un esempio pratico è in un pipeline CI/CD implementata utilizzando vari strumenti come Tekton, Jenkins, GitHub Workflows, ecc.

Quando la CLI di Snyk viene invocata, avvierà immediatamente il processo di scansione e riporterà problemi in un formato specifico. Per impostazione predefinita, stampa una tabella riassuntiva utilizzando l’output standard o la console. Snyk può generare report anche in altri formati, come JSON, HTML, SARIF, ecc.

Puoi scegliere di inviare i risultati al Portale Cloud di Snyk (o interfaccia web) tramite il flag --report per memorizzare e visualizzare successivamente i risultati della scansione.

Nota:
Non è obbligatorio inviare i risultati della scansione al portale cloud di Snyk. Il grande vantaggio nell’utilizzare il portale Snyk è la visibilità perché ti dà accesso a un bel cruscotto dove puoi controllare tutti i report di scansione e vedere quanto è influenzata la catena di approvvigionamento di Kubernetes. Ti aiuta anche nel lungo termine con indagini e suggerimenti per la risoluzione dei problemi.

La CLI di Snyk è divisa in diversi sotto-comandi. Ogni sotto-comando è dedicato a una funzionalità specifica, come:

Prima di procedere, assicurati di creare un account gratuito utilizzando l’interfaccia web di Snyk. Inoltre, la CLI di Snyk deve essere autenticata anche con il tuo account cloud affinché alcuni comandi/sottocomandi funzionino (ad es. snyk code test).

A few examples to try with Snyk CLI:

  1. Scansione open source:
# Scansiona il codice del tuo progetto dalla directory corrente
snyk test
# Scansiona un percorso specifico dalla directory del tuo progetto (assicurati di sostituire i segnaposto `<>` di conseguenza)
snyk test <path/to/dir>
  1. Scansione del codice:
# Scansiona il codice del tuo progetto dalla directory corrente
snyk code test

# Scansiona un percorso specifico dalla directory del tuo progetto (assicurati di sostituire i segnaposto `<>` di conseguenza)
snyk code test <path/to/dir>
  1. Scansione delle immagini:
# Scansiona l'immagine Docker di debian effettuando prima il pull
snyk container debian

# Fornisci ulteriore contesto al scanner fornendo un Dockerfile (assicurati di sostituire i segnaposto `<>` di conseguenza)
snyk container debian --file=<path/to/dockerfile>
  1. Scansione dell’infrastruttura come codice:
# Scansiona il codice del tuo progetto dalla directory corrente
snyk iac test

# Scansiona un percorso specifico dalla directory del tuo progetto (assicurati di sostituire i segnaposto `<>` di conseguenza)
snyk iac test <path/to/dir>

# Scansione dei progetti basati su Kustomize (prima è necessario renderizzare il template finale, quindi passarlo allo scanner)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Il CLI di Snyk fornisce pagine di aiuto per tutte le opzioni disponibili. Il comando seguente può essere utilizzato per stampare la pagina di aiuto principale:

snyk --help

L’output appare simile a:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

Ogni comando (o sotto-comando) del CLI di Snyk ha anche una pagina di aiuto associata, a cui si può accedere tramite snyk [comando] --help.

Per ulteriori esempi, visita la pagina ufficiale della documentazione del CLI di Snyk.

Passaggio 2 – Conoscere l’interfaccia utente Web di Snyk

Dopo aver registrato un account Snyk, autenticati e accedi a Snyk, l’interfaccia utente Web si apre al Dashboard, con una procedura guidata per aiutarti nei passaggi di configurazione:

  • Identificare dove si trova il codice che si desidera monitorare in Snyk.
  • Definire quali progetti all’interno del tuo codice vuoi che Snyk scansioni.
  • Collegare Snyk ai progetti rilevanti per scansionarli.
  • Esaminare i risultati della scansione Snyk.

Le seguenti funzionalità sono disponibili tramite l’interfaccia web:

Visita la pagina della documentazione ufficiale per saperne di più sull’interfaccia utente web di Snyk.

Comprensione dei Livelli di Severità di Snyk

In ogni scansione, snyk verifica le tue risorse per potenziali rischi di sicurezza e come ognuno di essi influisce sul tuo sistema. Viene applicato un livello di severità a una vulnerabilità per indicare il rischio che essa rappresenta in un’applicazione.

I livelli di severità possono assumere uno dei seguenti valori:

  • Basso: l’applicazione potrebbe esporre alcuni dati consentendo il mapping delle vulnerabilità, che può essere utilizzato con altre vulnerabilità per attaccare l’applicazione.
  • Medio: potrebbe consentire agli attaccanti, in alcune condizioni, di accedere a dati sensibili sulla tua applicazione.
  • Alto: potrebbe consentire agli attaccanti di accedere a dati sensibili sulla tua applicazione.
  • Cruciale: potrebbe consentire agli attaccanti di accedere a dati sensibili ed eseguire codice sulla tua applicazione.

Il Sistema di Punteggio delle Vulnerabilità Comuni (CVSS) determina il livello di gravità di una vulnerabilità. Snyk utilizza il framework CVSS versione 3.1 per comunicare le caratteristiche e la gravità delle vulnerabilità.

La tabella sottostante mostra la corrispondenza di ogni livello di gravità:

Severity level CVSS score
Low 0.0 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.10

In questa guida, viene utilizzato il livello medio come valore predefinito nell’esempio del pipeline CI/CD in uso. Di solito, si desidera valutare prima le problematiche di alto e critico livello, ma in alcuni casi anche il livello medio richiede attenzione. In termini di sicurezza e come regola generale, di solito si desidera essere molto rigorosi.

Si prega di visitare la pagina ufficiale della documentazione per saperne di più sui livelli di gravità.

Rimedio Assistito per Problemi di Sicurezza Segnalati

Un’altra funzionalità utile fornita dall’interfaccia utente web di Snyk è l’assistenza alla risoluzione dei problemi di sicurezza. Significa che ricevi una raccomandazione su come risolvere ciascun problema di sicurezza individuato dallo scanner snyk. Questo è molto importante perché semplifica il processo e chiude il cerchio per ogni iterazione che è necessario eseguire per risolvere ciascun problema di sicurezza segnalato.

La figura sottostante illustra meglio questo processo:

Per ogni problema segnalato, c’è un pulsante su cui puoi fare clic per ottenere assistenza per la risoluzione:

La procedura principale è la stessa per ogni problema segnalato. Significa che fai clic sul pulsante Mostra dettagli, quindi segui i passaggi suggeriti per applicare la correzione.

Passaggio 3 – Utilizzo di Snyk per eseguire la scansione delle vulnerabilità della configurazione di Kubernetes in un pipeline CI/CD

Come beneficia dall’incorporare uno strumento di scansione della conformità alla sicurezza nel suo pipeline CI/CD e evitare situazioni spiacevoli in un ambiente di produzione?

Tutto inizia al livello fondamentale, dove inizia lo sviluppo del software. In generale, vorrai utilizzare un ambiente dedicato per ogni fase. Quindi, nelle prime fasi dello sviluppo quando il codice dell’applicazione cambia molto spesso, dovresti utilizzare un ambiente di sviluppo dedicato (chiamato solitamente ambiente inferiore). Successivamente, l’applicazione viene affinata sempre di più nell’ambiente di QA, dove i team di QA eseguono test manuali e/o automatizzati. Successivamente, se l’applicazione ottiene l’approvazione del team di QA, viene promossa agli ambienti superiori, come la fase di staging, e infine in produzione. In questo processo, in cui l’applicazione viene promossa da un ambiente all’altro, viene eseguito un pipeline dedicato, che esamina continuamente gli artefatti dell’applicazione e ne controlla il livello di gravità. Se il livello di gravità non raggiunge una soglia specifica, il pipeline fallisce immediatamente e la promozione degli artefatti dell’applicazione in produzione viene interrotta nelle prime fasi.

Quindi, lo strumento di scansione della sicurezza (ad esempio, snyk) agisce come guardiano che ferma gli artefatti indesiderati dall’entrare nel tuo ambiente di produzione dalle prime fasi dello sviluppo. Allo stesso modo, i pipeline degli ambienti superiori utilizzano snyk per consentire o vietare agli artefatti dell’applicazione di entrare nella fase finale di produzione.

Implementazione del flusso di lavoro CI/CD di GitHub Actions

In questo passaggio, imparerai come creare e testare un esempio di pipeline CI/CD con scansione delle vulnerabilità integrata tramite flussi di lavoro di GitHub. Per apprendere i fondamenti dell’utilizzo delle Azioni di GitHub con DigitalOcean Kubernetes, consulta questo tutorial.

La pipeline fornita nella sezione seguente costruisce e distribuisce l’applicazione game-2048-example dal repository kubernetes-sample-apps di DigitalOcean.

A livello di panoramica generale, il workflow CI/CD di game-2048 fornito nel repository kubernetes-sample-apps è composto dalle seguenti fasi:

  1. Fase di costruzione e test dell’applicazione – costruisce gli artefatti principali dell’applicazione e esegue test automatizzati.
  2. Fase di scansione dell’immagine dell’applicazione Snyk – esegue la scansione dell’immagine docker dell’applicazione per le vulnerabilità conosciute. Agisce come un cancello, e lo stato finale della pipeline (pass/fail) dipende da questo passaggio. In caso di fallimento, viene inviata una notifica Slack.
  3. Fase di costruzione e push dell’immagine dell’applicazione – costruisce e contrassegna l’immagine dell’applicazione utilizzando l’ultimo SHA del commit git. Successivamente, l’immagine viene spinta su DOCR.
  4. Fase di scansione dell’infrastruttura come codice (IAC) di Snyk: esegue scansioni per le vulnerabilità conosciute nei manifesti YAML di Kubernetes associati all’applicazione. Agisce come un cancello, e lo stato finale del pipeline (pass/fail) dipende da questo passaggio. In caso di fallimento, viene inviata anche una notifica su Slack.
  5. Fase di distribuzione dell’applicazione: distribuisce l’applicazione su Kubernetes (DOKS).

Il diagramma seguente illustra ogni lavoro del pipeline e i passaggi associati con azioni (viene mostrata solo la configurazione rilevante):

Note:

  • Nel caso di progetti basati su kustomize, è meglio renderizzare il manifesto finale per catturare e scansionare tutto (inclusie risorse remote). D’altro canto, può essere difficile identificare quale risorsa di Kubernetes debba essere aggiornata. Questo è dovuto al fatto che il file manifesto risultante è composto da tutte le risorse da applicare. Così funziona kustomize: raccoglie tutti i frammenti di configurazione da ogni sovrapposizione e li applica su una base per costruire il composto finale.
  • Puoi anche dire a Snyk di scansionare l’intera cartella dove conservi le tue configurazioni kustomize. In questo modo, è più facile identificare quale risorsa deve essere corretta nel tuo repository. Le risorse remote utilizzate da kustomize devono essere corrette a monte. Inoltre, i segreti di Kubernetes e i ConfigMaps generati tramite kustomize non vengono catturati.

Come si può far fallire il pipeline se non viene soddisfatto un certo livello di conformità alla sicurezza?

Il CLI di Snyk fornisce un flag chiamato --severity-threshold a questo scopo. Questo flag è correlato al livello di gravità complessivo calcolato dopo ogni scansione. Nel caso di Snyk, il livello di gravità assume uno dei seguenti valori: basso, medio, alto, o critico. Puoi far fallire o superare il pipeline in base al valore del livello di gravità e interrompere il rilascio dell’applicazione se le condizioni non sono soddisfatte.

La seguente immagine illustra il flusso per il pipeline CI/CD di esempio utilizzato in questa guida:

Si prega di seguire i passaggi seguenti per creare e testare il workflow GitHub CI/CD di Snyk fornito nel repository GitHub kubernetes-sample-apps:

  1. Fai il fork del repository GitHub kubernetes-sample-apps.
  2. Creare le seguenti secrets crittografate di GitHub per la tua copia kubernetes-sample-apps (Tab Impostazioni -> Segreti -> Azioni):
    • DIGITALOCEAN_ACCESS_TOKEN – contiene il token del tuo account DigitalOcean.
    • DOCKER_REGISTRY – contiene il nome del registro Docker di DigitalOcean, incluso l’endpoint (ad esempio registry.digitalocean.com/sample-apps).
    • DOKS_CLUSTER – contiene il nome del tuo cluster DOKS. Puoi eseguire il seguente comando per ottenere il nome del tuo cluster DOKS: doctl k8s cluster list --no-header --format Name.
    • SNYK_TOKEN – contiene l’ID dell’account utente di Snyk – esegui: snyk config get api per ottenere l’ID. Se questo non funziona, puoi recuperare il token dalla pagina delle impostazioni dell’account utente.
    • SLACK_WEBHOOK_URL – contiene l’URL del webhook in arrivo di Slack utilizzato per le notifiche della scansione Snyk.
  3. Naviga nella scheda Azioni del tuo repo forkato e seleziona il flusso di lavoro Esempio CI/CD Snyk del gioco 2048:
  4. Fai clic sul pulsante Esegui flusso di lavoro e lascia i valori predefiniti:

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

Il processo verrà interrotto quando viene eseguito il lavoro controllo di sicurezza del container snyk. Questo è previsto perché il valore predefinito del livello di gravità utilizzato nell’input del flusso di lavoro, che è medio, non soddisfa le aspettative. Dovresti anche ricevere una notifica Slack con i dettagli sull’esecuzione del flusso di lavoro:

Nei prossimi passaggi, imparerai come investigare il rapporto di scansione di snyk per risolvere i problemi, abbassare il livello di gravità e far superare il processo.

Passaggio 4 – Investigare i risultati della scansione Snyk e correggere i problemi segnalati

Quando la soglia del livello di gravità non viene raggiunta, il flusso di lavoro di GitHub per game-2048 fallirà e verrà inviata una notifica su Slack con ulteriori dettagli. Vengono inoltre pubblicati rapporti sulla sicurezza su GitHub e sono accessibili nella scheda Sicurezza del repository del progetto.

Il flusso di lavoro per game-2048 esegue due controlli di sicurezza:

  1. Controlli di sicurezza dell’immagine del contenitore – il lavoro verifica-sicurezza-contenitore-snyk viene utilizzato per questo scopo. Il comando snyk equivalente utilizzato è – snyk container test <IMMAGINE-GAME-2048>:<TAG> --file=/percorso/a/game-2048/Dockerfile.
  2. Controlli sulla configurazione errata dei manifesti di Kubernetes – il lavoro verifica-sicurezza-iac-snyk viene utilizzato per questo scopo. Il comando snyk equivalente utilizzato è – snyk iac test /percorso/a/progetto/kubernetes/manifests.

Quindi, abbassare il livello di gravità e superare il flusso di lavoro consiste in:

  1. Investigare e correggere i problemi segnalati dal lavoro verifica-sicurezza-contenitore-snyk.
  2. Investigare e correggere i problemi segnalati dal lavoro verifica-sicurezza-iac-snyk.

Successivamente, imparerai come affrontare ciascuno di essi.

Indagine e Risoluzione delle Vulnerabilità delle Immagini dei Container

Il pipeline di esempio utilizzato in questa guida esegue controlli di sicurezza per l’immagine del container game-2048 e il relativo Dockerfile tramite il lavoro snyk-container-security-check.

Il lavoro snyk-container-security-check esegue i seguenti passaggi:

  1. Costruisce localmente l’immagine Docker dell’applicazione game-2048. Questo passaggio è implementato utilizzando l’azione GitHub docker-build-push.
  2. Esegue i controlli di sicurezza Snyk per l’immagine del container dell’applicazione e il Dockerfile. Questo passaggio è implementato utilizzando il comando snyk container test. I risultati della scansione sono esportati utilizzando il formato GitHub SARIF. Il livello di sicurezza soglia è controllato tramite l’argomento –severity-threshold – viene impostato sul parametro di input snyk_fail_threshold se il flusso di lavoro viene attivato manualmente, oppure sulla variabile d’ambiente SNYK_FAIL_THRESHOLD se il flusso di lavoro viene eseguito automaticamente.
  3. I risultati della scansione (formato SARIF) vengono pubblicati nella scheda sicurezza del repository dell’applicazione. Questo passaggio è implementato utilizzando l’azione GitHub codeql.

Il frammento seguente mostra la logica principale del lavoro snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

Per risolvere i problemi segnalati, è necessario controllare prima la scheda sicurezza del fork del repository kubernetes-sample-apps:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Vedrai una serie di vulnerabilità per l'immagine Docker di base in questo caso. Fai clic su ciascuna per espandere e vedere più dettagli:
Per completare le indagini e vedere le raccomandazioni offerte da Snyk, è necessario ispezionare l'output del lavoro snyk-container-security-check dal flusso di lavoro principale:
Nota:Il test del container Snyk offre la possibilità di esportare i risultati nel formato SARIF, ma non sa come caricare i report sul portale cloud di Snyk. D'altra parte, il monitoraggio del container Snyk offre la possibilità di caricare i risultati sul portale cloud di Snyk, ma non può esportare SARIF. Quindi questa guida utilizza il test del container Snyk con la funzionalità di esportazione SARIF. Purtroppo, alcune raccomandazioni non sono disponibili nell'output SARIF. Quindi, è necessario guardare anche nell'output della console del lavoro per le raccomandazioni.
Il risultato del lavoro snyk-container-security-check mostra che Snyk consiglia di aggiornare la versione dell'immagine di base da node:16-slim a node:18.6.0-slim. Questo cambiamento elimina il(i) problema(i) ad alto rischio e riduce anche il numero di altre vulnerabilità segnalate da 70 a 44 - si tratta di una riduzione sostanziale di quasi il 50%!!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

Ora, apri il Dockerfile dell’applicazione game-2048 dal tuo fork e cambia le direttive FROM in modo che puntino alla nuova versione (node:18.6.0-slim al momento della scrittura):

#

# La modalità di compilazione può essere impostata tramite la variabile d’ambiente NODE_ENV (sviluppo o produzione)

# Vedi il package.json e webpack.config.js del progetto

#

Infine, effettua il commit delle modifiche nel tuo repository GitHub e attiva nuovamente il flusso di lavoro (mantenendo i valori predefiniti). Questa volta il lavoro snyk-container-security-check dovrebbe superare:

Andando nella scheda di sicurezza del tuo progetto, non dovrebbero essere segnalati problemi.

Come ti assicuri di ridurre le vulnerabilità dell’immagine di base in futuro?

  1. Il miglior approccio è utilizzare un’immagine di base con un’impronta minima: meno binari o dipendenze nell’immagine di base, meglio è. Un’altra buona pratica è monitorare continuamente i tuoi progetti, come spiegato nella sezione Monitora i tuoi Progetti su Base Regolare di questa guida.
  2. Noterai che il flusso di lavoro fallisce ancora, ma questa volta nella fase snyk-iac-security-check. Questo è previsto perché ci sono problemi di sicurezza con i manifesti Kubernetes utilizzati per distribuire l’applicazione. Nella prossima sezione, imparerai come indagare su questa situazione e applicare le raccomandazioni di sicurezza di Snyk per risolvere i problemi segnalati.

Indagare e Risolvere le Vulnerabilità dei Manifesti Kubernetes

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

Il flusso di lavoro continua a fallire e si interrompe nel lavoro snyk-iac-security-check. Questo è previsto perché il valore predefinito del livello di gravità utilizzato nell’input del flusso di lavoro, che è medio, non soddisfa i requisiti di sicurezza per il progetto.

  1. Il lavoro snyk-iac-security-check controlla le vulnerabilità (o le errate configurazioni) dei manifesti Kubernetes e esegue i seguenti passaggi:
  2. I controlli di sicurezza di Snyk per i manifesti di Kubernetes dalla directory del progetto game-2048-example. Questo passaggio è implementato utilizzando il comando snyk iac test. I risultati della scansione vengono esportati utilizzando il formato GitHub SARIF. La soglia del livello di sicurezza è controllata tramite l’argomento –severity-threshold – è impostata sul parametro di input snyk_fail_threshold se il flusso di lavoro viene attivato manualmente, o sulla variabile d’ambiente SNYK_FAIL_THRESHOLD se il flusso di lavoro viene eseguito automaticamente. Infine, viene utilizzato anche l’argomento –report per inviare i risultati della scansione al portale cloud di Snyk.

I risultati della scansione (formato SARIF) vengono pubblicati nella scheda di sicurezza del repository dell’applicazione. Questo passaggio è implementato utilizzando l’azione GitHub codeql.

Di seguito viene mostrata l’implementazione effettiva di ciascun passaggio dal lavoro snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

Per risolvere i problemi segnalati hai due opzioni:

  • Utilizza il portale cloud di Snyk e accedi al progetto game-2048 per verificare i dettagli:
  • Utilizza la scheda di sicurezza del repository della tua app di gioco 2048 per controllare i dettagli:
  • In ogni caso, riceverai raccomandazioni su come risolvere i problemi segnalati.
  • Per questa guida, utilizzerai il portale cloud di Snyk per indagare sui problemi di sicurezza segnalati. Innanzitutto, clicca sull’ingresso game-2048-example dall’elenco dei progetti, quindi seleziona il file kustomize/resources/deployment.yaml:

Successivamente, spunta la casella di controllo Media nel menu Severità a sinistra per visualizzare solo problemi di livello medio:

Quindi, puoi ispezionare ogni scheda di problema segnalato e controllare i dettagli. Vai avanti e clicca sul pulsante Mostra altri dettagli dalla scheda Il contenitore viene eseguito senza controllo dell’utente root – riceverai ulteriori dettagli sul problema attuale e importanti suggerimenti su come risolverlo:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

  1. Dopo aver raccolto tutte le informazioni da ciascuna scheda, puoi procedere ed modificare il file deployment.yaml dal tuo repo (posizionato nella sotto-cartella game-2048-example/kustomize/resources). Le correzioni sono già state apportate, devi solo rimuovere i commenti dalle ultime righe del file. Il file deployment.yaml finale dovrebbe apparire come segue:
  2. readOnlyRootFilesystem – esegue l’immagine del container in sola lettura (non è possibile modificare i file tramite kubectl exec nel container).

allowPrivilegeEscalation – impostando allowPrivilegeEscalation su false si assicura che nessun processo figlio di un container possa ottenere più privilegi rispetto al suo genitore.

capabilities.drop – Per rendere i container più sicuri, è consigliabile fornire loro il minor numero possibile di privilegi necessari per l’esecuzione. In pratica, si elimina tutto per impostazione predefinita, quindi si aggiungono gradualmente le capacità richieste. Puoi saperne di più sulle capacità dei container qui.

Infine, esegui il commit delle modifiche per il file deployment.yaml e fai push sul branch principale. Dopo aver attivato manualmente il workflow, dovrebbe completarsi correttamente questa volta:

Dovresti anche ricevere una notifica Slack verde dal lavoro di scansione snyk. Accedi al link del portale Snyk e controlla se i problemi che hai risolto di recente sono scomparsi – non dovrebbero essere segnalati problemi di livello medio.

Verifica se il deployment di game-2048 ha un filesystem in sola lettura (immutabile) tentando di scrivere sul file index.html utilizzato dall’applicazione game-2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

L’output è simile a:

Output
/bin/bash: /public/index.html: Sistema di file in sola lettura
command terminato con codice di exit 1

Verifica se il deployment di game-2048 ha un filesystem in sola lettura (immutabile) tentando di scrivere sul file index.html utilizzato dall’applicazione game-2048:

L’output è simile a:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

Controlla se il contenitore viene eseguito come utente non root (dovrebbe stampare un numero intero diverso da zero – ad esempio, 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

Controlla se il contenitore viene eseguito come utente non root (dovrebbe stampare un numero intero diverso da zero – ad esempio, 1000):

Se tutti i controlli passano, hai applicato con successo le raccomandazioni di sicurezza richieste.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Monitora i tuoi progetti regolarmente

L’automazione della scansione delle vulnerabilità che hai implementato finora è un buon punto di partenza ma non è perfetto. Perché?

Un problema con l’approccio attuale è che non si sa mai quando vengono segnalati nuovi problemi per le risorse che hai già distribuito nei tuoi ambienti. In altre parole, hai valutato i rischi per la sicurezza e hai preso le misure per risolvere i problemi in un punto specifico nel tempo – quando è stata eseguita l’automazione CI/CD.

Ma cosa succede se nel frattempo vengono segnalati nuovi problemi e la tua applicazione è di nuovo vulnerabile? Snyk ti aiuta a superare questa situazione tramite la funzione monitoraggio. La funzione di monitoraggio di Snyk ti aiuta ad affrontare nuove vulnerabilità, che vengono costantemente rivelate. Quando combinato con l’integrazione di Snyk in Slack (spiegato in Passo 6 – Abilitare le Notifiche Slack), puoi prendere azioni immediate per risolvere i problemi appena divulgati che potrebbero influenzare la tua applicazione in un ambiente di produzione.

Per beneficiare di questa funzione, tutto ciò che devi fare è usare il comando snyk monitor prima di qualsiasi passaggio di deploy nel tuo pipeline CI/CD. La sintassi è molto simile ai comandi snyk test (una delle cose interessanti della CLI di snyk è che è stata progettata con uniformità in mente). Il comando snyk monitor invierà uno snapshot al portale cloud di Snyk, e da lì verrai notificato sulle nuove vulnerabilità divulgate per il tuo progetto.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

Per quanto riguarda l’automazione del flusso di lavoro di GitHub, puoi eseguire il monitoraggio della tua applicazione container nel lavoro snyk-container-security-check, dopo aver testato le vulnerabilità. Il seguente frammento mostra un’implementazione pratica per il pipeline utilizzato in questa guida (alcuni passaggi sono stati omessi per chiarezza):

  1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
  2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
  3. –target-name=${{ env.PROJECT_NAME }} \
  4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

Il frammento sopra mostra un passaggio aggiuntivo chiamato Monitora il container dell’applicazione usando Snyk dove effettivamente viene eseguito il monitoraggio del container di Snyk.

Dopo l’esecuzione del comando di monitoraggio di Snyk, puoi accedere all’interfaccia utente Web di Snyk per vedere l’ultima snapshot e la cronologia del tuo progetto:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

Puoi testare e monitorare anche il codice sorgente dell’applicazione nel lavoro build-and-test-application. Di seguito viene mostrata un’implementazione di esempio per il flusso di lavoro di GitHub utilizzato in questa guida:

In seguito, riceverai notifiche Slack su base regolare riguardanti le vulnerabilità appena divulgate per il tuo progetto.

Gestione delle eccezioni

Ci sono situazioni in cui non vuoi che il report finale venga influenzato da alcuni problemi che il tuo team considera sicuri da ignorare. Snyk offre una funzionalità integrata per gestire le eccezioni e superare questa situazione.

Puoi leggere ulteriori informazioni su questa funzione qui.

Snyk per IDE

Snyk offre supporto per una varietà di IDE, come:

Plugin Eclipse.

Plugin JetBrains.

  • Estensione Visual Studio.
  • Estensione Visual Studio Code.
  • I plugin sopra elencati ti aiuteranno a individuare e risolvere problemi nelle fasi iniziali dello sviluppo, eliminando così frustrazioni, costi e difetti di sicurezza nei sistemi in produzione. Inoltre, ti aiuta a ridurre le iterazioni e lo sforzo umano nel lungo periodo. Ad esempio, per ogni problema di sicurezza segnalato dalla tua automazione CI/CD è necessario tornare indietro e risolvere il problema nel tuo codice, fare commit delle modifiche, attendere nuovamente l’automazione CI/CD e ripetere in caso di fallimento.
  • Dalla documentazione ufficiale, puoi leggere ulteriori informazioni su queste funzionalità sulla pagina Snyk per IDE.
  • Passaggio 5 – Attivazione automatica del flusso di lavoro Snyk CI/CD
  • Puoi impostare il flusso di lavoro per essere attivato automaticamente su ogni commit o PR contro il branch principale, decommentando le seguenti righe all’inizio del file game-2048-snyk.yaml:
  • Dopo aver modificato il file, esegui il commit delle modifiche sul tuo branch principale e dovresti essere pronto a procedere.
  • Passaggio 6 – Abilitazione delle notifiche Slack
  • Puoi configurare Snyk per inviare avvisi Slack riguardanti nuove vulnerabilità scoperte nei tuoi progetti e riguardanti nuovi aggiornamenti o patch disponibili.
  • Per configurarlo, dovrai generare un webhook Slack. Puoi farlo tramite Incoming WebHooks o creando la tua App Slack. Una volta generato il tuo URL webhook di Slack, vai alle impostazioni ‘Gestisci organizzazione’, inserisci l’URL e clicca sul pulsante Connetti :

Source:
https://www.digitalocean.com/community/developer-center/using-the-snyk-vulnerability-scanning-tool