Scanner les vulnérabilités de conteneurs avec Grype

Grype détecte les vulnérabilités connues (CVE) dans vos images conteneurs et votre code source en quelques secondes. Une seule commande suffit pour scanner une image Alpine Python et obtenir la liste des CVE triées par sévérité, avec les scores EPSS (probabilité d'exploitation réelle) et RISK pour prioriser vos corrections. Ce guide vous montre comment installer Grype, scanner vos images, interpréter les résultats et intégrer le tout dans votre pipeline CI/CD.

Ce que vous allez apprendre

Scanner une image conteneur : détecter les CVE avec scores EPSS et RISK
Scanner un répertoire source : identifier les dépendances vulnérables avant le build
Interpréter les résultats : comprendre sévérité, EPSS et colonnes de sortie
Bloquer les déploiements : utiliser --fail-on en CI/CD
Configurer Grype : fichier .grype.yaml, gestion de la DB, filtrage VEX
Ancrage SOCLE : ce guide met en oeuvre SOCLE-PKG-SCN-1, le scan de vulnérabilités des artefacts avant publication avec un gate bloquant

Dans quel contexte ?

Vous utilisez Grype dès que vous manipulez des images conteneurs ou du code applicatif avec des dépendances tierces :

Vous construisez des images Docker et voulez vérifier qu'elles ne contiennent pas de CVE connues avant de les pousser en registre
Vous développez une application Python, Node ou Go et voulez détecter les dépendances vulnérables dans votre requirements.txt, package.json ou go.mod
Vous mettez en place un pipeline CI/CD et avez besoin d'un gate de sécurité qui bloque automatiquement les déploiements à risque
Vous gérez des images en production et voulez un scan régulier pour détecter les nouvelles CVE publiées
Vous travaillez avec des SBOM (générés par Syft) et voulez les analyser pour trouver les vulnérabilités

Dans l'écosystème de la sécurité applicative, Grype joue un rôle complémentaire avec d'autres outils :

Syft génère le SBOM (inventaire des composants)
Grype scanne ce SBOM pour détecter les CVE
VEX filtre les faux positifs selon votre contexte

Installation de Grype

Linux

Installez Grype depuis un binaire officiel vérifié par empreinte SHA256, jamais via un script distant tiré de curl | sh. Récupérez l'archive et le fichier de checksums depuis les GitHub Releases d'Anchore, contrôlez l'empreinte, puis extrayez le binaire :

GRYPE_VERSION=0.116.0
cd /tmp
base="https://github.com/anchore/grype/releases/download/v${GRYPE_VERSION}"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_linux_amd64.tar.gz"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_checksums.txt"

# Vérifier l'empreinte SHA256 AVANT d'installer
grep "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" "grype_${GRYPE_VERSION}_checksums.txt" | sha256sum -c -
# -> grype_0.116.0_linux_amd64.tar.gz: OK

sudo tar -C /usr/local/bin -xzf "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" grype
grype version
# Application:         grype
# Version:             0.116.0
# Syft Version:        v1.48.0
# Supported DB Schema: 6

Anchore signe aussi ses artefacts avec cosign (fichiers grype_${GRYPE_VERSION}_checksums.txt.sig et .pem) : en CI, vérifiez cette signature pour une garantie supply chain de bout en bout.

macOS

Sur macOS, Homebrew gère la vérification d'intégrité et les mises à jour à votre place. Le tap anchore/grype reste nécessaire : la formule n'est pas publiée dans homebrew-core, un brew install grype seul échoue.

brew tap anchore/grype
brew install grype

Autres options

Ces deux méthodes servent des besoins précis. mise ou asdf conviennent quand vous devez figer une version de Grype par projet, au même titre que la version de Python ou de Go. L'image de conteneur évite toute installation sur les runners de CI, au prix d'une contrainte : le conteneur ne voit pas le daemon Docker de l'hôte, il ne peut donc pas scanner une image simplement construite en local. Passez-lui un SBOM, une archive docker-archive: ou une référence registry: qu'il ira chercher lui-même.

asdf-vm : asdf plugin add grype && asdf install grype latest
Docker : docker run --rm anchore/grype:v0.116.0 <image>

Épinglez le tag de l'image (v0.116.0) plutôt que latest : une CI qui suit latest change de version de scanner sans prévenir, et vos résultats deviennent non reproductibles d'un build à l'autre.

Utiliser Grype au quotidien

Grype analyse deux types de sources :

Images de conteneurs : scan de tous les packages installés (APK, DEB, RPM, binaires Go, dépendances Python/Node/Java...)
Répertoires source : scan des fichiers de dépendances (requirements.txt, package.json, go.mod, pom.xml...)

Écosystèmes supportés :

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)

Scanner une image conteneur

Le scan d'une image Docker est le cas le plus courant : Grype y voit à la fois les paquets du système (apk, deb, rpm) et les bibliothèques applicatives installées par-dessus. Dans la sortie ci-dessous, regardez d'abord la colonne FIXED IN : une ligne sans version corrigée signale une CVE que vous ne pouvez pas régler par une mise à jour, il faudra la traiter par configuration ou par VEX. Le -q supprime les journaux de mise à jour de la base et laisse uniquement le tableau, ce qui rend la sortie exploitable dans un script.

grype python:3.12-alpine -o table -q
# NAME           INSTALLED   FIXED IN                       TYPE    VULNERABILITY        SEVERITY  EPSS         RISK
# python         3.12.13     *3.13.14, 3.14.6, 3.15.0b2     binary  CVE-2026-7210        High      0.8% (52nd)  0.6
# python         3.12.13                                    binary  CVE-2026-11940       High      0.6% (45th)  0.5
# python         3.12.13     3.15.0                         binary  CVE-2026-15308       High      0.6% (43rd)  0.4
# pip            25.0.1      25.3                           python  GHSA-4xh5-x5gv-qwph  Medium    0.4% (35th)  0.2
# busybox        1.37.0-r31                                 apk     CVE-2025-60876       Medium    0.3% (20th)  0.2
# ... (35 détections, 33 CVE distinctes)

Détail du processus :

Chargement : Grype extrait les métadonnées de l'image (layers, packages)
Inventaire : Il identifie tous les packages : APK Alpine (musl, libssl), Python (flask, requests), binaires compilés
Comparaison : Chaque package est comparé à la base de vulnérabilités (NVD, GitHub Advisory, Alpine Security)
Scoring : Les CVE sont enrichies avec scores CVSS (gravité), EPSS (probabilité d'exploitation) et RISK (score combiné)
Affichage : Résultats triés par sévérité avec percentile EPSS

Colonnes de sortie :

Colonne	Signification
NAME	Package vulnérable
INSTALLED	Version installée
FIXED IN	Version corrigée (vide si pas de fix)
VULNERABILITY	Identifiant CVE ou GHSA
SEVERITY	Niveau CVSS : Critical, High, Medium, Low
EPSS	Probabilité d'exploitation réelle + percentile
RISK	Score de risque combiné (sévérité × exploitabilité)

Le score EPSS indique le percentile : "41st" signifie que 41% des CVE connues sont moins exploitées que celle-ci. Le score RISK combine la sévérité CVSS et l'EPSS pour donner une priorité actionnable.

Scanner un répertoire source

Le scan d'un répertoire source répond à une autre question : quelles dépendances déclarées sont vulnérables, avant même qu'une image existe. Grype lit les fichiers de verrouillage (requirements.txt, package-lock.json, go.sum, poetry.lock) et ne voit rien du système d'exploitation. Un même paquet peut apparaître plusieurs fois, une ligne par CVE le concernant : le nombre de lignes n'est donc pas le nombre de paquets à corriger.

Pour reproduire la sortie ci-dessous, créez un projet minimal avec trois dépendances Python volontairement anciennes :

mkdir projet-demo && cd projet-demo
printf "flask==3.0.0\njinja2==3.1.2\nrequests==2.31.0\n" > requirements.txt

grype dir:. -o table -q
# NAME      INSTALLED  FIXED IN  TYPE    VULNERABILITY        SEVERITY  EPSS         RISK
# jinja2    3.1.2      3.1.4     python  GHSA-h75v-3vvj-5mfj  Medium    1.0% (58th)  0.5
# jinja2    3.1.2      3.1.3     python  GHSA-h5c8-rqwp-cp95  Medium    0.9% (55th)  0.5
# requests  2.31.0     2.32.4    python  GHSA-9hjg-9r4m-mvj7  Medium    0.8% (54th)  0.4
# jinja2    3.1.2      3.1.5     python  GHSA-q2x7-8rv6-6q7h  Medium    0.5% (40th)  0.3
# flask     3.0.0      3.1.3     python  GHSA-68rp-wp8r-4726  Low       0.3% (26th)  < 0.1
# ... (9 détections pour 3 paquets)

Différence image vs source, sur les deux sorties ci-dessus :

Image python:3.12-alpine : 35 détections (paquets système Alpine + interpréteur Python + dépendances)
Source (dir:.) : 9 détections, uniquement des dépendances Python déclarées

L'écart ne traduit pas une différence de qualité de scan mais une différence de périmètre. Le scan de source ne verra jamais une CVE dans libssl3, et le scan d'image ne verra pas une dépendance listée dans requirements.txt mais jamais installée. Les deux sont complémentaires : le scan de source tourne en pre-commit ou dans l'IDE pour arrêter le problème avant le build, le scan d'image tourne en CI pour couvrir tout ce que la couche de base a apporté.

Grype prend en argument les sources suivantes :

grype podman:yourrepo/yourimage@sha256:...    Podman daemon
grype docker:yourrepo/yourimage@sha256:...    Docker daemon
grype docker-archive:path/to/image.tar        tarball Docker
grype oci-archive:path/to/image.tar           tarball OCI
grype oci-dir:path/to/yourimage               OCI layout directory
grype singularity:path/to/yourimage.sif       Singularity Image Format
grype dir:path/to/yourproject                 répertoire source
grype sbom:path/to/syft.json                  fichier SBOM
grype registry:yourrepo/yourimage@sha256:...  registre distant
grype purl:path/to/purl/file                  fichier PURL

Obtenir des informations sur les vulnérabilités

La commande explain approfondit la compréhension d'une CVE spécifique :

grype alpine:latest -o json -q | grype explain --id CVE-2026-45447

Sortie (condensée) :

[0000]  WARN grype explain is a prototype feature and is subject to change
CVE-2026-45447 from nvd:cpe (High)
Issue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.

Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.

Informations clés :

Package vulnérable : libcrypto3 et libssl3 (OpenSSL)
Sévérité : High
Type : use-after-free, du plantage à l'exécution de code à distance
Correction : mettre à jour Alpine pour récupérer la version corrigée d'OpenSSL

L'avertissement en tête de sortie est normal : explain reste une commande prototype côté Anchore, son format peut changer d'une version à l'autre. Ne bâtissez pas un script d'automatisation dessus, préférez la sortie JSON.

Choix du format de sortie

Grype produit plusieurs formats selon votre usage :

Pour l'humain :

table (défaut) : Tableau lisible avec colonnes NAME, INSTALLED, VULNERABILITY, SEVERITY, EPSS

Pour l'automatisation :

json : Toutes les métadonnées CVE (description, CVSS, EPSS, URLs, fix disponible, chemins de fichiers)
cyclonedx / cyclonedx-json : Standard CycloneDX 1.4 pour intégration Dependency Track

Pour la personnalisation :

template : Template Go personnalisé (exemple : générer un rapport Markdown)

Exemple JSON pour automatisation :

grype alpine:latest -o json -q > vulnerabilities.json
jq '{total: (.matches | length), high: [.matches[] | select(.vulnerability.severity == "High")] | length, medium: [.matches[] | select(.vulnerability.severity == "Medium")] | length}' vulnerabilities.json
# {"total": 33, "high": 16, "medium": 11}

Le format JSON est essentiel pour :

Filtrer les CVE avec jq ou scripts Python
Stocker les résultats historiques
Intégrer avec des plateformes comme Dependency Track

Fixer le niveau pour produire une erreur

Option --fail-on pour faire échouer le pipeline CI/CD si des vulnérabilités dépassent un seuil de sévérité :

grype python:3.12-alpine --fail-on high
# NAME     INSTALLED  FIXED IN                    TYPE    VULNERABILITY   SEVERITY  EPSS         RISK
# python   3.12.13    *3.13.14, 3.14.6, 3.15.0b2  binary  CVE-2026-7210   High      0.8% (52nd)  0.6
# python   3.12.13                                binary  CVE-2026-11940  High      0.6% (45th)  0.5
# ...
# [0002] ERROR discovered vulnerabilities at or above the severity threshold

Résultat : Grype renvoie le code retour 2, valeur documentée par l'aide de l'option (set the return code to 2 if a vulnerability is found with a severity >= the given severity). Un runner CI traite tout code non nul comme un échec, la distinction avec le code 1 compte surtout si vous scriptez la réaction : le code 1 correspond à une erreur d'exécution de Grype (image introuvable, base corrompue), le code 2 à des vulnérabilités trouvées au-dessus du seuil. Ne confondez pas les deux dans un if de pipeline, vous masqueriez une panne du scanner en la prenant pour un résultat de scan.

Configuration de Grype

Grype se configure via un fichier .grype.yaml pour personnaliser le comportement du scanner selon vos besoins. C'est utile pour standardiser les scans dans une équipe ou un projet.

Principaux réglages :

# Format de sortie par défaut, la clé attend une LISTE
output:
  - table  # ou json, cyclonedx-json

# Échouer selon sévérité (utile en CI/CD)
fail-on-severity: high  # options: negligible, low, medium, high, critical

# Filtrer uniquement les CVE corrigées (ignorer les not-fixed)
only-fixed: false

# Scope du scan pour les images
search:
  scope: squashed  # système de fichiers final, une fois les layers aplaties
  # scope: all-layers     # analyse toutes les layers (plus lent, plus exhaustif)
  # scope: deep-squashed  # squashed enrichi, contenu des archives inclus

# Base de données de vulnérabilités
db:
  auto-update: true  # vérifie la disponibilité d'une mise à jour à chaque exécution
  cache-dir: ~/.cache/grype/db
  max-allowed-built-age: 120h  # refuse une base construite il y a plus de 5 jours

# Intégration VEX pour filtrer les faux positifs
vex-documents:
  - ./vex/devops-status-api.vex.json
  - ./vex/global.vex.json

# Ignorer certains chemins (exemple : tests, vendor)
exclude:
  - "**/test/**"
  - "**/vendor/**"

Chemins de recherche (ordre de priorité) :

.grype.yaml (racine du projet)
.grype/config.yaml
~/.grype.yaml (configuration utilisateur)
~/.config/grype/config.yaml
/etc/xdg/grype/config.yaml (configuration système)

Vérifiez cette liste sur votre poste avec grype config locations, qui affiche les chemins dans l'ordre réel où Grype les cherche. Un .grype.yaml chargé se contrôle avec grype config --load : si votre réglage n'apparaît pas dans la sortie, c'est que le fichier n'a pas été lu ou que la clé est mal formée.

Exemple d'usage : créer .grype.yaml à la racine de votre projet pour que tous les développeurs utilisent les mêmes seuils de sévérité et les mêmes documents VEX.

Gérer la base de vulnérabilités

La base de vulnérabilités de Grype est cruciale : elle contient toutes les CVE connues provenant de NVD, GitHub Advisory Database, Alpine Security, etc. Elle est mise à jour quotidiennement par Anchore.

Vérifier l'état de la base :

grype db status
# Schema:    v6.1.9
# Built:     2026-07-23T07:03:49Z
# From:      https://grype.anchore.io/databases/v6/...
# Status:    valid

Informations clés :

Schema : Version du format DB (schéma v6 depuis Grype 0.88.0, qui a aussi déplacé l'URL de distribution vers grype.anchore.io)
Built : Date de génération (vérifiez qu'elle est récente)
Status : valid si tout est OK

Mise à jour manuelle :

grype db update
# No vulnerability database update available

Deux réglages distincts gouvernent ce comportement, et les confondre mène à des scans silencieusement obsolètes. db.auto-update (activé par défaut) fait vérifier la disponibilité d'une nouvelle base à chaque exécution, sans condition d'ancienneté. db.validate-age, également activé, refuse une base plus vieille que max-allowed-built-age, soit 120h (5 jours) par défaut : Grype s'arrête alors sur the vulnerability database was built X weeks ago.

Pour interroger la disponibilité d'une mise à jour sans rien installer :

grype db check
# Installed DB version v6.1.9 was built on 2026-07-23T07:03:49Z
# No update available

Si la base locale est corrompue ou dans un schéma incompatible, la remise à zéro passe par une suppression suivie d'un téléchargement complet. La version 6 de la base n'expose pas d'option --force sur grype db update :

grype db delete
grype db update

En CI/CD : la mise à jour auto peut ralentir les builds. Deux stratégies :

Cache avec expiration : conservez la base au maximum 4 jours, jamais une semaine. Au-delà de 5 jours, validate-age fait échouer le scan et vous perdez le bénéfice du cache
Mise à jour manuelle : grype db update dans un job séparé quotidien qui publie la base en artefact réutilisé par les jobs de scan

Taille de la DB : environ 200-300 Mo compressée, 1-2 Go décompressée. Elle est stockée dans ~/.cache/grype/db/.

Intégrer Grype dans un pipeline CI/CD

Intégrer Grype dans votre pipeline automatise la détection des vulnérabilités avant le déploiement en production. L'objectif : détecter tôt, corriger vite.

L'exemple suivant scanne l'image par son identifiant plutôt que par son tag. Deux builds successifs peuvent porter le même tag myapp tout en contenant des couches différentes : passer l'identifiant garantit que le rapport correspond bien à l'image que vous venez de construire. Notez le permissions: {} au niveau du workflow, les droits minimaux par job, et les actions épinglées par SHA : un tag comme @v4 est mutable, un attaquant qui compromet le dépôt de l'action peut le repointer vers du code hostile qui s'exécutera dans votre pipeline.

permissions: {}

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Build and get image ID
        run: |
          docker build -t myapp .
          echo "DIGEST=$(docker inspect myapp --format='{{.Id}}')" >> "$GITHUB_ENV"

      - name: Scan image
        run: |
          grype "myapp@${DIGEST}" \
            --fail-on critical \
            -o json > grype-report.json

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: grype-report
          path: grype-report.json

Stratégie de seuil :

--fail-on critical : Bloque uniquement les CVE critiques (CVSS ≥ 9.0)
--fail-on high : Bloque critical + high (CVSS ≥ 7.0)
--fail-on medium : Plus strict, peut générer beaucoup de faux positifs

Workflow recommandé :

Scan de répertoire (grype dir:.) lors du commit (pré-commit hook)
Scan d'image lors du build CI/CD
Fail-on critical pour bloquer les déploiements à risque
Upload JSON pour traçabilité et analyse historique
Intégration VEX pour filtrer les faux positifs validés

Optimisation cache. La clé de cache doit dépendre du temps, pas du contenu du dépôt : la fraîcheur de la base CVE n'a aucun rapport avec votre Dockerfile. Une clé calculée sur la date du jour force un téléchargement quotidien et vous garde loin de la limite des 5 jours.

- name: Calculer la clé du jour
  run: echo "DAY=$(date -u +%Y-%m-%d)" >> "$GITHUB_ENV"

- name: Cache Grype DB
  uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
  with:
    path: ~/.cache/grype
    key: grype-db-${{ env.DAY }}
    restore-keys: grype-db-

:::caution Fraîcheur de la DB

La base CVE de Grype est mise à jour quotidiennement. En CI/CD avec cache, régénérez-la au moins tous les 4 jours, sinon Grype refuse purement et simplement de scanner : l'option db.validate-age rejette toute base construite il y a plus de 120h. Un cache hebdomadaire casse donc le pipeline avant même de manquer une CVE.

:::

Dépannage

La grande majorité des incidents avec Grype vient de la base de vulnérabilités, pas du scanner. Réflexe numéro un devant un comportement anormal : grype db status. Si la ligne Status affiche autre chose que valid, arrêtez le diagnostic là et remettez la base en état avant d'incriminer l'image scannée.

Deux solutions du tableau passent par grype db delete suivi de grype db update, et c'est volontaire : la version 6 du schéma n'expose aucune option --force sur grype db update. La commande répond unknown flag: --force et ne fait rien. La suppression puis le retéléchargement sont le seul chemin de remise à zéro.

Symptôme	Cause probable	Solution
`the vulnerability database was built X weeks ago`	DB trop ancienne	`grype db update`
Aucune CVE détectée sur une image connue comme vulnérable	DB pas à jour ou scope trop restreint	`grype db delete` puis `grype db update`, et rescanner avec `--scope all-layers`
`unsupported database schema` après mise à jour	Incompatibilité schema DB	`grype db delete` puis `grype db update`
Scan très lent (> 30s)	Analyse all-layers sur image volumineuse	Passer en `scope: squashed` dans `.grype.yaml`
`explain` ne montre rien	Commande prototype, ID non trouvé	Vérifier l'ID exact dans la sortie JSON
Un réglage de `.grype.yaml` semble ignoré	Fichier non lu, ou clé attendue en liste	`grype config --load` pour voir la configuration réellement chargée

Ce que Grype ne prouve pas

Un scanner de vulnérabilités répond à une question précise et une seule : ce paquet, dans cette version, porte-t-il une CVE publiée ? Confondre cette réponse avec « l'artefact est sain » est l'erreur la plus coûteuse de la chaîne supply chain, parce qu'elle donne le sentiment d'avoir couvert un périmètre qu'on n'a pas approché.

Trois exigences voisines du SOCLE restent hors de portée de Grype :

SOCLE-PKG-SCN-2, le scan de malware et de secrets : une porte dérobée délibérément ajoutée ne porte aucun numéro de CVE, Grype ne la verra jamais. Ce périmètre revient à un scanner de secrets comme gitleaks ou TruffleHog.
SOCLE-PKG-SCN-3, la conformité des licences : Grype lit un inventaire, il ne juge pas les licences. C'est Syft qui les collecte.
SOCLE-PKG-IMG-2, l'exécution non-root et l'absence de shell : une image sans aucune CVE peut tourner en root avec un shell complet. Cette vérification relève d'un linter d'image comme Dockle ou d'une politique d'admission.

Un rapport Grype vert est donc une condition nécessaire de publication, pas une preuve de sécurité de l'artefact.

À retenir

Grype scanne images conteneurs, répertoires source et SBOM en quelques secondes
Les colonnes EPSS et RISK permettent de prioriser les corrections selon le risque réel d'exploitation, pas seulement la sévérité CVSS
--fail-on intégré en CI/CD bloque automatiquement les déploiements contenant des CVE au-dessus d'un seuil
La base de vulnérabilités se met à jour automatiquement toutes les 24h. En CI/CD, plafonnez le cache à 4 jours : au-delà de 120h, validate-age fait échouer le scan
Grype + Syft + VEX forment une chaîne complète : inventaire → détection → filtrage des faux positifs
Preuve attendue par le SOCLE (SOCLE-PKG-SCN-1) : un rapport de scan de vulnérabilités produit avant publication, accompagné d'un gate bloquant sur les criticités hautes. Le rapport JSON archivé en artefact de CI et le code retour 2 de --fail-on high constituent ensemble cette preuve

FAQ : questions fréquentes

Ces cinq questions couvrent ce qui décide de l'usage au quotidien : ce qu'est Grype, son positionnement face à Trivy, la façon dont il priorise les vulnérabilités avec EPSS, le réglage qui fait échouer un pipeline, et la réduction des faux positifs.

Grype, c'est quoi ?

Grype est un scanner de vulnérabilités open source d'Anchore. Il détecte les CVE connues dans les images conteneurs, le code source et les SBOM en quelques secondes, et trie les résultats par sévérité avec des scores EPSS et RISK pour prioriser.

Grype ou Trivy : lequel choisir ?

Grype (Anchore) est un scanner de vulnérabilités focalisé et rapide, idéal couplé à Syft pour la chaîne SBOM. Trivy (Aqua) est plus polyvalent : vulnérabilités, mais aussi secrets, IaC et configurations. Grype pour un scan vuln ciblé, Trivy pour un couteau suisse.

Comment Grype priorise-t-il les vulnérabilités (EPSS, RISK) ?

Grype enrichit chaque CVE avec l'EPSS (probabilité d'exploitation réelle, en percentile) et un score RISK qui combine la sévérité CVSS et l'exploitabilité. Vous corrigez d'abord les CVE à RISK élevé plutôt que toutes les High, ce qui réduit le bruit.

Comment faire échouer un pipeline CI/CD avec Grype ?

Utilisez l'option --fail-on (par exemple --fail-on critical ou --fail-on high). Grype renvoie un code de sortie 1 si une vulnérabilité atteint ou dépasse le seuil, ce qui fait échouer le job CI/CD et bloque le déploiement.

Comment réduire les faux positifs de Grype ?

Fournissez des documents VEX (clé vex-documents dans .grype.yaml) pour marquer les CVE non applicables à votre contexte : Grype les filtre alors du rapport. Vous pouvez aussi exclure des chemins (tests, vendor) via la clé exclude.

Prochaines étapes

Comprendre CVE, CVSS et EPSS Interpréter les scores de vulnérabilités et prioriser les corrections

Scanner avec Trivy Alternative à Grype pour le scan de vulnérabilités multi-cibles

Générer des SBOM avec Syft Créer l'inventaire des composants que Grype peut analyser

Filtrer les faux positifs avec VEX Documenter les CVE non applicables à votre contexte

Sécuriser la supply chain logicielle Vue d'ensemble SBOM, signatures, attestations et politiques

Plus d'infos

Site Officiel : https://anchore.com/grype/

Projet Grype : https://github.com/anchore/grype