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.