virli/tutorial/docker-internals/vulnerability-scan.md

\newpage

Analyse de vulnérabilité
========================

Nous avons vu jusqu'à présent que Docker nous apportait un certain degré de
sécurité d'emblée, au lancement de nos conteneurs. Cela peut sans doute
paraître quelque peu rassurant pour une personne chargée d'administrer une
machine hébergeant des conteneurs, car cela lui apporte des garanties quant à
l'effort de cloisonnement mis en place.

Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé
l'ensemble des problématiques de sécurité liées aux conteneurs ?

Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont
pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient
dans notre code ou celui d'une bibliothèque, accessible par rebond, ...

Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois
leur image créée et envoyée en production. Nos conteneurs doivent être
regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une
image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien
lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées est
mise à jour.

Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en
œuvre, pouvant mettre en péril tout un système d'information. Pour s'en
protéger, nous allons avoir besoin de réaliser à intervalles réguliers une
analyse statique de nos conteneurs.

![Scan de vulnérabilités sur le Docker Hub](hubvuln.png){ width=90% }

Selon une étude[^dockerhubvulnerability] réalisée sur les images du Docker Hub,
elles présenteraient en moyenne 180 vulnérabilités, beaucoup ne sont pas mises
à jour depuis trop longtemps et les vulnérabilités ont surtout tendance à se
propager à cause de l'usage d'une image parente pas à jour.

[^dockerhubvulnerability]: <https://www.enck.org/pubs/shu-codaspy17.pdf>

Une mesure efficace consiste à reconstruire régulièrement (et surtout
automatiquement) les images que l'on publie sur un registre, sans oublier de
mettre à jour l'image de base.

D'ailleurs, avez-vous vérifié qu'une mise à jour de l'image
`registry.nemunai.re/youp0m` n'était pas disponible depuis que vous avez
commencé à l'utiliser ? Docker ne vérifie jamais si une mise à jour des images
que vous avez précédemment téléchargées. Pensez donc régulièrement à appeler :

<div lang="en-US">
```
42sh$ docker image pull IMAGE
```
</div>


## Docker Scan

Pour faire face à ces problèmes de sécurité qui prennent de l'ampleur, le
Docker Hub, dans son modèle payant, permet d'analyser régulièrement ses images,
pour avoir une idée sur la nécessité de les reconstruire.

Un plugin existe pour réaliser des scans d'images présentes sur votre machine,
à travers les données du Docker Hub. Cela nécessite d'avoir un compte Docker,
si vous n'en avez pas, nous verrons dans la section suivante `trivy` qui permet
de réaliser ses scans directement sur notre machine, sans passer par un
intermédiaire.

::::: {.warning}

Par cette méthode, vous êtes limité à 10 scans par mois avec un compte gratuit.

:::::

### Installation du plugin

#### Windows et MacOS {-}

Avec Docker Desktop, le plugin est déjà installé. Il faut que vous vous soyez
préalablement connecté à votre compte Docker avec la commande `docker login`.

#### Linux {-}

Comme `docker scan` est un plugin, suivant la méthode d'installation que vous
avez suivie, il n'a pas forcément été installé. Si vous obtenez un message
d'erreur en lançant la commande, [voici comment récupérer le plugin et
l'installer manuellement :](https://github.com/docker/scan-cli-plugin#on-linux)

<div lang="en-US">
```
mkdir -p ~/.docker/cli-plugins
curl -L -s -S -o ~/.docker/cli-plugins/docker-scan \
    https://github.com/docker/scan-cli-plugin/releases/\
    latest/download/docker-scan_linux_amd64
chmod +x ~/.docker/cli-plugins/docker-scan
```
</div>

### Utilisation

Une fois le plugin installé et la licence du service acceptée, nous pouvons
commencer notre analyse :

<div lang="en-US">
```
42sh$ docker scan nemunaire/youp0m

Testing nemunaire/youp0m...

Package manager:   apk
Project name:      docker-image|nemunaire/youp0m
Docker image:      nemunaire/youp0m
Platform:          linux/amd64
Base image:        alpine:3.16.2

✓ Tested 15 dependencies for known vulnerabilities, no vulnerable paths found.

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

<div lang="en-US">
```
$ docker scan mysql

Testing mysql...

✗ Low severity vulnerability found in util-linux/libuuid1
[...]

✗ High severity vulnerability found in gcc-8/libstdc++6
  Description: Insufficient Entropy
  Info: https://snyk.io/vuln/SNYK-DEBIAN10-GCC8-469413
  Introduced through: apt@1.8.2.3, mysql-community/mysql-client@[...]
  From: apt@1.8.2.3 > gcc-8/libstdc++6@8.3.0-6
  From: mysql-community/mysql-client@8.0.26-1debian10 > gcc-8[...]
  From: mysql-community/mysql-server-core@8.0.26-1debian10 > gcc-8[...]
  and 7 more...
  Image layer: Introduced by your base image (mysql:8.0.26)

Package manager:   deb
Project name:      docker-image|mysql
Docker image:      mysql
Platform:          linux/amd64
Base image:        mysql:8.0.30

Tested 119 dependencies for known vulnerabilities, found 24 vulnerabilities

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

Ce dernier exemple est sans appel : `mysql` est une image officielle, et sa
dernière version à l'écriture de ses lignes contient pas moins de 24
vulnérabilités dont 9 *high* (pourtant corrigées dans des versions suivantes).


## Trivy

Le principal outil pour chercher des vulnérabilités connues dans les images
Docker est [`trivy`](https://www.aquasec.com/products/trivy/), édité par Aqua
security.

À partir des informations mises à disposition par les équipes de sécurité des
principales distributions, `trivy` va générer un rapport, pour chacune de nos
images, indiquant les vulnérabilités connues au sein de l'image.

L'outil se présente sous la forme d'un binaire ou d'une image Docker, prenant
un certain nombre d'arguments, notamment le nom de l'image à analyser.


### Utilisation

Tentons à nouveau d'analyser l'image `mysql` :

<div lang="en-US">
```
42sh$ docker run --rm aquasec/trivy image mysql
INFO Need to update DB
INFO Downloading DB... 100.00% 14.41 MiB p/s 2s
INFO Detected OS: oracle
INFO Detecting Oracle vulnerabilities...
INFO Number of language-specific files: 0

mysql (oracle 8.6)
==================
Total: 5 (UNKNOWN: 0, LOW: 0, MEDIUM: 4, HIGH: 1, CRITICAL: 0)
```
</div>

Les résultats sont un peu différents qu'avec `docker scan`, mais on constate
que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si
elles ne sont heureusement pas forcément exploitables directement.

Voyons maintenant s'il y a des différentes avec l'image `nemunaire/youp0m` :

<div lang="en-US">
```
42sh$ docker run --rm aquasec/trivy image nemunaire/youp0m
INFO Need to update DB
INFO Downloading DB... 100.00% 15.98 MiB p/s 1s
INFO Detected OS: alpine
INFO Detecting Alpine vulnerabilities...
INFO Number of language-specific files: 1
INFO Detecting gobinary vulnerabilities...

nemunaire/youp0m (alpine 3.16.2)
===================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)


srv/youp0m (gobinary)
====================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
```
</div>

Nous pouvons remarque que Trivy, en plus de faire l'analyse statique des
vulnérabilités de l'image, a aussi fait une analyse des dépendances du binaire
`/srv/youp0m`.

Trivy est en effet capable de rechercher des vulnérabilités par rapport aux
dépendances connues de certains langages : Python, PHP, Node.js, .NET, Java,
Go, ...


### Usage du cache

Pour éviter de surcharger les serveurs de distributions de la base de données
de vulnérabilités, nous devrions utiliser un cache pour faire nos
analyses. Préférez lancer `trivy` avec les options suivantes :

<div lang="en-US">
```
42sh$ docker run --rm -v /tmp/trivy-cache:/root/.cache/ aquasec/trivy \
         image IMAGE
```
</div>

### Format de génération du rapport

Lorsque nous appelons `trivy` directement, il génère un rapport au format texte
lisible directement dans notre terminal. Il peut être pourtant pratique de
pouvoir l'exporter pour l'afficher dans un navigateur (par exemple pour le
mettre à disposition des développeurs, lors d'une analyse automatique).

Pour ce faire, on peut ajouter les options suivantes à la ligne de commande de
notre conteneur :

<div lang="en-US">
```bash
--quiet --format template --template "@contrib/html.tpl"
```
</div>

En redirigeant la sortie standard vers un fichier, vous pourrez l'ouvrir dans
votre navigateur favori.

![Scan de vulnérabilités sur le registre Quay.io](quay-vulns.png){ width=80% }

## Clair