NexTool Solutions

Votre instance GLPI est-elle exposée à des vulnérabilités déjà répertoriées sans que vous le sachiez ? Dans la plupart des parcs que nous reprenons en maintenance, personne ne peut dire immédiatement quelle CVE touche la version en production ni si PHP a les bons drapeaux de sécurité. Le module CVE Scan Vulnérabilités de NexTool croise la version installée avec des bases publiques de CVE et audite 17 points critiques de l'environnement en quelques secondes, en produisant un Security Score visuel.

Le problème

Les équipes de service desk qui exploitent GLPI ont rarement un processus formel pour suivre les vulnérabilités liées à la version en production. Le NVD (NIST) et la GitHub Advisory Database publient des CVE en continu, mais suivre cela à la main, version par version, est irréaliste pour ceux qui ouvrent et ferment aussi des tickets toute la journée.

Pire : la version du logiciel n'est que la moitié du risque. L'environnement PHP et la configuration du serveur introduisent des failles silencieuses - display_errors activé en production qui fuit chemins et stack traces, un cookie de session sans HttpOnly, l'absence de Content-Security-Policy ou de Strict-Transport-Security. Chacun de ces détails est une surface d'attaque qui n'apparaît en général qu'après l'incident, quand il est déjà trop tard.

Comment fonctionne CVE Scan

Au lancement du scan, le module détecte la version via la constante GLPI_VERSION et la croise avec une base dynamique de CVE construite à partir de trois sources :

• NVD / NIST - la source de référence pour le score CVSS et les métadonnées officielles de chaque faille.
• GitHub Advisory Database - liens d'advisory et détail des failles signalées par la communauté.
• Base statique de secours - garantit la couverture même lorsque les API externes sont indisponibles ou que la limite de requêtes est dépassée.

La fusion se fait par CVE ID : le NVD prime pour le CVSS, GitHub apporte les liens d'advisory. Un cache local est actualisé chaque jour par cron et à la demande à chaque exécution manuelle. En parallèle du croisement des CVE, le module exécute 17 vérifications de sécurité de l'environnement, réparties en quatre catégories : configuration PHP (8 checks), vérifications propres à GLPI (3), en-têtes HTTP (3) et autres (3), comme PHP en fin de vie. Le résultat devient un Security Score de 0 à 100, avec une plage de couleur - rouge pour critique, jaune pour modéré et vert pour sain - et chaque élément affiche son statut, la version qui corrige la faille et l'instruction de correction.

Ce qu'il voit et que GLPI natif ne montre pas

Ce que nous avons appris sur le terrain

En maintenance, le check qui échoue le plus souvent chez un client est session.cookie_secure - et c'est presque toujours une fausse alerte mal interprétée. GLPI est derrière un reverse proxy qui termine le TLS, donc PHP voit la connexion comme http et ne marque pas le cookie comme sécurisé. La correction n'est pas dans GLPI : il faut régler l'en-tête X-Forwarded-Proto sur le proxy et forcer HSTS en périphérie. Le deuxième plus fréquent est le répertoire install/ oublié après le setup. GLPI le signale bien sur l'écran de connexion, mais sur un parc de dizaines d'instances cet avertissement passe inaperçu - le score consolidé est ce qui oblige l'équipe à regarder. C'est pourquoi nous traitons CVE Scan comme un thermomètre, pas comme un verdict : il pointe l'endroit, mais la décision de corriger à la bonne source reste à celui qui exploite l'environnement.

Vérifier les mêmes points à la main

Avant d'installer quoi que ce soit, vous pouvez reproduire une partie du diagnostic directement sur le serveur. Voici précisément certains des points que le module audite dans PHP et sur le système de fichiers :

# Drapeaux PHP audites par CVE Scan (a executer sur le serveur GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'

# Permission du fichier d'identifiants de la base : doit etre 400 ou 440, jamais 644
stat -c '%a %n' /var/www/glpi/config/config_db.php

# Repertoire d'installation qui aurait du etre supprime apres le setup
test -f /var/www/glpi/install/install.php && echo 'ALERTE : install/ encore present - a supprimer'

# Version de PHP : alerter si elle est en fin de vie (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'

Le module automatise cela, ajoute le croisement avec les bases de CVE et conserve l'historique - mais lancer les commandes ci-dessus montre déjà pourquoi l'audit manuel ne passe pas l'échelle au-delà de deux ou trois instances.

Comment l'activer

1. Installez le plugin NexTool sur votre GLPI.
2. Allez dans Configuration > NexTool > Modules.
3. Repérez la carte CVE Scan Vulnérabilités, cliquez sur Installer puis Activer.
4. Ouvrez le module et cliquez sur Lancer le scan dans l'onglet des fonctionnalités.
5. Optionnel : saisissez un token GitHub et une clé API NVD dans l'onglet de configuration pour relever les limites de requêtes des bases externes.

Pour qui (et quand non)

Pour les administrateurs GLPI qui ont besoin d'un audit de sécurité rapide et récurrent, les équipes qui subissent des audits internes ou externes et ont besoin de preuves de l'état de l'environnement, et les responsables qui veulent suivre la posture de sécurité dans le temps via l'historique des scans. Ce n'est pas une solution miracle : il ne remplace pas un pentest, ne corrige rien tout seul et ne doit pas servir d'excuse pour reporter la mise à jour de GLPI. Si votre environnement dispose déjà d'un scanner d'entreprise (Nessus, Qualys) pointant sur le même hôte, CVE Scan est un complément léger et spécifique à GLPI, pas un concurrent.

Compatibilité

• GLPI : 10.x et 11.x
• Plan : FREE
• Plugin : NexTool 3.x ou supérieur

Étape suivante

CVE Scan Vulnérabilités fait partie de NexTool, le plugin modulaire pour GLPI. Découvrez les autres modules ou parlez à l'équipe pour une évaluation de sécurité complète de votre environnement.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe NexTool Solutions.