Pourquoi vérifier le serveur lui-même
Un scan de site web voit ce que le serveur montre au monde : en-têtes, fichiers exposés, TLS. Il ne peut pas voir qu'un paquet Composer à trois niveaux de profondeur, une dépendance npm du build ou la bibliothèque Python d'un worker en arrière-plan a une CVE publiée — et c'est précisément ce que les attaquants recherchent dès qu'un exploit est public.
La seule méthode fiable consiste à lister ce qui est réellement installé et à le comparer aux bases de vulnérabilités. C'est ce que fait cette vérification, avec OSV et la liste CISA des vulnérabilités exploitées activement (KEV).
Ce qui est vérifié
Le serveur est lu comme une pile, de bas en haut :
- Système d'exploitation : la distribution et le noyau.
- Bibliothèques système et logiciels installés : openssl, nginx, docker, redis…
- Langages et frameworks : PHP avec Laravel, JavaScript avec Vue, Python…
- Bibliothèques des langages : les paquets Composer, npm et PyPI de chaque application, directs et transitifs.
Avec --docker, chaque conteneur en cours d'exécution est lu aussi, sur place, sans exporter son image.
Comment vérifier
wpsbom est un binaire open source unique pour Linux et macOS. Il se contente de lire des fichiers et n'envoie rien sauf si vous le lui demandez.
curl -fsSL https://raw.githubusercontent.com/ice-s/wpsbom/main/install.sh | shIl ne peut pas deviner où se trouve votre code : indiquez donc chaque répertoire d'application avec --path, autant de fois que nécessaire :
sudo wpsbom scan / --path /srv/shop --path /srv/worker --docker \
--out-dir scans/ -o cyclonedx-jsonQuelques secondes plus tard, scans/ contient un fichier pour le serveur et un par image de conteneur. Connectez-vous ensuite, ouvrez Mon serveur depuis le menu du compte, nommez le projet, choisissez Serveur et déposez le fichier :

- Bibliothèques des applications uniquement, sans les paquets de l'OS :
--no-os. - Une seule image :
wpsbom scan --image acme/shop:1.4 -o cyclonedx-json=shop.cdx.json. - Les fichiers issus de syft, Trivy ou cdxgen fonctionnent aussi (CycloneDX ou SPDX JSON).
Lire les résultats
La pile logicielle résume le serveur : chaque bloc affiche ses paquets et ses vulnérabilités ouvertes par sévérité, et son bord gauche prend la couleur de la plus grave. Cliquez sur un bloc pour n'afficher que cette partie.

La liste des vulnérabilités est organisée de la même façon. Emplacement indique à quelle application appartient un paquet et s'il s'agit d'une dépendance directe ou transitive ; Corrigé dans donne la version et la commande à copier.

Que corriger en premier
- Exploitées (KEV) et Critiques : elles sont utilisées contre de vrais serveurs ; mettez à jour aujourd'hui.
- Dépendances directes de vos applications : les mettre à jour entraîne généralement des versions corrigées des dépendances transitives.
- Les paquets dev (outils de build) comptent moins sur un serveur de production, sauf si le build y est exécuté.
Après la mise à jour, scannez et importez de nouveau : la liste montre ce qu'il reste. Pour la garder à jour sans intervention manuelle, créez un jeton d'API dans Intégrations et laissez wpsbom envoyer le scan, par exemple depuis une tâche cron quotidienne :
export WPSBOM_TOKEN=wp_…
sudo -E wpsbom push / --project demo-web-01 \
--path /srv/shop --path /srv/worker --dockerFAQ
Watchpost se connecte-t-il à mon serveur ? Non. C'est vous qui lancez le scan ; seul le fichier que vous importez est lu.
Qu'est-ce qui est envoyé ? Les noms et versions des paquets ainsi que les chemins des fichiers de verrouillage. Ni code source, ni configuration, ni secrets. Le nom d'hôte est remplacé par un hash, le fichier importé lui-même n'est pas conservé, et les projets ne sont visibles que par votre compte.
Quels systèmes ? wpsbom lit les paquets Debian, Ubuntu et Alpine ainsi que les bibliothèques Composer, npm / yarn, PyPI, Go et RubyGems ; les bibliothèques Maven et NuGet sont aussi comparées lorsque le fichier provient d'un autre outil. Les paquets de l'OS sont listés mais pas encore comparés aux vulnérabilités.
Kubernetes ? wpsbom k8s s'exécute dans le cluster et relie chaque workload au scan de son image.
Ce vérificateur répond à une seule question. Un scan gratuit vérifie plus de 50 autres points visibles par tous — fichiers exposés, clés divulguées, TLS, en-têtes, DNS — et la vérification de votre domaine débloque plus de 200 contrôles approfondis.
Lancer un scan complet