Trois étapes pour sécuriser les images de conteneurs

Sécurité des images de conteneurs avec Docker

Si vous avez déjà analysé une image de conteneur à la recherche de vulnérabilités, vous en avez probablement trouvé plus que quelques-unes — peut-être des centaines, voire des milliers. Ce guide La sécurité des conteneurs pour les équipes de développement, rédigé conjointement par Snyk et Docker, se concentre sur l’image de conteneur et les logiciels qu’elle contient. Vous pouvez télécharger ici la version PDF de ce guide sur la sécurité des conteneurs.

Nous commençons par expliquer pourquoi la sécurité des conteneurs est importante.  Les conteneurs gagnent en popularité, mais présentent des risques de sécurité susceptibles d’entraîner une baisse de productivité, une diminution des ventes, voire des millions de dollars d’amendes pour les entreprises. Cet article présente notre processus en trois étapes pour créer des images de conteneurs sécurisées. Créez un compte Snyk gratuit pour détecter et corriger facilement les vulnérabilités dans les images Docker et les bibliothèques open source.

Trois étapes pour sécuriser les images de conteneurs

Comme nous l’avons indiqué précédemment, la sécurité des images de conteneurs ne se limite pas à un seul domaine : elle concerne les équipes de développement, de sécurité et d’exploitation. Plusieurs enjeux de sécurité s’appliquent aux conteneurs.

• L’image de conteneur elle-même et les logiciels qu’elle contient

• Les interactions entre un conteneur, le système d’exploitation hôte et les autres conteneurs sur le même hôte

• Le système d’exploitation hôte lui-même

• Les enjeux liés au réseau et au stockage des conteneurs

• La sécurité à l’exécution, souvent dans les clusters Kubernetes

Chacun de ces points mérite un guide à part entière pour être traité comme il se doit, et tous, sauf le premier, font déjà l’objet d’un ou plusieurs guides. Celui-ci se concentre sur l’image de conteneur et les logiciels qu’elle contient.

À un niveau général, la création d’une image de conteneur sécurisée se déroule en trois étapes clés :

1. Sécurisez votre code et ses dépendances

2. Partez d’une image de base minimale provenant d’une source fiable

3. Gérez les outils et les paquets ajoutés aux images tout au long du cycle de développement

Examinons chacune de ces étapes plus en détail afin de voir comment cette approche permet de créer des images de conteneurs sécurisées.

1. Sécurisez votre code et ses dépendances

Accélérer la livraison de vos applications cloud natives est probablement l’une des principales raisons pour lesquelles vous créez des conteneurs, et vos applications sont vitales pour votre organisation. Il n’y a pas si longtemps, la sécurité des applications se limitait au code. Même si les conteneurs et d’autres pratiques de développement modernes ont élargi le sens du terme « code d’application », ce domaine reste une préoccupation majeure.

Heureusement, c’est la partie des images de conteneurs sur laquelle les développeurs ont le plus de contrôle direct et qu’ils connaissent, espérons-le, le mieux. Il n’est toutefois pas facile de répertorier toutes les dépendances de votre code et de déterminer comment corriger les problèmes de sécurité. Si vous avez accès au code source, utilisez des outils spécialisés comme Snyk Open Source pour effectuer une analyse de la composition logicielle (SCA) et des tests statiques de sécurité des applications (SAST) afin d’analyser votre code et ses dépendances. Dans les applications modernes, il n’est pas rare que les dépendances open source tierces représentent la majorité des lignes de code.

Figure 2 : La quantité de code open source dans une application peut facilement dépasser de loin la quantité de code propriétaire.

Détecter les problèmes dès le début du développement et intégrer des outils de sécurité à votre code source permet d’automatiser ce processus, sans dépendre de l’étape de conteneurisation. Il est possible d’analyser un conteneur et certains types de code, mais détecter ces problèmes directement dans vos commits Git, vos pipelines et vos dépôts s’intégrera probablement mieux au processus de travail des développeurs.

2. Partez d’une image de base minimale provenant d’une source fiable

Pourquoi les petites images sont-elles si importantes ?

L’image de base — la ligne FROM de votre Dockerfile — est l’un des facteurs les plus importants en matière de sécurité. Heureusement, de nombreux fournisseurs de confiance proposent du contenu facile à utiliser. Docker Hub est de loin le point de départ le plus populaire pour trouver des images de base de conteneurs.

Docker Hub propose plus de 3,8 millions d’images et plus de 7 millions de dépôts. Docker Hub est très actif et enregistre environ 11 milliards de téléchargements par mois. Certaines de ces images sont des images officielles, publiées par Docker sous la forme d’une sélection de dépôts open source Docker et de solutions « prêtes à l’emploi ».

Docker propose également des images publiées par des éditeurs vérifiés. Ces images de haute qualité sont publiées et maintenues directement par des entités commerciales que Docker a vérifiées en tant qu’éditeurs vérifiés. Les consignes que Docker recommande à ces éditeurs de suivre constituent un excellent point de départ pour définir vos propres bonnes pratiques internes en matière d’images de conteneurs.

Figure 3 : Images officielles sur Docker Hub. Remarquez le badge « Official » et les mises à jour récentes.

Il est facile de trouver sur Docker Hub une image publique correspondant à votre cas d’utilisation, mais vous devez prêter attention à sa provenance. Tout comme vous n’installeriez pas de logiciel téléchargé depuis un site Web non fiable, vous ne voudriez probablement pas utiliser des images publiées sur Docker Hub par des personnes que vous ne connaissez pas et en qui vous n’avez pas confiance.

En utilisant des images issues du programme officiel de Docker, ou en connaissant et en vérifiant la source et le contenu des images tierces — par exemple à l’aide de Notary pour contrôler les signatures numériques —, vous avez certaines garanties de qualité. Pour réduire davantage le nombre de vulnérabilités et mieux contrôler les éléments intégrés à vos conteneurs, allez plus loin et choisissez des images de base minimales adaptées à vos besoins.

Par exemple, la figure 3 ci-dessus présente un dépôt Python. Vous pouvez tout à fait créer votre application Python à partir de cette image, et elle fonctionnera presque à coup sûr. En effet, l’image marquée sur Docker Hub est conçue pour être facile à utiliser dans de nombreux cas et elle est bien maintenue. Mais ce dépôt contient plus de 1 000 autres images Python.

Faut-il simplement utiliser l’image facile à mémoriser _python ou existe-t-il des images plus petites, mieux adaptées à vos besoins et qui réduiraient aussi votre surface d’exposition aux risques de sécurité_ ? Comme vous pouvez vous en douter, il existe presque certainement de meilleurs choix du point de vue de la sécurité.

La taille des images de conteneurs compte, et pas seulement pour leur portabilité et la rapidité des téléchargements. L’image marquée python est facile à utiliser, car elle comprend un grand nombre de bibliothèques système et de paquets de développement préinstallés. Elle fonctionnera donc probablement très bien avec différents projets et contiendra tout ce dont vous pourriez avoir besoin pour compiler du code et des dépendances. Mais les scanners de vulnérabilités peuvent également révéler une longue liste de problèmes à examiner.

Figure 4 : Comparaison de deux images basées sur Debian pour Python 3.x.

Vous vous demandez peut-être pourquoi les deux images présentent encore des vulnérabilités, et notamment des vulnérabilités de gravité élevée. En examinant ces vulnérabilités, vous constaterez toutefois qu’elles concernent les paquets du système d’exploitation sous-jacent ; aucun correctif n’est disponible et aucun exploit n’est connu dans la nature. De plus, dans le cadre du processus de vérification des éditeurs de Docker, les deux images ont été mises à jour avec les versions les plus récentes de tous leurs paquets au cours des derniers jours. Elles sont donc bien maintenues.

Il faut également tenir compte du contexte : les vulnérabilités qui apparaissent concernent souvent des outils de développement qu’il serait préférable de supprimer de la version de production de votre image, comme curl, des bibliothèques de développement, voire des interpréteurs de commandes et des gestionnaires de paquets. Mais avec le temps, les risques de nouvelles vulnérabilités affectant la grande image Python sont bien plus élevés qu’avec l’image plus légère.

Mise en pratique de la sécurité des images de conteneurs : choisir une image de base

Comme nous l’avons indiqué précédemment, « commencez par des images légères » est un conseil que vous trouverez partout. Mais l’un des objectifs du partenariat entre Docker et Snyk est de vous aider à passer des conseils à l’action. La fonctionnalité intégrée d’analyse des vulnérabilités de Docker Desktop peut justement vous aider à choisir une image de base !

Poursuivons avec notre exemple Python pour voir comment passer de l’image Python à l’image python:3-slim-buster grâce à la fonctionnalité d’analyse des vulnérabilités de Docker, optimisée par Snyk. Vous pouvez suivre ces étapes de votre côté si vous le souhaitez.

Commençons par un cas simple : utilisons l’image Python pour créer une image de conteneur très simple. Voici le Dockerfile correspondant :

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Difficile de faire plus simple. Le fichier hello.py se résume à une instruction print (“Hello, World!”).

Ensuite, nous allons créer l’image, puis l’analyser :

$> docker build -t hello-python .

[+] Building 67.4s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.4s => => transferring dockerfile: 36B 0.1s => [internal] load .dockerignore 0.4s => => transferring context: 2B 0.1s => [internal] load metadata for docker.io/library/python:latest 1.6s => FROM [1/1] FROM docker.io/library/python 65.1s
...
=> exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:3a92e9... 0.0s => => naming to docker.io/library/hello-python 0.0s

$> docker run hello-python
Hello, World!

$> docker scan hello-python -f Dockerfile
/ Analyzing docker dependencies for hello-python/Dockerfile

Organization: snyk-pmm Package manager: deb
 Target file: Project name: Docker image: Base image:
Dockerfile docker-image|hello-python hello-python
python

Tested 431 dependencies for known issues, found 268 issues. Base Image Vulnerabilities Severity
python:latest 268 6 high, 34 medium, 228 low

Recommendations for base image upgrade:
Alternative image types
Vulnerabilities Severity
75 1 high, 10 medium, 64 low
Base Image
python:3-slim-buster
python:3.9-rc-slim-buster 75 1 high, 10 medium, 64 low

Notez d’abord que le résultat indique 431 dépendances et 268 problèmes dans l’image. Nous avons omis le détail des différentes vulnérabilités pour rester concis ; nous y reviendrons dans un instant. Nous n’avons rien ajouté de notable à l’image de base python, donc les 268 vulnérabilités proviennent toutes de l’image de base, comme le montre également le résultat.

À la fin du résultat, des recommandations d’images de base nous sont proposées pour améliorer notre niveau de sécurité. L’image python:3-slim-buster présentée précédemment y figure. C’est d’ailleurs exactement ainsi que nous avons établi notre comparaison initiale. Nous voyons déjà que cette nouvelle image éliminera plus de 70 % des vulnérabilités présentes dans l’image Python et ramènera le nombre de vulnérabilités de gravité élevée à une seule. Nous allons tout de même la créer et l’analyser à nouveau pour le confirmer.

Il suffit de modifier la ligne FROM du Dockerfile. Nous allons enregistrer une copie distincte sous le nom Dockerfile.slim.

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Nous pouvons ensuite créer et analyser à nouveau l’image avec une étiquette « slim » afin de conserver nos images séparément :

```
$> docker build -t hello-python:slim . -f Dockerfile.slim

[+] Building 21.0s (8/8) FINISHED
=> [internal] load .dockerignore                                        0.1s
=> => transferring context: 2B                                          0.0s
=> [internal] load build definition from Dockerfile.slim                0.1s
=> => transferring dockerfile: 135B                                     0.0s
=> [internal] load metadata for docker.io/library/python:3-slim-buster  11.5s                                                                            
...
=> exporting to image                                                   0.0s                           
=> => exporting layers                                                  0.0s                            
=> => writing image sha256:63768699.                                    0.0s                                          
=> => naming to docker.io/library/hello-python:slim                     0.0s                                                         

$> docker run hello-python:slim
Hello, World!

$> docker scan hello-python:slim -f Dockerfile.slim

Package manager:  deb
Target file:      Dockerfile.slim
Project name:     docker-image hello-python
Docker image:     hello-python:slim
Base image:       python:3-slim-buster
Licenses:         enabled

Tested 94 dependencies for known issues, found 75 issues.

According to our scan, you are currently using the most secure version of the selected base image
```

Cette fois, les résultats de l’analyse complète ne révèlent que 94 dépendances et une seule vulnérabilité de gravité élevée. Voilà comment Docker et Snyk peuvent vous guider vers de meilleures images de base. Comme vous pouvez l’imaginer, nous ne couvrons pas toutes les images de Docker Hub, mais la plupart des images de base officielles les plus populaires sont prises en charge.

3. Gérez toutes les couches entre l’image de base et votre code

Nous avons examiné en détail les images de base, car elles exigent une attention particulière. En ajoutant vos propres couches, vous héritez de tout ce qui se trouve dans l’image de base ; une image légère réduit souvent la charge liée à la sécurité. Mais qu’en est-il de toutes les couches que vous ajoutez au conteneur ? Si vous partez d’une image légère, vous aurez probablement besoin d’ajouter des outils et des bibliothèques, ainsi que votre code et divers éléments à installer pour que tout fonctionne. Vous devez surveiller l’ensemble afin de détecter les vulnérabilités.

La bonne nouvelle, c’est que vous contrôlez directement ces couches intermédiaires, c’est-à-dire tout ce qui suit la première ligne FROM et précède les dernières lignes du Dockerfile où vous configurez l’exécution de votre code. Plus précisément, nous nous intéressons aux commandes RUN, COPY et ADD des Dockerfiles, car ce sont elles qui installent des éléments. Techniquement, votre code peut aussi se trouver dans ces couches intermédiaires, mais, par principe, nous considérerons qu’il constitue la dernière couche, principalement parce que nous avons déjà traité le code à l’étape 1.

Figure 5 : Les couches intermédiaires d’une image de conteneur

L’une des principales difficultés liées à la gestion des vulnérabilités dans ces couches intermédiaires consiste à déterminer les priorités à chaque étape du cycle de vie.

Vous aurez peut-être besoin de différents ensembles d’outils à chaque étape, mais à mesure que les images approchent de la production, supprimez tout ce qui n’est pas absolument indispensable au fonctionnement de votre application. En personnalisant vos images à partir d’une base minimale, puis en y ajoutant vos outils, vous pourrez facilement les retirer plus tard : il vous suffira de les supprimer du Dockerfile et de reconstruire l’image. Mieux encore, utilisez des builds multi-étapes pour intégrer toutes ces étapes à un processus de build unique et automatisé.

Prioriser la correction des vulnérabilités de sécurité dans les conteneurs

Cela dit, vous trouverez toujours des vulnérabilités de sécurité et devrez déterminer comment les traiter. En théorie, éliminer toutes les vulnérabilités est idéal, mais dans la pratique, c’est probablement irréalisable ou ne justifie pas le temps nécessaire.

Voici un point de départ suggéré pour les étapes classiques du développement, des tests et de la production. Vos processus de production logicielle sont probablement plus complexes, mais vous pouvez les adapter en conséquence.

• Commencez par les images de développement
  Images de développement : elles présentent probablement le plus de vulnérabilités dans les couches intermédiaires, car elles nécessitent davantage d’outils et de paquets de prise en charge. La bonne nouvelle, c’est que SI vous créez vos images par étapes et que vos images de production n’incluent pas tous ces éléments supplémentaires, vous pouvez sans doute ignorer bon nombre des vulnérabilités à ce stade. Pour prendre cette décision, vous devez notamment pouvoir suivre les dépendances installées dans le conteneur et les comparer à ce qui est nécessaire pour votre boucle de développement interne. Il est tout à fait normal qu’une bibliothèque installée comme dépendance d’une dépendance d’une dépendance présente une vulnérabilité… vous devez pouvoir déterminer si la simple suppression d’un de vos paquets de développement suffit à éliminer cette vulnérabilité.
  
  

  Dans l’exemple ci-dessous, nous avons une application Ruby. SQLite est souvent fourni avec Ruby pour simplifier le développement, mais vous n’utiliseriez probablement pas la même base de données SQLite en production. Sachant cela, et avec les bonnes informations issues de l’analyse des vulnérabilités du conteneur, vous pouvez décider d’ignorer les vulnérabilités des bibliothèques installées avec SQLite pendant le développement. Nous verrons comment l’analyse Docker fournit ces informations ainsi que des détails supplémentaires qui simplifient considérablement cette tâche.
  

  

• Allégez les images de test
  Images de test : en pratique, elles ne sont pas très différentes des images de développement, du moins pour ce qui est de l’évaluation des vulnérabilités. Si vous savez qu’une vulnérabilité provient d’un paquet de test qui ne sera pas inclus dans l’image de production, vous pouvez choisir de l’ignorer. C’est le bon moment pour comparer les résultats d’analyse avec ceux de l’étape de développement, surtout si vous avez choisi d’ignorer des vulnérabilités graves à cette étape. Les vulnérabilités des images de développement ont-elles vraiment disparu des images de test ? Si oui, votre processus fonctionne. Sinon, il est peut-être temps de revoir votre image de développement ou vos étapes de compilation.

• Verrouillez vos images de production
  Images de production : ce sont les images critiques, car elles seront effectivement exécutées quelque part et potentiellement exposées au monde extérieur. Malgré tout, même en les allégeant et en supprimant autant d’éléments que possible, éliminer toutes les vulnérabilités peut s’avérer difficile. Dans bien des cas, l’objectif est d’automatiser le processus de mise en production. Vous devez absolument corriger les vulnérabilités à haut risque, en particulier celles pour lesquelles des exploits sont connus. Mais l’une des raisons pour lesquelles il est également important d’analyser les images aux étapes de développement et de test est de réduire les surprises au moment de la mise en production. Si vous avez atténué les risques en amont, l’analyse en production sert principalement à détecter les nouvelles vulnérabilités découvertes à la dernière minute.

Voyons un autre exemple pour découvrir comment Docker et Snyk peuvent vous aider à gérer les couches intermédiaires.

Mise en pratique : hiérarchiser la correction des vulnérabilités introduites par l’utilisateur

Dans cet exemple, nous allons présenter des techniques pratiques liées aux « couches intermédiaires », utilisables avec les capacités d’analyse des vulnérabilités de Docker optimisées par Snyk. Pour commencer, nous utilisons cette fois une application un peu plus intéressante. C’est une application Ruby, mais ce n’est pas très important pour ces exercices.

Voici notre Dockerfile :

```
FROM ruby:2.5.1

RUN apt-get update && \
  apt-get install -y git vim && \
  rm -rf/var/lib/apt/lists/*

RUN gem update --system 3.0.4 && \
  gem install bundler -V '2.0.2'

WORKDIR /usr/src/app/alpha-blog

COPY . .

ENV BUNDLER VERSION 2.0.2

RUN bundle update && \
  bundle install && \
  rails db:setup && \
  rails db:migrate

EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]
```

Il s’agit toujours d’un Dockerfile assez simple, dans lequel nous ajoutons plusieurs couches à notre image parente Ruby :

• La première ligne RUN ajoute quelques utilitaires pour effectuer du développement local dans l’image

• Nous mettons ensuite à jour les principaux composants Ruby pour qu’ils soient prêts à l’emploi

• Notre code est copié à l’aide de la commande COPY . .

• Notre projet Rails est initialisé à l’aide des commandes RUN bundle…

Si vous vous dites « Installer git et vim dans une image semble étrange », vous avez raison. Ne faites pas ça. L’atelier complet mentionné dans la note précédente explique l’historique de cette image et la raison de leur présence.

Même si ce qui se passe n’est pas très compliqué à comprendre, comme vous pouvez l’imaginer, chacune de ces lignes du Dockerfile installe un grand nombre d’éléments, susceptibles d’ajouter de nouvelles vulnérabilités à notre image.

Nous pouvons créer cette image et la tester comme précédemment :

```
$> docker build -t blog .

[+] Building 111.5s (11/11) FINISHED
.
.
.
=> [6/6] RUN bundle update && bundle install && 
  rails db:setup && rails db:migrate 108.8s
=> exporting to image                                           1.6s
=> => exporting layers                                          1.6s 
=> => writing image sha256:0b7c017032e301429...433c23a5         0.0s                                  
=> => naming to docker.io/library/blog                          0.0s                 

$> docker scan blog -f Dockerfile

Testing blog...
.
.
.
X High severity vulnerability found in bzip2
  Description: Out-of-bounds Write
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-BZIP2-450801
  Introduced through: bzip2@1.0.6-8.1, bzip2/libbz2-dev@1.0.6-8.l, imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-11+deb9u6,meta-common-packages@meta
  From: bzip2@1.0.6-8.1
  From: bzip2/libbz2-dev@1.0.6-8.1
  From: imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-ll+deb9u6>imagemagick/libmagickcore-6.q16-dev@8:6.9.7.4+dfsg-1l+deb9u6 › bzip2/libbz2-devel.0.6-8.1
  and 1 more..
  Introduced by your base image (ruby:2.5.1)

X High severity vulnerability found in apt/libapt-pkg5.0
  Description: Arbitrary Code Injection
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-APT-407402
  Introduced through: apt/libapt-pkg5.0@1.4.8, apt@l.4.8
  From: apt/libapt-pkg5.001.4.8
  From: apt@l.4.8 > apt/libapt-pkg5.001.4.8
  From: apt@l.4.8
  Introduced by your base image (ruby:2.5.1)
  Fixed in: 1.4.9

Organization:      snyk-pmm
Package manager:   deb
Target file:       Dockerfile
Project name:      docker-image|blog
Docker image:      blog
Base image:        ruby:2.5.1
Licenses:          enabled

Tested 413 dependencies for known issues, found 871 issues.

Base Image     Vulnerabilities   Severity
ruby:2.5.1     867               48 high, 237 medium, 582 low

Recommendations for base image upgrade:

Minor upgrades
Base Image     Vulnerabilities   Severity
ruby:2.5       257               6 high, 34 medium, 217 low

Alternative image types
Base Image                       Vulnerabilities   Severity
ruby:2.5-slim                    53                0 high, 5 medium, 48 low
ruby:2.7.0-slim-buster           61                1 high, 8 medium, 52 low
ruby:2.7.0-preview3-slim-buster  63                1 high, 9 medium, 53 low
ruby:2.7.0-preview2-slim         63                1 high, 9 medium, 53 low

De toute évidence, la personne qui a créé ce Dockerfile n’a pas suivi nos conseils de la section précédente : 871 vulnérabilités, alors que notre image parente en compte déjà 867 ! Il va falloir retrouver cette personne et lui donner un exemplaire de ce guide. Mais, pour l’instant, nous devons déterminer si l’une de nos commandes Dockerfile a ajouté des vulnérabilités. La différence entre le nombre total de problèmes et celui de l’image de base indique qu’il y en a au moins quatre à corriger.

La commande docker scan peut nous aider à cerner rapidement le problème en ignorant toutes les vulnérabilités de l’image de base grâce à l’option –exclude-base. Voici une autre analyse et un extrait des résultats obtenus en excluant les vulnérabilités de l’image de base :

L’option —exclude-base nécessite d’inclure le Dockerfile dans l’analyse (avec l’option -f Dockerfile que nous utilisons depuis le début).

X High severity vulnerability found in curl/libcurl3
  Description: Buffer Overflow
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-CURL-466505
  Introduced through: curl@7.52.1-5+deb9u7, curl/libcurl4-openssl-dev@7.52.1-5+deb9u7, gitel:2.11.0-3+deb9u7
  From: curl@7.52.1-5+deb9u7 > curl/libcurl3@7.52.1-5+deb9u7
  From: curl/libcurl4-openssl-dev@7.52.1-5+deb9u7 › curl/libcurl3@7.52.1-5+deb9u7
  From: curl@7.52.1-5+deb9u7
  and 2 more..
  Introduced in your Dockerfile by `RUN apt-get update && apt-get install -y git vim && rm -rf/var/lib/apt/lists/*`
  Fixed in: 7.52.1-5+deb9u10

Organization:     snyk-pmm
Package manager:  deb
Target file:      Dockerfile
Project name:     docker-image|blog
Docker image:     blog
Base image:       ruby:2.5.1
Licenses:         enabled

Tested 413 dependencies for known issues, found 70 issues.

C’est déjà plus facile à gérer : 70 problèmes au lieu de 871. En parcourant la liste des vulnérabilités détectées, vous verrez également une ligne qui commence par « Introduced in your Dockerfile by ». Le chemin des dépendances permet aussi de remonter à l’origine d’une vulnérabilité, mais le fait de voir la commande Dockerfile elle-même (plutôt qu’une interprétation obscure de celle-ci) nous mène directement à son point d’introduction.

Cela dit, 70 vulnérabilités, c’est beaucoup à traiter en une seule fois.

Bien souvent, les équipes de sécurité et de développement souhaitent commencer par se concentrer sur toutes les vulnérabilités graves qui peuvent être corrigées.

Nous pouvons facilement obtenir ce niveau de détail en tirant parti de l’option de sortie JSON et en filtrant les résultats avec l’utilitaire JSON en ligne de commande jq (notez que jq accepte parfaitement les retours à la ligne dans la commande) :

```
$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

[
  {
    "packageName": "curl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "7.52.1-5+deb9u7",
    "nearestFixedInVersion": "7.52.1-5+deb9u13"
  },
...  
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Integer Overflow or Wraparound",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Buffer Overflow",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  }
]
```

Et voilà ! Dans notre résultat final, 36 vulnérabilités sont répertoriées. Elles sont toutes de gravité élevée et disposent d’une correction, avec la commande Dockerfile correspondante et la version corrective. Nous devrions pouvoir les corriger à partir de là. Si vous ne connaissez pas la commande jq, cela peut sembler complexe. Voici donc un bref aperçu de ce que nous avons fait. Mais jq est très puissant et mérite que vous preniez le temps de l’apprendre :

Pour commencer, nous avons ajouté l’option de sortie --json à notre commande docker scan, puis nous avons utilisé jq pour effectuer les opérations suivantes :

• Sélectionner uniquement les vulnérabilités dans les résultats

• Ne conserver que les vulnérabilités corrigibles et celles dont la gravité est « élevée »

• Épurer les résultats en n’affichant que quelques champs de vulnérabilité

Conclusions

La sécurité des conteneurs est un vaste sujet. Même en nous limitant à la sécurité des images, nous devons examiner plusieurs vecteurs d’attaque. Pour sécuriser vos images, voici les points essentiels à retenir :

• Commencez par des images de base provenant d’un fournisseur de confiance. Utilisez des signatures numériques pour en vérifier l’authenticité.

• Dans la mesure du possible, privilégiez des images de base minimales, qui ne contiennent que les paquets essentiels du système d’exploitation et la version du framework de votre choix, puis ajoutez-y le reste.

• Analysez vos images à la recherche de vulnérabilités, tôt et souvent. Créez vos propres images de base approuvées, activement maintenues et conformes à toutes vos vérifications de sécurité, puis relancez l’analyse à chaque création d’image.

• Effectuez des analyses à plusieurs étapes du cycle de vie logiciel : sur les postes de travail, dans la CI, sur les images stockées dans les registres et sur les conteneurs/pods exécutés dans vos clusters.

• Lorsque vous choisissez des outils d’analyse, ne vous limitez pas à la liste des vulnérabilités qu’ils fournissent :

  • L’outil va-t-il au-delà du simple signalement des vulnérabilités et vous indique-t-il qu’une image de base plus récente ou plus adaptée est peut-être disponible ?

  • Si une compilation échoue en raison de vulnérabilités détectées, l’outil fournit-il aux développeurs et aux équipes DevOps suffisamment d’informations pour les corriger ?

  • L’outil offre-t-il la flexibilité nécessaire pour définir vos contrôles de sécurité ?

  • Une solution unique ne convient pas à tout le monde : vos développeurs auront probablement besoin de davantage d’outils dans une image que vous n’en autoriseriez en production. Vous pourriez donc utiliser des images différentes à chaque étape du cycle de développement. L’automatisation, la CI et les Dockerfiles adaptés à ces étapes permettent de mettre en place des contrôles de sécurité appropriés et de trouver le bon équilibre entre sécurité et productivité, pour en tirer le meilleur parti.

Pour commencer à sécuriser vos images de conteneurs avec Docker et Snyk, inscrivez-vous dès maintenant !