TECHNOLOGIES / OSV-Scanner
OSV-Scanner : les CVE de vos images et dépendances
OSV-Scanner cherche les vulnérabilités connues dans une image Docker ou un fichier de verrouillage, en interrogeant la base OSV.dev. Il tourne sur nos projets en pipeline planifiée, parce qu'une faille peut être publiée sur une image que personne n'a touchée.
Cette fiche documente ce qu'il scanne, à quel rythme, et les trois points de branchement en CI qui bloquent le plus souvent.
PRÉSENTATION
Qu'est-ce qu'OSV-Scanner ?
OSV-Scanner est un outil open source développé par Google. Il interroge OSV.dev, un agrégateur de vulnérabilités qui consolide les sources CVE, GHSA, PYSEC et les signalements de paquets malveillants de l'OpenSSF, dans un format commun à tous les écosystèmes.
Il analyse aussi bien les fichiers de verrouillage de dépendances que les images Docker complètes, couche par couche. Le scan est statique : il lit, il n'installe rien et n'exécute rien.
Le code de sortie vaut 0 si tout est sain et 1 dès qu'une vulnérabilité est détectée, ce qui rend l'intégration en CI immédiate. L'option --serve produit un rapport HTML lisible quand la sortie console ne suffit plus.
POURQUOI OSV-SCANNER
Ce qui en fait un scanner de CVE de référence
OSV-Scanner surveille les vulnérabilités connues même quand personne ne touche au projet. C'est l'un des outils qui font entrer la sécurité dans le cycle de maintenance évolutive plutôt que dans les chantiers d'urgence.
Une base ouverte et agrégée
OSV-Scanner interroge OSV.dev, qui consolide les CVE, les avis GitHub (GHSA), PYSEC et les signalements de paquets malveillants de l'OpenSSF. Une seule requête couvre tous les écosystèmes d'un projet.
L'image Docker entière
osv-scanner scan image analyse les paquets système de l'image construite, couche par couche. Le rapport distingue ce qui vient de l'image de base de ce que le Dockerfile a ajouté : on sait tout de suite s'il faut corriger le Dockerfile ou changer de base.
Les fichiers de verrouillage aussi
composer.lock, package-lock.json, yarn.lock, go.sum et des dizaines d'autres formats. Le même outil lit les dépendances applicatives et les paquets système, avec la même base derrière.
Statique, donc sûr
Le scan lit les fichiers sans jamais installer ni exécuter le moindre paquet. Face aux attaques de chaîne d'approvisionnement, où le code malveillant se déclenche à l'installation, c'est une garantie qui compte.
Un rapport HTML par couche
L'option --serve produit un rapport consultable dans le navigateur : synthèse par sévérité, vulnérabilités regroupées par couche, et pour chaque paquet la version corrigée quand elle existe.
Fait pour la CI
Code de sortie 0 si tout est sain, 1 dès qu'une vulnérabilité est trouvée, sortie JSON exploitable par jq, image Docker officielle. Le branchement dans une pipeline tient en un job.
NOTRE USAGE
Comment nous utilisons OSV-Scanner chez SmartBooster
Le scan porte sur les images Docker de l'environnement de développement à la production, à un rythme régulier découplé des commits.
Sur une pipeline planifiée, pas sur les merge requests
Une image validée hier peut être vulnérable aujourd'hui sans qu'aucun commit n'ait eu lieu : il suffit qu'une CVE soit publiée sur un paquet qu'elle embarque. La question n'est pas « ai-je introduit une faille ? » mais « en a-t-on découvert une depuis la dernière fois ? ». Le job est déclenché par un Schedule GitLab, hebdomadaire par défaut.
La cible est l'image qui tourne
Le scan porte sur l'image publiée dans le registre, celle qui est réellement utilisée, pas sur une image reconstruite pour l'occasion. Sinon on audite un artefact qui n'est pas le reflet de la réalité.
Le seuil de sévérité se filtre en aval
OSV-Scanner n'a pas d'option de seuil. On passe par --format json et un filtre jq sur les scores CVSS supérieurs ou égaux à 7 : seuls HIGH et CRITICAL font échouer le job. Le rapport complet reste en artefact 30 jours.
Livré par notre socle symfony-docker
make docker-scan-osv et make docker-scan-osv-html, à côté de docker-lint (Hadolint) et docker-scan-dockle, tous exécutés dans leurs propres images sans rien installer sur le poste. Industrialisé par symfony-docker.
COMPLÉMENTS
Ce que nous ajoutons à OSV-Scanner
OSV-Scanner ne dira jamais que l'image tourne en root ni que le Dockerfile est mal écrit. Nous ajoutons ces trois outils qui permettent d'aller plus loin pour sécuriser nos images.
Hadolint
Relit le Dockerfile source, avant le build : écriture, reproductibilité, bonnes pratiques. Il ne verra jamais une CVE.
Dockle
Inspecte l'image construite : utilisateur root, secrets dans une couche, sudo oublié. Il ne dira jamais qu'un paquet est vulnérable.
composer audit
Vérifie les CVE des dépendances PHP à chaque push, dans make qa. OSV-Scanner surveille en plus les paquets système de l'image, sur un autre rythme.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Ils ne regardent pas la même chose. composer audit lit composer.lock et ne connaît que les dépendances PHP. OSV-Scanner lit l'image Docker construite : la libc, OpenSSL, curl, l'interpréteur PHP lui-même et tout ce que l'image de base embarque. Une CVE sur zlib ne sera jamais vue par composer audit. Les deux tournent, chacun à son rythme : composer audit à chaque push, OSV-Scanner sur une pipeline planifiée.
Parce que les failles arrivent après le build. Une image validée hier peut être vulnérable aujourd'hui sans qu'aucun commit n'ait eu lieu, dès qu'une CVE est publiée sur un paquet qu'elle contient. Un scan déclenché uniquement par les modifications de code laisse donc passer l'essentiel des vulnérabilités. La pipeline planifiée pose la bonne question : en a-t-on découvert une depuis la dernière fois ?
Deux causes classiques. L'image officielle a pour entrypoint le binaire osv-scanner lui-même : GitLab attend un shell, il faut déclarer entrypoint: [""] sinon le job ne démarre pas. Et OSV-Scanner sort en 1 dès qu'il trouve la moindre vulnérabilité, même informative : sans capturer ce code avant le filtrage de sévérité, le job échoue sur des avis mineurs. Les autres codes de sortie restent traités comme de vraies erreurs.
OSV-Scanner n'a pas d'option de seuil de sévérité. On demande la sortie JSON et on filtre avec jq sur le score CVSS : à partir de 7, soit HIGH et CRITICAL, le job échoue. En dessous, la vulnérabilité figure dans le rapport archivé en artefact mais ne bloque rien. Ce seuil se discute avec le client, comme celui de nos scans ZAP.
Le rapport indique la couche qui a introduit le paquet et la version corrigée quand elle existe. Si le paquet vient de l'image de base, on monte de version d'image. S'il vient du Dockerfile, on corrige l'instruction. Si aucune version corrigée n'existe encore, on évalue l'exposition réelle et on trace le risque accepté. Dans tous les cas, la correction se planifie dans le lot courant de maintenance : le scan est là pour informer, pas pour créer une urgence.
Oui. C'est un outil open source publié par Google sous licence Apache 2, sans version payante. La base OSV.dev qu'il interroge est publique. La version 2.5.1 est sortie en août 2026.
Pour aller plus loin
Approfondir votre réflexion
Hadolint, Dockle et OSV-Scanner en détail, avec le job GitLab CI complet et les quatre pièges de sa mise en place.
Ce qu'est une CVE, comment elle est scorée, et comment lire ce qu'un scanner remonte.
Un scan de CVE n'a de sens que si les montées de version suivent. Notre méthode pour ne pas laisser la dette s'installer.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.