Aller au contenu principal

Scanner les vulnérabilités de conteneurs avec grype

· 6 minutes de lecture
Stéphane ROBERT

logo

Je viens de découvrir un autre outil de scan de vulnérabilités qui va peut-être remplacer voir compléter le travail fourni par trivy.

Cet outil répond au nom de grype. Il permet comme trivy de scanner des images de containers, des filesystems, mais aussi des SBOM (Software Bill of Materials). Ces SBOM sont générés avec un autre outil du même éditeur et répondant lui au nom de syft.

Pour rappel, certaines entreprises et administrations commencent à exiger de fournir ces SBOM. Un SBOM doit permettre d’identifier les composants des logiciels utilisés et doit contenir : leurs noms, leurs versions, leurs origines et leurs licences.

Installation de syft et grype​

L'installation peut se faire via un simple curl :

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/bin

Utilisation de Syft et Grype​

Ces deux produits fonctionnent de la même manière. Ils peuvent scanner le contenu d'une image de conteneur ou d'un répertoire à la recherche de vulnérabilités.

Ils prennent en charge les gestionnaires de package et les langages de développement suivant :

  • Alpine (apk)
  • C (conan)
  • C++ (conan)
  • Dart (pubs)
  • Debian (dpkg)
  • Dotnet (deps.json)
  • Objective-C (cocoapods)
  • Go (go.mod, Go binaries)
  • Haskell (cabal, stack)
  • Java (jar, ear, war, par, sar)
  • JavaScript (npm, yarn)
  • Jenkins Plugins (jpi, hpi)
  • PHP (composer)
  • Python (wheel, egg, poetry, requirements.txt)
  • Red Hat (rpm)
  • Ruby (gem)
  • Rust (cargo.lock)
  • Swift (cocoapods)

Créer des SBOM avec syft​

Syft permet de scanner les sources en indiquant simplement un des types suivant :

docker:yourrepo/yourimage:tag            use images from the Docker daemon
podman:yourrepo/yourimage:tag            use images from the Podman daemon
docker-archive:path/to/yourimage.tar     use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar        use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage                read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
singularity:path/to/yourimage.sif        read directly from a Singularity Image Format (SIF) container on disk
dir:path/to/yourproject                  read directly from a path on disk (any directory)
file:path/to/yourproject/file            read directly from a path on disk (any single file)
registry:yourrepo/yourimage:tag          pull image directly from a registry (no container runtime required)

Par exemple pour scanner le dossier contenant le code source d'une de mes applications :

syft dir:./
 ✔ Indexed .
 ✔ Cataloged packages      [210 packages]
NAME                           VERSION    TYPE
Jinja2                         3.1.2      python
PyYAML                         6.0        python
aiofiles                       0.8.0      python
...

yarl                           1.7.2      python
zipp                           3.7.0      python

Pour générer un fichier SBOM il suffit d'ajouter -o <format>=<nom_du_fichier> :

syft dir:./ -o github=test.json
 ✔ Indexed .
 ✔ Cataloged packages      [210 packages]

On retrouve bien en sortie un fichier de nomenclature au format désiré. Il est possible de demander de produire plusieurs formats dans la même commande en cumulant les arguments -o. Les formats pris en charge sont :

  • json
  • text
  • cyclonedx-xml
  • cyclonedx-json
  • spdx-tag-value
  • spdx-json
  • github
  • table
  • template

Il est possible de générer des fichiers en utilisant un template écrit en Go.

Rapport de scan de vulnérabilites avec grype​

Maintenant, nous pouvons regarder ce que propose grype. Commençons par le lancer sur une image de container :

grype docker:registry.gitlab.com/dockerfiles6/images/lastversion:2.4.5

grype docker:registry.gitlab.com/dockerfiles6/images/lastversion:2.4.5
 ✔ Vulnerability DB        [no update available]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [136 packages]
 ✔ Scanned image           [89 vulnerabilities]
NAME              INSTALLED                FIXED-IN         TYPE  VULNERABILITY     SEVERITY
apt               2.2.4                                     deb   CVE-2011-3374     Negligible
bsdutils          1:2.36.1-8+deb11u1                        deb   CVE-2022-0563     Negligible
...

perl-base         5.32.1-4+deb11u2         (won't fix)      deb   CVE-2020-16156    High
tar               1.34+dfsg-1                               deb   CVE-2005-2541     Negligible
util-linux        2.36.1-8+deb11u1                          deb   CVE-2022-0563     Negligible

Et oui une image debian.... sans commentaire.

On retrouve les mêmes que celles remontées par trivy. Donc plutôt rassurant. Comme pour trivy il est possible de l'exécuter sur un répertoire. Par exemple sur le même dossier que précédemment :

grype dir:./
 ✔ Vulnerability DB        [no update available]
 ✔ Indexed .
 ✔ Cataloged packages      [210 packages]
 ✔ Scanned image           [112 vulnerabilities]

NAME    INSTALLED  FIXED-IN  TYPE    VULNERABILITY   SEVERITY
docker  5.0.3                python  CVE-2019-16884  High
docker  5.0.3                python  CVE-2020-27534  Medium
docker  5.0.3                python  CVE-2021-21284  Medium
docker  5.0.3                python  CVE-2021-21285  Medium
docker  5.0.3                python  CVE-2019-13509  High
docker  5.0.3                python  CVE-2019-5736   High
docker  5.0.3                python  CVE-2019-13139  High
docker  5.0.3                python  CVE-2018-10892  Medium

trivy lui ne m'a pas remonté ces vulnérabilités. Intéressant. Par contre, il a détecté en plus la probable présence d'une clé privée. A suivre ....

Grype prend en argument les sources suivantes :

  • podman:yourrepo/yourimage:tag use images from the Podman daemon
  • docker:yourrepo/yourimage:tag use images from the Docker daemon
  • docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
  • oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
  • oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
  • singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk
  • dir:path/to/yourproject read directly from a path on disk (any directory)
  • sbom:path/to/syft.json read Syft JSON from path on disk
  • registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
  • att:attestation.json --key cosign.pub explicitly use the input as an attestation

On voit qu'il est possible de traiter les données créés par Syft. Testons:

grype sbom:./test.json
 ✔ Vulnerability DB        [no update available]
 ✔ Scanned image           [112 vulnerabilities]
NAME    INSTALLED  FIXED-IN  TYPE    VULNERABILITY   SEVERITY
docker  5.0.3                python  CVE-2018-10892  Medium
docker  5.0.3                python  CVE-2019-5736   High
docker  5.0.3                python  CVE-2021-21285  Medium
docker  5.0.3                python  CVE-2020-27534  Medium
docker  5.0.3                python  CVE-2021-21284  Medium
docker  5.0.3                python  CVE-2019-16884  High
docker  5.0.3                python  CVE-2019-13509  High
docker  5.0.3                python  CVE-2019-13139  High

Je vois tout de suite un intérêt. Imaginons que nous stockions toutes nos SBOMs de manière centralisée. Il serait donc, possible de relancer à tout moment grype sur l'ensemble de toutes les sboms. Cool le gain de temps est appréciable et cela ouvre la porte à pas mal de choses pour les équipes de sécurité.

Le rapport peut être stocké dans un fichier au format de votre choix avec l'option -o <format>=<nom_du_fichier> : table, cyclonedx, json, ou un template de votre conception.

Plus loin​

Pour moi ces deux outils sont indispensables et viennent compléter tous les autres outils que nous avons à notre disposition. Donc, ils vont venir en complément de trivy dans mes outils de CI.

D'ailleurs je vais compléter mon billet sur trivy car à l'époque de sa sortie il ne consommait que des images docker.