Utilisation de l’outil de balayage de vulnérabilités Snyk

Tutoriels
Kubernetes

Introduction

Snyk a été conçu pour servir de plateforme de sécurité des développeurs avec une grande flexibilité à l’esprit. Son objectif principal est de vous aider à détecter et à corriger les vulnérabilités dans le code source de votre application, les dépendances tierces, les images de conteneurs et les fichiers de configuration de l’infrastructure (par exemple Kubernetes, Terraform, etc.).

Snyk est divisé en quatre composants :

  1. Snyk Code – vous aide à trouver et à corriger les vulnérabilités dans le code source de votre application.
  2. Snyk Open Source – vous aide à trouver et à corriger les vulnérabilités pour toutes les bibliothèques tierces ou dépendances sur lesquelles votre application s’appuie.
  3. Snyk Container – vous aide à trouver et à corriger les vulnérabilités dans les images de conteneurs ou les charges de travail Kubernetes utilisées dans votre cluster.
  4. Snyk Infrastructure as Code – vous aide à trouver et à corriger les erreurs de configuration dans vos manifestes Kubernetes (Terraform, CloudFormation et Azure sont également pris en charge).

Snyk peut être exécuté de différentes manières :

  • via l’interface en ligne de commande en utilisant Snyk CLI. C’est la méthode préférée pour s’exécuter dans les scripts et diverses automatisations, y compris les pipelines CI/CD.
  • Dans le navigateur en tant que Interface Web Snyk. Snyk propose également une plateforme basée sur le cloud que vous pouvez utiliser pour examiner les rapports de scan, recevoir des indices et prendre les mesures nécessaires pour corriger les problèmes signalés, etc. Vous pouvez également connecter des dépôts GitHub et effectuer des scans/audits depuis l’interface web.
  • Via des extensions IDE. De cette façon, vous pouvez repérer les problèmes tôt pendant que vous développez en utilisant votre IDE préféré (par exemple, Visual Studio Code).
  • De manière programmatique, via l’API Snyk. L’API Snyk est disponible pour les clients sur des plans payants et vous permet de vous intégrer de manière programmatique avec Snyk.

Est-ce que Snyk est gratuit?

Oui, l’outil est gratuit, sauf l’API Snyk et certaines fonctionnalités avancées de l’interface web (telles que les rapports avancés). Il y a également une limitation sur le nombre de tests que vous pouvez effectuer par mois.

Consultez les plans tarifaires pour plus d’informations.

Snyk est-il open source?

Oui, l’outil et Snyk CLI le sont certainement. Vous pouvez visiter la page d’accueil GitHub de Snyk pour trouver plus de détails sur chaque composant implémenté. Le portail cloud et toutes les fonctionnalités payantes telles que l’implémentation de l’API REST ne sont pas open source.

Un autre ensemble important de concepts utilisés par Snyk sont les Cibles et les Projets.

Les cibles représentent une ressource externe que Snyk a analysée via une intégration, l’interface en ligne de commande (CLI), l’interface utilisateur (UI) ou l’API. Des exemples de cibles sont un référentiel SCM, une charge de travail Kubernetes, etc.

En revanche, les projets définissent les éléments analysés par Snyk pour une cible donnée. Un projet inclut :

  • A scannable item external to Snyk.
  • Une configuration pour définir comment exécuter cette analyse.

Vous pouvez en savoir plus sur les concepts fondamentaux de Snyk ici.

Dans ce guide, vous utiliserez la CLI Snyk pour effectuer une analyse des risques pour la chaîne d’approvisionnement de vos applications Kubernetes (images de conteneurs, manifestes YAML Kubernetes). Ensuite, vous apprendrez à prendre les mesures appropriées pour remédier à la situation. Enfin, vous apprendrez à intégrer Snyk dans un pipeline CI/CD pour analyser les vulnérabilités dès les premières étapes du développement.

Table des matières

Prérequis

Pour accomplir toutes les étapes de ce guide, vous aurez besoin de :

  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 pour l’interaction avec Kubernetes. Suivez ces instructions pour vous connecter à votre cluster avec kubectl et doctl.
  4. Snyk CLI pour interagir avec le scanner de vulnérabilités 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.

Étape 1 – Faire connaissance avec l’interface de ligne de commande Snyk

Vous pouvez analyser manuellement les vulnérabilités via l’interface de ligne de commande snyk. Le CLI Snyk est conçu pour être utilisé dans divers scripts et automatisations. Un exemple pratique est dans un pipeline CI/CD implémenté à l’aide de différents outils tels que Tekton, Jenkins, GitHub Workflows, etc.

Lorsque le CLI Snyk est invoqué, il démarrera immédiatement le processus d’analyse et signalera les problèmes dans un format spécifique. Par défaut, il affichera un tableau récapitulatif en utilisant la sortie standard ou la console. Snyk peut également générer des rapports dans d’autres formats, tels que JSON, HTML, SARIF, etc.

Vous pouvez choisir d’envoyer les résultats vers le Portail Cloud Snyk (ou l’interface web) via le drapeau --report pour stocker et visualiser ultérieurement les résultats de l’analyse.

Note :Il n’est pas obligatoire de soumettre les résultats de l’analyse au portail cloud Snyk. Le grand avantage d’utiliser le portail Snyk est la visibilité car il vous donne accès à un tableau de bord agréable où vous pouvez vérifier tous les rapports d’analyse et voir dans quelle mesure la chaîne d’approvisionnement Kubernetes est impactée. Il vous aide également à long terme avec les enquêtes et les indices de remédiation.

Le CLI Snyk est divisé en plusieurs sous-commandes. Chaque sous-commande est dédiée à une fonctionnalité spécifique, telle que :

Avant de continuer, assurez-vous de créer un compte gratuit en utilisant l’interface utilisateur web de Snyk. De plus, la CLI de Snyk doit être authentifiée avec votre compte cloud également afin que certaines commandes/sous-commandes fonctionnent (par exemple, snyk code test).

A few examples to try with Snyk CLI:

  1. Exploration des sources ouvertes :
# Analyse le code de votre projet depuis le répertoire actuel
snyk test
# Analyser un chemin spécifique de votre répertoire de projet (assurez-vous de remplacer les espaces réservés `<>` en conséquence)
snyk test <path/to/dir>
  1. Exploration de code :
# Analysez le code de votre projet à partir du répertoire actuel
snyk code test

# Analysez un chemin spécifique à partir de votre répertoire de projet (assurez-vous de remplacer les espaces réservés `<>` en conséquence)
snyk code test <path/to/dir>
  1. Analyse d’image :
# Analyse de l'image docker debian en la téléchargeant d'abord
snyk container debian

# Fournissez plus de contexte au scanner en fournissant un fichier Dockerfile (assurez-vous de remplacer les espaces réservés `<>` en conséquence)
snyk container debian --file=<path/to/dockerfile>
  1. Analyse de l’infrastructure en tant que code :
# Analysez le code de votre projet à partir du répertoire actuel
snyk iac test

# Analysez un chemin spécifique à partir de votre répertoire de projet (assurez-vous de remplacer les espaces réservés `<>` en conséquence)
snyk iac test <path/to/dir>

# Analysez les projets basés sur Kustomize (d'abord vous devez rendre le modèle final, puis le passer au scanner)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Le CLI Snyk fournit des pages d’aide pour toutes les options disponibles. La commande ci-dessous peut être utilisée pour imprimer la page d’aide principale :

snyk --help

La sortie ressemble à ceci :

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.

Chaque commande (ou sous-commande) du CLI Snyk a également une page d’aide associée, qui peut être consultée via snyk [commande] --help.

Veuillez consulter la page de documentation officielle du CLI Snyk pour plus d’exemples.

Étape 2 – Apprendre à connaître l’interface utilisateur web de Snyk

Après avoir créé un compte Snyk, authentifiez-vous et connectez-vous à Snyk, l’interface utilisateur Web s’ouvre sur le tableau de bord, avec un assistant pour vous guider à travers les étapes de configuration:

  • Identifier où se trouve le code que vous souhaitez surveiller dans Snyk.
  • Définir quels projets de votre code vous voulez que Snyk scanne.
  • Connecter Snyk aux projets pertinents pour les analyser.
  • Examiner les résultats de votre analyse Snyk.

Les fonctionnalités suivantes sont disponibles via l’interface web :

Veuillez consulter la page de documentation officielle pour en savoir plus sur l’interface utilisateur web de Snyk.

Comprendre les niveaux de gravité de Snyk

À chaque analyse, snyk vérifie vos ressources pour les risques potentiels en matière de sécurité et comment chaque risque impacte votre système. Un niveau de gravité est attribué à une vulnérabilité pour indiquer le risque que cette vulnérabilité représente dans une application.

Les niveaux de gravité peuvent prendre l’une des valeurs suivantes :

  • Bas: l’application peut exposer certaines données permettant le mappage des vulnérabilités, qui peuvent être utilisées avec d’autres vulnérabilités pour attaquer l’application.
  • Moyen: peut permettre aux attaquants, dans certaines conditions, d’accéder à des données sensibles sur votre application.
  • Élevé: peut permettre aux attaquants d’accéder à des données sensibles sur votre application.
  • Critique: peut permettre aux attaquants d’accéder à des données sensibles et d’exécuter du code sur votre application.

Le système commun d’évaluation des vulnérabilités (CVSS) détermine le niveau de gravité d’une vulnérabilité. Snyk utilise le cadre CVSS version 3.1 pour communiquer les caractéristiques et la gravité des vulnérabilités.

Le tableau ci-dessous montre la correspondance de chaque niveau de 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

Dans ce guide, le seuil de niveau moyen est utilisé comme valeur par défaut dans le pipeline CI/CD exemple en cours d’utilisation. Habituellement, vous voudrez évaluer en premier lieu les problèmes graves et critiques, mais dans certains cas, les problèmes de niveau moyen nécessitent également une attention. En termes de sécurité et en règle générale, vous voudrez généralement être très strict.

Veuillez consulter la documentation officielle pour en savoir plus sur les niveaux de gravité.

Réparation assistée des problèmes de sécurité signalés

Une autre fonctionnalité utile fournie par l’interface web de Snyk est l’assistance à la réparation des problèmes de sécurité. Cela signifie que vous recevez une recommandation sur la manière de corriger chaque problème de sécurité trouvé par le scanner snyk. C’est très important car cela simplifie le processus et boucle pour chaque itération que vous devez effectuer pour corriger chaque problème de sécurité signalé.

La photo ci-dessous illustre mieux ce processus:

Pour chaque problème signalé, il y a un bouton sur lequel vous pouvez cliquer pour obtenir une assistance à la remédiation :

La procédure principale est la même pour chaque problème signalé. Cela signifie que vous cliquez sur le bouton « afficher les détails », puis suivez les étapes suggérées pour appliquer la correction.

Étape 3 – Utiliser Snyk pour analyser les vulnérabilités de configuration Kubernetes dans un pipeline CI/CD

Comment bénéficiez-vous de l’intégration d’un outil de balayage de conformité de sécurité dans votre pipeline CI/CD et évitez-vous les situations désagréables dans un environnement de production ?

Tout commence au niveau fondamental, là où commence le développement logiciel. En général, vous voudrez utiliser un environnement dédié pour chaque étape. Ainsi, dans les premières phases de développement où le code de l’application change très souvent, vous devriez utiliser un environnement de développement dédié (appelé généralement l’environnement inférieur). Ensuite, l’application se perfectionne de plus en plus dans l’environnement de QA, où les équipes de QA effectuent des tests manuels et/ou automatisés. Ensuite, si l’application obtient l’approbation de l’équipe de QA, elle est promue vers les environnements supérieurs, tels que la mise en scène, et enfin en production. Dans ce processus, où l’application est promue d’un environnement à un autre, un pipeline dédié s’exécute, qui scanne en continu les artefacts de l’application et vérifie le niveau de gravité. Si le niveau de gravité ne répond pas à un seuil spécifique, le pipeline échoue immédiatement et la promotion des artefacts de l’application vers la production est arrêtée aux premières étapes.

Ainsi, l’outil de scan de sécurité (par exemple, snyk) agit comme un garde-fou, empêchant les artefacts indésirables d’entrer dans votre environnement de production dès les premières étapes du développement. De la même manière, les pipelines des environnements supérieurs utilisent snyk pour autoriser ou interdire aux artefacts de l’application d’entrer dans la phase finale de production.

Implémentation du Flux de travail CI/CD des Actions GitHub

À cette étape, vous apprendrez à créer et à tester un pipeline CI/CD d’exemple avec une analyse de vulnérabilité intégrée via les workflows GitHub. Pour apprendre les principes fondamentaux de l’utilisation des actions GitHub avec Kubernetes de DigitalOcean, reportez-vous à ce tutoriel.

Le pipeline fourni dans la section suivante construit et déploie l’application game-2048-example à partir du dépôt kubernetes-sample-apps de DigitalOcean.

À un niveau élevé, le workflow CI/CD de game-2048 fourni dans le dépôt kubernetes-sample-apps est composé des étapes suivantes :

  1. Étape de construction et de test de l’application – construit les principaux artefacts de l’application et exécute les tests automatisés.
  2. Étape de scan d’image d’application Snyk – analyse l’image Docker de l’application à la recherche de vulnérabilités connues. Il agit comme un portail, et l’état final du pipeline (réussite/échec) dépend de cette étape. En cas d’échec, une notification Slack est envoyée.
  3. Étape de construction et de publication d’image d’application – construit et étiquette l’image de l’application en utilisant le dernier SHA de commit git. Ensuite, l’image est poussée vers DOCR.
  4. Étape de balayage de l’infrastructure en tant que code (IAC) de Snyk – analyse les vulnérabilités connues dans les manifestes YAML Kubernetes associés à l’application. Agit comme une porte, et l’état final du pipeline (réussite/échec) dépend de cette étape. En cas d’échec, une notification Slack est également envoyée.
  5. Étape de déploiement de l’application – déploie l’application sur Kubernetes (DOKS).

Le diagramme ci-dessous illustre chaque tâche du pipeline et les étapes associées avec les actions (seule la configuration pertinente est montrée):

Remarques:

  • Dans le cas de projets basés sur kustomize, il est préférable de générer le manifeste final afin de capturer et d’analyser tout (y compris les ressources distantes). D’autre part, il peut être difficile d’identifier quelle ressource Kubernetes doit être corrigée. Cela est dû au fait que le fichier manifeste résultant est composé de toutes les ressources à appliquer. C’est ainsi que kustomize fonctionne – il rassemble tous les fragments de configuration de chaque superposition et les applique sur une base pour construire le composé final.
  • Vous pouvez également indiquer à Snyk de balayer l’ensemble du dossier où vous stockez vos configurations kustomize. De cette manière, il est plus facile d’identifier quelle ressource doit être corrigée dans votre référentiel. Les ressources distantes utilisées par kustomize doivent être corrigées en amont. De plus, les secrets Kubernetes et les ConfigMaps générés via kustomize ne sont pas capturés.

Comment faites-vous échouer le pipeline si un certain niveau de conformité à la sécurité n’est pas atteint ?

Le CLI Snyk propose un indicateur nommé --severity-threshold à cette fin. Cet indicateur est corrélé au niveau de gravité global calculé après chaque analyse. Dans le cas de Snyk, le niveau de gravité peut prendre l’une des valeurs suivantes : faible, moyen, élevé ou critique. Vous pouvez faire échouer ou réussir le pipeline en fonction de la valeur du niveau de gravité et arrêter le déploiement de l’application si les conditions ne sont pas remplies.

La photo ci-dessous illustre le flux pour le pipeline CI/CD exemple utilisé dans ce guide :

Veuillez suivre les étapes ci-dessous pour créer et tester le flux de travail GitHub CI/CD de Snyk fourni dans le dépôt GitHub kubernetes-sample-apps :

  1. Forkez le dépôt GitHub kubernetes-sample-apps.
  2. Créez les secrets chiffrés GitHub suivants pour votre copie de kubernetes-sample-apps (Onglet Paramètres -> Secrets -> Actions):
    • DIGITALOCEAN_ACCESS_TOKEN – contient le jeton de votre compte DigitalOcean.
    • DOCKER_REGISTRY – contient le nom de votre registre Docker DigitalOcean, y compris le point de terminaison (par exemple, registry.digitalocean.com/sample-apps).
    • DOKS_CLUSTER – contient le nom de votre cluster DOKS. Vous pouvez exécuter la commande suivante pour obtenir le nom de votre cluster DOKS : doctl k8s cluster list --no-header --format Name.
    • SNYK_TOKEN – contient l’identifiant de votre compte utilisateur Snyk – exécutez : snyk config get api pour obtenir l’identifiant. Si cela ne fonctionne pas, vous pouvez récupérer le jeton depuis votre page de paramètres de compte utilisateur.
    • SLACK_WEBHOOK_URL – contient votre URL de webhook entrante Slack utilisée pour les notifications de scan Snyk.
  3. Naviguez vers l’onglet Actions de votre repo forké et sélectionnez le flux de travail Exemple de CI/CD Snyk pour le jeu 2048 :
  4. Cliquez sur le bouton Lancer le flux de travail et laissez les valeurs par défaut :

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:

Le pipeline échouera et s’arrêtera lorsque le travail snyk-container-security-check s’exécutera. C’est attendu car la valeur de gravité par défaut utilisée dans l’entrée du flux de travail, qui est moyenne, ne répond pas aux attentes. Vous devriez également recevoir une notification Slack avec les détails sur l’exécution du flux de travail:

Dans les étapes suivantes, vous apprendrez comment enquêter sur le rapport de scan snyk pour corriger les problèmes, diminuer le niveau de gravité et faire passer le pipeline.

Étape 4 – Investigation des résultats de l’analyse Snyk et correction des problèmes signalés

Chaque fois que le seuil de niveau de gravité n’est pas atteint, le flux de travail GitHub de game-2048 échouera, et une notification Slack est envoyée avec des détails supplémentaires. Vous recevez également des rapports de sécurité publiés sur GitHub et accessibles dans l’onglet Sécurité de votre dépôt de projet.

Le flux de travail de game-2048 exécute deux vérifications de sécurité :

  1. Vérifications de sécurité de l’image de conteneur – le travail snyk-container-security-check est utilisé à cette fin. La commande snyk équivalente utilisée est – snyk container test <IMAGE-DE-GAME-2048>:<TAG> --file=/chemin/vers/game-2048/Dockerfile.
  2. Vérifications de la configuration incorrecte des manifestes Kubernetes – le travail snyk-iac-security-check est utilisé à cette fin. La commande snyk équivalente utilisée est – snyk iac test /chemin/vers/projet/kubernetes/manifestes.

Ainsi, abaisser le niveau de gravité et réussir le flux de travail consiste à :

  1. Investir et corriger les problèmes signalés par le travail snyk-container-security-check.
  2. Investir et corriger les problèmes signalés par le travail snyk-iac-security-check.

Ensuite, vous apprendrez à les aborder un par un.

Investigation et correction des vulnérabilités des images de conteneurs

Le pipeline d’exemple utilisé dans ce guide exécute des vérifications de sécurité pour l’image de conteneur game-2048 et le fichier Docker associé via la tâche snyk-container-security-check.

La tâche snyk-container-security-check exécute les étapes suivantes :

  1. Construction de l’image Docker de l’application game-2048 localement. Cette étape est implémentée en utilisant l’action GitHub docker-build-push.
  2. Exécution des vérifications de sécurité Snyk pour l’image du conteneur de l’application et le fichier Docker. Cette étape est implémentée en utilisant la commande snyk container test. Les résultats de l’analyse sont exportés au format SARIF GitHub. Le seuil de niveau de sécurité est contrôlé via l’argument –severity-threshold – il est soit défini sur le paramètre d’entrée snyk_fail_threshold si le flux de travail est déclenché manuellement, soit sur la variable d’environnement SNYK_FAIL_THRESHOLD si le flux de travail s’exécute automatiquement.
  3. Les résultats de l’analyse (format SARIF) sont publiés dans l’onglet sécurité de votre dépôt d’application. Cette étape est mise en œuvre en utilisant l’action GitHub codeql.

Le fragment ci-dessous montre la logique principale de la tâche 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

Pour corriger les problèmes signalés, vous devez d’abord vérifier l’onglet sécurité de votre fork du dépôt kubernetes-sample-apps :

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Vous verrez un tas de vulnérabilités pour l'image docker de base dans ce cas. Cliquez sur chacune pour les développer et voir plus de détails :
Pour terminer les investigations et voir les recommandations offertes par Snyk, vous devez inspecter la sortie de la tâche snyk-container-security-check du flux de travail principal :
Remarque : Le test de conteneur Snyk offre la possibilité d'exporter les résultats au format SARIF, mais ne sait pas comment télécharger les rapports sur le portail cloud Snyk. D'autre part, le moniteur de conteneur Snyk offre la possibilité de télécharger les résultats sur le portail cloud Snyk, mais ne peut pas exporter au format SARIF. Par conséquent, ce guide utilise le test de conteneur Snyk avec la fonction d'exportation SARIF. Malheureusement, certaines recommandations ne sont pas disponibles dans la sortie SARIF. Vous devez donc également consulter la sortie de la console de la tâche pour obtenir des recommandations.
Le résultat du travail snyk-container-security-check montre que Snyk recommande de mettre à jour la version de l'image de base de node:16-slim à node:18.6.0-slim. Ce changement élimine le(s) problème(s) de risque élevé et réduit également le nombre d'autres vulnérabilités signalées de 70 à 44 - ce qui représente une réduction substantielle de presque 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"]

Maintenant, ouvrez le fichier Dockerfile de l’application game-2048 à partir de votre fork, et modifiez les directives FROM pour pointer vers la nouvelle version (node:18.6.0-slim à l’heure où ces lignes sont écrites) :

#

# Le mode de construction peut être défini via la variable d’environnement NODE_ENV (développement ou production)

# Voir le package.json du projet et webpack.config.js

#

Enfin, validez les modifications sur votre dépôt GitHub et déclenchez à nouveau le flux de travail (en laissant les valeurs par défaut). Cette fois, le travail snyk-container-security-check devrait passer :

En accédant à l’onglet sécurité de votre projet, aucun problème ne devrait être signalé.

Comment vous assurez-vous de réduire les vulnérabilités de l’image de base à l’avenir ?

  1. La meilleure approche est d’utiliser une image de base avec une empreinte minimale – moins il y a de binaires ou de dépendances dans l’image de base, mieux c’est. Une autre bonne pratique consiste à surveiller continuellement vos projets, comme expliqué dans la section Suivre vos projets régulièrement de ce guide.
  2. Vous remarquerez que le pipeline échoue toujours, mais cette fois-ci à la phase snyk-iac-security-check. C’est attendu car il y a des problèmes de sécurité avec les manifestes Kubernetes utilisés pour déployer l’application. Dans la prochaine section, vous apprendrez comment enquêter sur cette situation et appliquer les recommandations de sécurité de Snyk pour corriger les problèmes signalés.

Enquête et Correction des Vulnérabilités des Manifestes 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

Le pipeline échoue toujours et s’arrête au travail snyk-iac-security-check. C’est attendu car la valeur de niveau de gravité par défaut utilisée dans l’entrée du flux de travail, qui est moyen, ne répond pas aux exigences de sécurité du projet.

  1. Le travail snyk-iac-security-check vérifie les vulnérabilités (ou les mauvaises configurations) des manifestes Kubernetes, et exécute les étapes suivantes:
  2. Les vérifications de sécurité de Snyk pour les manifestes Kubernetes à partir du répertoire du projet game-2048-example sont effectuées. Cette étape est mise en œuvre à l’aide de la commande snyk iac test. Les résultats de l’analyse sont exportés au format GitHub SARIF. Le seuil de niveau de sécurité est contrôlé via l’argument –severity-threshold – il est soit défini sur le paramètre d’entrée snyk_fail_threshold si le flux de travail est déclenché manuellement, soit sur la variable d’environnement SNYK_FAIL_THRESHOLD, si le flux de travail s’exécute automatiquement. Enfin, l’argument –report est également utilisé pour envoyer les résultats de l’analyse au portail cloud Snyk.

Les résultats de l’analyse (format SARIF) sont publiés dans l’onglet de sécurité de votre dépôt d’application. Cette étape est mise en œuvre à l’aide de l’action GitHub codeql.

Le fragment ci-dessous montre la mise en œuvre effective de chaque étape de la tâche 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

Pour corriger les problèmes signalés, vous avez deux options:

  • Utilisez le portail cloud Snyk et accédez au projet game-2048 pour consulter les détails:
  • Utilisez l’onglet sécurité de votre dépôt d’application Game-2048 pour vérifier les détails :
  • Quoi qu’il en soit, vous recevrez des recommandations sur la manière de résoudre les problèmes signalés.
  • Pour ce guide, vous utiliserez le portail cloud Snyk pour examiner les problèmes de sécurité signalés. Tout d’abord, cliquez sur l’entrée game-2048-example de la liste des projets, puis sélectionnez le fichier kustomize/resources/deployment.yaml :

Ensuite, cochez la case Moyenne dans le sous-menu Sévérité sur la gauche pour afficher uniquement les problèmes de niveau moyen :

Ensuite, vous pouvez inspecter chaque carte de problème signalé et vérifier les détails. Allez-y et cliquez sur le bouton Afficher plus de détails de la carte Le conteneur fonctionne sans contrôle de l’utilisateur root – vous recevrez plus de détails sur le problème actuel et des indications importantes sur la manière de le résoudre :

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

  1. Après avoir collecté toutes les informations de chaque carte, vous pouvez continuer et modifier le fichier deployment.yaml de votre dépôt ( situé dans le sous-dossier game-2048-example/kustomize/resources). Les correctifs sont déjà en place, vous devez simplement décommenter les dernières lignes du fichier. Le fichier deployment.yaml final devrait ressembler à ce qui suit :
  2. readOnlyRootFilesystem – exécute l’image du conteneur en lecture seule (impossible de modifier les fichiers via kubectl exec dans le conteneur).

allowPrivilegeEscalation – définir allowPrivilegeEscalation sur false garantit qu’aucun processus enfant d’un conteneur ne peut acquérir plus de privilèges que son parent.

capabilities.drop – Pour rendre les conteneurs plus sécurisés, vous devez leur fournir le moins de privilèges nécessaires à leur exécution. En pratique, vous supprimez tout par défaut, puis ajoutez les capacités requises étape par étape. Vous pouvez en savoir plus sur les capacités des conteneurs ici.

Enfin, validez les modifications pour le fichier deployment.yaml et poussez-les sur la branche principale. Après avoir déclenché manuellement le flux de travail, il devrait se terminer avec succès cette fois-ci:

Vous devriez également recevoir une notification Slack verte de la tâche de balayage de Snyk. Accédez au lien du portail Snyk et vérifiez si les problèmes que vous avez récemment corrigés ont disparu – il ne devrait y avoir aucun problème de niveau moyen signalé.

Vérifiez si le déploiement du jeu 2048 dispose d’un système de fichiers en lecture seule (immutable) en écrivant dans le fichier index.html utilisé par l’application de jeu 2048 :

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

La sortie ressemble à ceci :

Sortie
/bin/bash: /public/index.html: Système de fichiers en lecture seule
command terminée avec le code de sortie 1

Vérifiez si le déploiement du jeu 2048 dispose d’un système de fichiers en lecture seule (immutable) en écrivant dans le fichier index.html utilisé par l’application de jeu 2048 :

La sortie ressemble à ceci :

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 }}
      
      ...

Vérifiez si le conteneur s’exécute en tant qu’utilisateur non root (devrait imprimer un nombre entier différent de zéro – par exemple, 1000):

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

Vérifiez si le conteneur s’exécute en tant qu’utilisateur non root (devrait imprimer un nombre entier différent de zéro – par exemple, 1000):

Si toutes les vérifications réussissent, alors vous avez appliqué avec succès les recommandations de sécurité requises.

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 }}

Surveillez vos projets régulièrement

L’automatisation de l’analyse de vulnérabilité que vous avez mise en œuvre jusqu’à présent est un bon point de départ mais pas parfait. Pourquoi ?

Un problème avec l’approche actuelle est que vous ne savez jamais quand de nouveaux problèmes sont signalés pour les ressources que vous avez déjà déployées dans vos environnements. En d’autres termes, vous avez évalué les risques de sécurité et pris les mesures pour résoudre les problèmes à un moment précis – lorsque votre automatisation CI/CD a été exécutée.

Mais que se passe-t-il si de nouveaux problèmes sont signalés entre-temps et que votre application est à nouveau vulnérable ? Snyk vous aide à surmonter cette situation grâce à la fonction de surveillance. La fonction de surveillance de Snyk vous aide à traiter de nouvelles vulnérabilités qui sont constamment divulguées. Lorsqu’elle est combinée à l’intégration Slack de Snyk (expliquée dans Étape 6 – Activation des notifications Slack), vous pouvez prendre des mesures immédiates pour corriger les problèmes récemment divulgués qui pourraient affecter votre application en environnement de production.

Pour bénéficier de cette fonctionnalité, il vous suffit d’utiliser la commande snyk monitor avant toute étape de déploiement dans votre pipeline CI/CD. La syntaxe est très similaire aux commandes snyk test (l’une des choses intéressantes à propos de l’interface en ligne de commande de snyk est qu’elle a été conçue dans un souci d’uniformité). La commande snyk monitor enverra un instantané au portail cloud de Snyk, et à partir de là, vous serez informé des nouvelles vulnérabilités divulguées pour votre projet.

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.

En ce qui concerne l’automatisation du flux de travail GitHub, vous pouvez surveiller votre conteneur d’application dans le travail snyk-container-security-check, après avoir testé les vulnérabilités. L’extrait ci-dessous montre une mise en œuvre pratique du pipeline utilisé dans ce guide (certaines étapes ont été omises pour des raisons de clarté) :

  1. –fichier=${{ env.PROJECT_DIR }}/Dockerfile \
  2. –seuil-de-gravité=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
  3. –nom-de-la-cible=${{ env.PROJECT_NAME }} \
  4. –référence-de-la-cible=${{ env.ENVIRONMENT }} \

–sortie-de-fichier-sarif=snyk-container-scan.sarif

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

Le snippet ci-dessus montre une étape supplémentaire appelée Surveiller le conteneur d’application à l’aide de Snyk où s’exécute le véritable moniteur de conteneur Snyk.

Après l’exécution de la commande de surveillance Snyk, vous pouvez vous connecter à l’interface utilisateur Web de Snyk pour voir le dernier instantané et l’historique de votre projet:

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

Vous pouvez également tester et surveiller le code source de votre application dans le travail build-and-test-application. Le snippet ci-dessous montre un exemple d’implémentation pour le flux de travail GitHub utilisé dans ce guide:

Ensuite, vous recevrez des notifications Slack régulières sur les vulnérabilités récemment divulguées pour votre projet.

Gestion des Exceptions

Il arrive parfois que vous ne vouliez pas que le rapport final soit affecté par certains problèmes que votre équipe considère comme sûrs à ignorer. Snyk propose une fonctionnalité intégrée pour gérer les exceptions et surmonter cette situation.

Vous pouvez en savoir plus sur cette fonctionnalité ici.

Snyk pour les IDE

Snyk offre une prise en charge pour une variété d’IDE, tels que :

le plugin Eclipse.

le plugin JetBrains.

  • l’extension Visual Studio.
  • l’extension Visual Studio Code.
  • Les plugins ci-dessus vous aideront à détecter et à corriger les problèmes dès les premiers stades de développement, éliminant ainsi la frustration, les coûts et les failles de sécurité dans les systèmes de production. De plus, cela vous aide à réduire les itérations et les efforts humains à long terme. Par exemple, pour chaque problème de sécurité signalé par votre automatisation CI/CD, vous devez revenir en arrière et corriger le problème dans votre code, valider les modifications, attendre à nouveau l’automatisation CI/CD, puis répéter en cas d’échec.
  • À partir de la documentation officielle, vous pouvez en savoir plus sur ces fonctionnalités sur la page Snyk pour les IDE.
  • Étape 5 – Déclenchement automatique du flux de travail Snyk CI/CD
  • Vous pouvez configurer le flux de travail pour se déclencher automatiquement à chaque validation ou PR sur la branche principale en décommentant les lignes suivantes en haut du fichier game-2048-snyk.yaml :
  • Après avoir modifié le fichier, validez les modifications sur votre branche principale, et vous devriez être prêt à partir.
  • Étape 6 – Activation des notifications Slack
  • Vous pouvez configurer Snyk pour envoyer des alertes Slack concernant les nouvelles vulnérabilités découvertes dans vos projets et concernant les nouvelles mises à jour ou correctifs disponibles.
  • Pour le configurer, vous devrez générer un webhook Slack. Vous pouvez le faire soit via Incoming WebHooks soit en créant votre propre Slack App. Une fois que vous avez généré votre URL de webhook Slack, rendez-vous dans les paramètres de votre ‘Gérer l’organisation’, saisissez l’URL et cliquez sur le bouton Connect :

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