Meilleurs outils de gestion des vulnérabilités

Nous avons évalué quatre outils leaders de gestion des vulnérabilités selon 11 dimensions. Les résultats révèlent un marché où « la gestion des vulnérabilités » signifie quatre choses différentes pour quatre fournisseurs. Certains construisent des pipelines de détection axés d’abord sur les CVE ; d’autres suivent la disponibilité des correctifs comme proxy du risque ; l’un délègue explicitement l’analyse à des outils tiers.

Résultats du benchmark de gestion des vulnérabilités

Principales conclusions

• Automox et NinjaOne signalent les vulnérabilités en fonction de la disponibilité du catalogue de correctifs, et non de la correspondance de versions CVE-NVD. Si aucune mise à jour n’existe dans leur catalogue pour une version logicielle, l’outil indique « Aucune CVE connue » quel que soit le nombre réel de CVE. LibreOffice 7.1.8.1 (100 CVE documentées ou plus) et Firefox ESR 115.12.0 ont tous deux renvoyé « Aucune CVE connue » dans Automox pour cette raison. ManageEngine et Action1 utilisent des flux CVE indépendants et signalent les vulnérabilités, qu’un correctif soit disponible ou non.
• Aucun outil ne détecte les logiciels installés en dehors du gestionnaire de paquets. Les binaires extraits vers /opt/, compilés à partir des sources ou distribués par des fournisseurs en dehors de leurs dépôts de paquets officiels sont invisibles pour les quatre outils. ManageEngine et NinjaOne mettent en correspondance les CVE des paquets listés par dpkg. Action1 inventorie les paquets dpkg mais ne renvoie aucune donnée CVE pour eux sous Linux. Automox n’a aucune détection CVE indépendante.
• Le module VM de NinjaOne ne génère aucune alerte et ne possède aucun modèle de rapport. Le framework d’alertes répertorie 13 catégories dont Windows Patch Management, Bitdefender et CrowdStrike. Vulnerability et CVE n’en font pas partie. Le catalogue de rapports comprend un modèle Patch Compliance à 10 sections, mais aucun équivalent pour la gestion des vulnérabilités.
• Automox nécessite un scanner externe pour détecter les CVE. La page Remediations importe des exports CSV depuis Qualys, Tenable, Rapid7 ou CrowdStrike, puis met en correspondance ces CVE avec son catalogue de correctifs. Il n’effectue aucune détection indépendante.
• ManageEngine et Automox n’ont aucun canal d’alerte sortant. ManageEngine n’a aucune configuration SMTP, ni dans les paramètres globaux, ni dans les préférences par utilisateur, ni dans la livraison des rapports. La documentation web d’Automox mentionne le support de Slack, Teams et des webhooks, mais cela n’a pas été vérifié dans la console pendant les tests.”
• NinjaOne a désinstallé Automox deux minutes après son installation sur la même VM Windows. Le journal Activities a enregistré : « Logiciel désinstallé : “Automox Agent”, Utilisateur : Système. » La désinstallation était incomplète : l’enregistrement du service et les fichiers programme sont restés. Sous Linux, ManageEngine, Action1 et NinjaOne ont fonctionné côte à côte sans qu’un agent n’en supprime un autre.

Indicateurs mesurés

Latence de détection : un binaire notoirement vulnérable a été installé sur un endpoint propre, l’horodatage de fin d’installation étant enregistré à la seconde près. Le chronomètre s’est arrêté lorsque la CVE est apparue dans le panneau des vulnérabilités du produit.

Précision de détection : des logiciels aux historiques CVE bien documentés ont été installés sous Windows et Linux via trois chemins : MSI/EXE (suivi par le registre), dpkg (gestionnaire de paquets) et archive tar du fournisseur extraite vers /opt/ (en dehors du gestionnaire de paquets).

Empreinte sur l’endpoint : toutes les mesures ont utilisé pidstat au niveau processus pour capturer la RSS (resident set size) par processus, en excluant le cache de pages au niveau cgroup. Les mesures Windows ont utilisé Get-Counter (\Process(*)\Working Set - Private) échantillonné toutes les 5 secondes sur une fenêtre de 10 minutes. Le moteur d’analyse spawn-on-demand de ManageEngine a été mesuré séparément au repos et pendant une analyse active. Les quatre agents Linux ont fonctionné simultanément sur le même hôte Ubuntu 24.04 ; les mesures Windows ont été effectuées sur une VM Windows Server 2022 distincte.

Déploiement des correctifs : le temps de déploiement a été mesuré entre la confirmation dans l’interface et le signalement de la fin par le produit. L’état après déploiement a été vérifié directement sur l’endpoint via l’historique Windows Update afin de distinguer « binaire écrit sur le disque » de « correctif appliqué et actif », distinction importante lorsqu’un redémarrage est nécessaire pour terminer l’installation.

Accès à l’essai : chaque essai a d’abord été tenté avec une adresse Gmail, puis avec une adresse institutionnelle lorsque Gmail était refusé. Les étapes entre la page d’atterrissage et un tableau de bord utilisable avec des installateurs d’agents visibles ont été comptées. Le temps entre la soumission du formulaire et la connexion du premier agent a été enregistré.

Livraison des alertes : une règle d’alerte personnalisée a été créée dans chaque produit et déclenchée par un événement d’installation de logiciel. Le délai de livraison et la structure du contenu de l’e-mail ont été enregistrés. Lorsque les alertes cessaient de se déclencher, les journaux côté agent ont été inspectés pour identifier la cause.

Meilleurs outils de gestion des vulnérabilités

1. Gestion des vulnérabilités NinjaOne

NinjaOne est une plateforme UEM/RMM qui a ajouté un module VM en mars 2026. Sa gestion des correctifs est mature ; la couche de détection des vulnérabilités ne l’est pas.

NinjaOne

No permission devices

Accès à l’essai : NinjaOne est orienté commercial. Après l’envoi du formulaire d’essai, la réponse a été « Nous vous contacterons prochainement. » L’accès est arrivé sous la forme d’un technicien ajouté à un tenant existant partagé, plutôt que d’un environnement isolé neuf.

L’écran d’intégration a immédiatement affiché : « Vous n’avez pas les autorisations nécessaires pour gérer les appareils. Veuillez contacter votre administrateur système pour obtenir de l’aide. » Le déploiement des appareils était indisponible avec le rôle Technicien.

Couverture des appareils : le menu Ajouter un appareil couvre plus de domaines que tout autre outil testé : ordinateurs (Windows, Linux, Mac), appareils mobiles (Apple, Android), infrastructure virtuelle (Hyper-V, VMware), moniteurs cloud (ping, analyse de port, DNS, HTTP/HTTPS) et découverte réseau. Aucun autre outil de cette comparaison n’en approche.

Détail de l’appareil : chaque appareil dispose de graphiques horaires en direct pour le CPU, la mémoire, le disque et le réseau, ainsi qu’un inventaire matériel complet.

La section Details énumère les ports ouverts en ligne : RDP sur 3389, SMB sur 445, et 10 autres étaient visibles sans exécuter d’analyse distincte.

Le menu Tools fournit Remote Registry, Task Manager, File Browser et Service Manager accessibles depuis le navigateur, tous en direct. Le bureau à distance complet nécessite le téléchargement d’un client natif distinct.

Détection des CVE : l’inventaire logiciel a détecté Firefox en 35 secondes. L’onglet Vulnerabilities affichait 0 résultat après 5 minutes, après 30 minutes et après 3 heures, sur les appareils Windows et Linux et avec tous les filtres effacés. Le fichier de liste CVE côté agent est resté de 44 octets depuis l’installation jusqu’à plus de 5 heures, sans modification.

La corrélation CVE côté serveur n’a jamais été déclenchée pendant l’essai. Impossible de déterminer si cela reflète une restriction de l’offre d’essai ou une exigence de configuration non satisfaite. L’onglet Vulnerabilities s’est rempli avec 85 CVE environ 24 heures après l’installation de l’agent, la colonne Sources affichant « NinjaOne Patching », c’est-à-dire le propre catalogue de correctifs de l’outil, et non le NVD.

Intégration des alertes : la section Activities de la stratégie répertorie 13 catégories d’alertes : Bitdefender, CrowdStrike, SentinelOne, Webroot, ImageManager, Backup, ShadowProtect, Software, System, User, Windows, Windows Patch Management et Raid. Il n’existe aucune catégorie Vulnerability ou CVE. Le module VM ne produit aucune alerte.

Reporting : le catalogue de modèles de rapports comprend un modèle Patch Compliance de 10 sections couvrant les correctifs échoués, les correctifs en attente, les pourcentages de correctifs installés et l’activation des correctifs du système d’exploitation. Il n’existe aucun modèle Vulnerability Management.

Comportement de l’agent vis-à-vis des autres outils : NinjaOne s’est enregistré sur la VM Windows de test. À 11 h 31, le journal Activities a enregistré : « Logiciel désinstallé : “Automox Agent”, Version : “2.5.70”, Utilisateur : “<System>” » deux minutes après l’enregistrement, via une action système automatisée. La suppression était incomplète ; voir les Principales conclusions pour plus de détails.

Empreinte sur l’endpoint : mémoire maximale de l’agent Linux : 116 Mo. Windows : quatre processus totalisant environ 127 Mo de working set, 92 secondes de CPU sur trois heures.

NinjaOne est une plateforme UEM/RMM qui a ajouté un module VM. La couche d’inventaire logiciel de l’agent fonctionne bien ; la couche de corrélation CVE dépend d’un traitement côté serveur qui était inactif pendant la période d’essai.

Principales différences :

• L’inventaire logiciel est précis et rapide : Firefox 115.12.0 est apparu dans le tableau de bord 35 secondes après l’installation
• La corrélation CVE est restée inactive pendant tous les tests. Le fichier NinjaWPM-cve-patch-list.json est resté à 44 octets pendant plus de 5 heures ; l’onglet Vulnerabilities s’est rempli avec 85 CVE environ 24 heures après l’installation de l’agent, ce qui est incohérent avec le positionnement « en temps réel et piloté par l’IA »
• Prise en charge des types d’appareils la plus large : Windows, Linux, macOS, iOS, Android, Hyper-V, VMware, surveillance cloud par ping et découverte réseau
• Le module VM ne génère aucune alerte (aucune catégorie « Vulnerability » dans le framework d’alertes Activities) et n’a aucun modèle de rapport dédié
• Sous Windows, l’agent a supprimé Automox 2 minutes après l’installation via une règle de stratégie Windows Server, laissant des fichiers orphelins ; aucun comportement équivalent sous Linux

2. ManageEngine Vulnerability Manager Plus

ManageEngine VMP est le seul scanner de vulnérabilités spécialement conçu dans cette comparaison. La détection fonctionne indépendamment de la disponibilité des correctifs ; les vulnérabilités sont signalées même lorsqu’aucun correctif n’existe.

ManageEngine Vulnerability Manager Plus

Onboarding

Accès à l’essai. Libre-service, aucun contact commercial requis. Le formulaire d’inscription accepte Gmail. Après envoi, le tableau de bord se charge immédiatement avec un compteur de 30 jours. Une fenêtre de demande de démo apparaît, mais avec un bouton Ignorer visible ; ce n’est pas un obstacle. L’interface se charge en turc selon l’adresse IP, le seul outil de cette comparaison avec une localisation non anglaise. L’instance de la région UE est attribuée automatiquement.

Intégration : l’écran Getting Started affiche quatre étapes de workflow : Prérequis, Paramètres des correctifs, Déploiement et Workflow de gestion des correctifs. Trois des quatre sont axées sur les correctifs. Le cadrage est « détecter puis corriger », et non une détection en temps réel.

Tableau de bord : s’ouvre sur un onglet Vulnerabilities avec une matrice d’ancienneté des vulnérabilités, par tranches de gravité × ancienneté, montrant depuis combien de temps les résultats sont ouverts. Un flux Latest Security News affiche dans le panneau droit les avis de sécurité des fournisseurs en direct.

Le panneau gauche de la vue Systems segmente les appareils par état opérationnel : Très vulnérable, Vulnérable, Sain, Redémarrage en attente, Échec du déploiement des correctifs, Système sans contact d’agent, Système en fin de vie et Zero-day détecté. L’appareil est apparu dans la liste quelques secondes après l’installation de l’agent.

L’analyse initiale s’exécute en deux passes. Une bannière confirme que des résultats limités sont affichés en premier ; l’analyse complète se termine en quelques minutes. Les correctifs manquants sont passés de 0 à 8 entre les deux passes.

Détail de l’appareil : la vue de détail de l’appareil couvre plus de terrain que tout autre outil testé.

L’onglet Summary affiche quatre anneaux de gravité des menaces côte à côte : Correctifs, Vulnérabilités logicielles, Mauvaises configurations système et Mauvaises configurations du serveur Web. L’endpoint de test Windows Server 2022 standard a montré 7 correctifs manquants, 28 vulnérabilités logicielles et 54 erreurs de configuration.

L’onglet Software & Components liste chaque composant installé avec des compteurs Correctifs manquants, Correctifs installés et Vulnérabilités par ligne. Windows Server 2022 lui-même portait 16 vulnérabilités ; Curl pour Windows, livré avec l’image du système d’exploitation et non installé par l’utilisateur, en portait 10.

L’onglet Vulnerabilities est une liste au niveau des CVE avec Exploit Status, Patch Availability, score CVSS 3.0, Detected Version, Published Date et Supported Date par ligne. Les scores CVSS allaient de 4.3 à 9.9 sur l’endpoint standard.

L’onglet Patches classe les correctifs manquants en Security Updates, Optional, Third Party, Driver, Service Pack et BIOS, avec les actions Install/Publish Patches et Decline Patch directement intégrées.

L’onglet Security Config est une liste de vérification de durcissement de type CIS/STIG. Chaque ligne corrigible a un lien « Deploy Secure Configuration » : les constats se connectent directement à une remédiation en un clic. L’endpoint de test présentait 30 éléments, dont TLSv1.1 activé, BitLocker désactivé, Windows Firewall non détecté, des seuils de verrouillage de compte non configurés et un niveau d’authentification LAN Manager mal configuré.

L’onglet Port Audit associe chaque port ouvert au binaire responsable avec le chemin complet de l’exécutable. Le port 3389 correspond à svchost.exe, le port 445 à ntoskrnl.exeChrome et Edge sont listés séparément sur 5353.

Vue des menaces sur l’ensemble du parc : la navigation Threats couvre huit sous-sections dans tout le parc.

Les vues Vulnerabilities et Detected CVEs affichent les scores CVSS 3.0 et CVSS 2.0 dans des colonnes parallèles. Le produit conserve le CVSS 2.0 hérité pour les organisations qui s’appuient encore dessus.

System Misconfigurations agrège les lacunes de durcissement sur l’ensemble du parc avec une action « Deploy Secure Configuration » par ligne.

High Risk Software suit les dates de fin de vie. Windows Server 2022 apparaissait avec sa date EOL du 14 octobre 2031 et un compteur de 1 990 jours restants.

Manage Exceptions permet d’accepter des menaces spécifiques par groupe d’appareils. Aucune exception n’a été définie lors des tests ; l’infrastructure est présente.

Section Patches : la barre latérale gauche affiche des compteurs en direct : Manquants 9, Installés 3, Applicables 12, Pris en charge 106 973, Derniers 2 195. Chaque page de correctif contient des Quick Links intégrés au workflow, avec des guides pratiques, une base de connaissances et une FAQ, plutôt que des ressources accessibles séparément.

Le catalogue Supported Patches couvre 106 973 entrées d’Adobe, Microsoft, Mozilla, Splunk, Oracle et d’autres. La vue Latest Patches affiche 2 195 entrées récemment ajoutées, triées par date de publication. Decline Patch bloque des correctifs spécifiques par groupe d’appareils. Upload Pending accepte des correctifs personnalisés pour les logiciels hors catalogue.

Déploiement des correctifs : l’assistant de déploiement couvre : opération Installer ou Désinstaller (rollback intégré), déployer directement ou publier sur le Self Service Portal, sélecteur de stratégie de déploiement, date « Forcer le déploiement après » pour l’application des SLA et ciblage délimité par Remote Office et par ordinateur individuel.

Une mise à jour de définitions Defender a été déployée lors du test et s’est terminée avec le statut Succeeded et la remarque « Cette version existe déjà. » Le produit a détecté que le correctif avait déjà été appliqué et ne l’a pas réinstallé. La nouvelle tentative automatique en cas d’échec est réglée par défaut sur 2 tentatives.

Gestion du parc d’agents. La section Agent affiche l’état de santé des agents sur l’ensemble du parc, notamment l’actualité des versions, l’heure du dernier contact, l’état de synchronisation AD, la gestion des bureaux distants et la stratégie des ordinateurs inactifs.

Empreinte sur l’endpoint : cinq processus au repos, RAM combinée au repos d’environ 83 Mo. Le moteur d’analyse dcpatchscan n’apparaît que pendant les analyses, pas au repos. Pendant une analyse, il a consommé environ 160 Mo de RAM et 100 % d’un cœur de CPU sous Windows, contre environ 144 Mo et 16 % d’un cœur sous Linux. La conception spawn-on-demand maintient l’empreinte au repos bien en dessous des lignes de base continues de NinjaOne (116–127 Mo) et d’Action1 (51 Mo).

Latence de détection : Scan Now manuel : 5 à 6 minutes. Cycle automatique : fixé à 90 minutes, non configurable par l’utilisateur. Les nouvelles entrées du flux CVE se propagent en jusqu’à 25 heures (synchronisation quotidienne de la base plus un cycle de rafraîchissement de 90 minutes). La page Admin > Agent Settings n’a pas de champ d’intervalle de rafraîchissement ; les demandes d’ajout restent ouvertes sur le forum officiel sans résolution.

Alerte et notification : aucun canal d’alerte sortant n’existe à aucun niveau : pas de SMTP dans Global Settings, pas de préférence de notification par utilisateur, pas de planification de rapports ni de livraison par e-mail. La page Audit > Alerts enregistre les événements internes (perte de contact de l’agent, correctifs échoués, nouveaux endpoints) mais ne peut pas les router vers l’extérieur.

Reporting : 16 rapports prédéfinis ou plus, répartis en six catégories (Patch, System, APD, Configuration, SSP, Threat). Pas de générateur de rapports personnalisés. Sélecteur de colonnes et filtres disponibles dans les rapports prédéfinis. Aucun préréglage de plage de dates. Export : PDF, CSV, XLSX. Une fenêtre de clause de non-responsabilité RGPD exige une confirmation avant chaque export. Aucune livraison planifiée ni par e-mail.

Principales différences :

• 11 modules dans un seul produit : Vulnerability Assessment, Compliance, Patch Management, Network Device scanning, Security Configuration Management, Zero-Day Mitigation, Web Server Hardening, High-Risk Software Audit, Antivirus Audit, Port Audit et Reporting
• Catalogue de 106 973 correctifs ; options de déploiement cloud et sur site ; instance SaaS de la région UE
• Le cycle d’analyse automatique est fixé à 90 minutes et n’est pas configurable par l’utilisateur (demandes de fonctionnalité non résolues sur le forum) ; le nouveau flux CVE met jusqu’à 25 heures à se propager (synchronisation de la base + un cycle de rafraîchissement)
• Aucun canal d’alerte sortant : SMTP est absent à chaque couche de configuration

3. Automox

Automox est une plateforme d’automatisation des correctifs, pas un scanner de vulnérabilités. Sa capacité de gestion des vulnérabilités repose sur l’import des résultats de scanners Qualys, Tenable, Rapid7 ou CrowdStrike plutôt que sur une détection CVE indépendante.

Automox

Trial access screen

Accès à l’essai : essai de 15 jours, aucune carte de crédit requise. Gmail est refusé ; une adresse e-mail professionnelle est obligatoire. Après l’envoi, le parcours ajoute deux étapes avant le tableau de bord : un écran de connexion distinct et une 2FA obligatoire par e-mail. Le mot de passe doit comporter au minimum 12 caractères, le plus strict des quatre outils. Instance globale unique à console.automox.com, aucune option régionale.

Installation de l’agent : la fenêtre Add Devices affiche l’UUID de la clé d’accès, une liste déroulante de systèmes d’exploitation, un bouton Download Installer et la ligne de commande d’installation silencieuse équivalente : Automox_Installer-2.5.70.msi ACCESSKEY=<uuid>. Un seul binaire, une seule clé, le flux d’installation le plus simple des quatre outils testés.

L’installateur effectue un contrôle de santé post-installation en ligne avant de se fermer : démarrage du service, test du démon, rapport IRS (Installation Result Service). Il ne se ferme qu’après avoir confirmé « Configuration réussie ! », ce qui élimine l’ambiguïté sur la connexion réelle de l’agent.

L’appareil est apparu dans la liste Devices en 1 à 2 minutes avec l’étiquette « Recently Added ».

Détail de l’appareil : le détail de l’appareil comporte quatre onglets : Summary, Health, Network et System. Aucune stratégie n’a été attribuée à l’installation ; l’agent a été enregistré dans le groupe Default sans calendrier de correctifs attaché. ManageEngine applique automatiquement une portée d’analyse par défaut ; Automox exige l’attribution explicite d’une stratégie avant que quoi que ce soit ne s’exécute.

Inventaire logiciel et langage de gravité : la liste Software au niveau de l’appareil utilise des valeurs Severity empruntées au catalogue de mises à jour Microsoft : Critical, Unknown ou « No Known CVEs ». Il n’y a pas de score CVSS NVD. La colonne Latest Version est vide pour toutes les lignes ; Automox suit l’existence d’une mise à jour, pas la version amont. Days Exposed mesure depuis combien de temps un correctif est en attente, et non depuis combien de temps une CVE a été publiée.

Tableau de bord : le principal KPI est la matrice Outstanding Patch Count : lignes de gravité (Critique / Élevée / Moyenne / Faible / Inconnue) × colonnes d’ancienneté (90 jours et plus, 61-89, 31-60, 16-30, ≤15 jours). Indicateurs Device Troubleshooting : Redémarrage requis, Échecs de tentative de mise à jour, Déconnecté plus de 30 jours, Non compatible. Aucun nombre de CVE, aucun score de gravité des vulnérabilités nulle part dans le tableau de bord.

Architecture des stratégies : trois types de stratégies : Patch Policy (avec les sous-types Advanced, Patch All, Patch All Except, Patch Only, Manual Approvals, Severity), Required Software Policy et Worklet. Il n’existe pas de type Vulnerability Scan Policy ni de stratégie basée sur les CVE. La section Schedule propose un bouton radio Patch Tuesday qui s’aligne automatiquement sur le cycle de publication du deuxième mardi de Microsoft.

Catalogue Worklet : les Worklets sont des modèles de scripts shell pour des tâches de configuration. Les catégories sont System Preferences, Security et Software Lifecycle. Il n’existe aucune catégorie Vulnerability.

Page Remediations : le signal architectural central. La page Remediations sous Automate n’a qu’une action : Import. Le filtre CSV Provider liste Generic Report, CrowdStrike, Qualys, Rapid7 et Tenable Vulnerability Management. Les colonnes du tableau sont Patchable Vulnerabilities, Unmatched Vulnerabilities et Unknown Devices. Automox met en correspondance la sortie d’un scanner tiers avec son propre catalogue de correctifs et montre quelles CVE il peut remédier. Il n’effectue pas sa propre détection CVE.

Manage > Software : inventaire global du parc. La vue Software au niveau du parc ajoute un filtre « Vulnerability or CVE-ID », confirmant que les données CVE existent dans le système à un certain niveau. Cependant, la colonne Severity affiche encore des catégories de métadonnées KB, et non des scores CVSS. Les colonnes Days Exposed, Ignored et Impacted sont disponibles pour le triage au niveau du parc.

Agent Linux : l’agent Linux a inventorié 746 paquets. La liste Software affiche les colonnes Installed Version, Available Version, Days Exposed, Severity, KEV List et EPSS. Les colonnes KEV et EPSS sont vides pour toutes les entrées ; elles existent dans le schéma mais ne sont pas renseignées. Severity reflète le signal du catalogue de correctifs, pas le NVD.

Angles morts du catalogue de correctifs : Firefox ESR 115.12.0 sous Windows affichait Installed 115.12.0, Available 140.10.2, Days Exposed 9, Severity « No Known CVEs » ; environ 25 versions publiées et des milliers de CVE séparent ces deux versions, mais le catalogue ne porte aucun signal CVE pour cet écart de version. LibreOffice 7.1.8.1 sous Linux (14 paquets installés, 100 CVE NVD documentées ou plus) affichait tous les paquets comme « Installed », avec Available Version vide et Severity vide. L’éditeur est passé de la branche 7.1 à la série 24.x ; aucune entrée de mise à jour n’existe donc dans le catalogue, et l’outil ne renvoie aucun signal de vulnérabilité.

Empreinte sur l’endpoint : pic de l’agent Linux : 8.8 Mo, le plus léger des quatre outils testés, malgré l’absence de revendication marketing sur l’empreinte. L’empreinte Windows n’a pas été mesurée : la stratégie de NinjaOne a supprimé l’agent Automox 2 minutes après l’enregistrement de NinjaOne sur la même VM, de sorte qu’aucune ligne de base Windows n’a été capturée.

Principales différences :

• Automate → Remediations : accepte les exports CSV de Qualys, Tenable, Rapid7, CrowdStrike ou d’un format générique ; met en correspondance les CVE avec les éléments corrigibles et affiche les compteurs Patchable et Unmatched
• Les libellés Severity sont empruntés aux classifications du catalogue de mises à jour Microsoft (Critical / Unknown / No Known CVEs), et non aux scores CVSS du NVD
• La détection par catalogue de correctifs produit des angles morts systématiques : LibreOffice 7.1.8.1 et Firefox ESR 115.12.0 ont tous deux renvoyé « No Known CVEs » malgré des centaines de CVE documentées, car aucune mise à jour de catalogue n’existe pour ces branches de version
• Agent le plus léger du groupe avec un pic de 8.8 Mo sous Linux — bien qu’il ne fasse aucune revendication marketing sur l’empreinte
• Trois types de stratégies : Patch Policy (avec une planification compatible Patch Tuesday), Required Software Policy et Worklet (modèles de scripts shell/PowerShell)
• L’essai exige une adresse e-mail professionnelle ; Gmail refusé

4. Action1

Action1 est une RMM cloud-native dotée d’un pipeline de vulnérabilités Windows performant. Sous Linux, il inventorie les paquets et suit les écarts de version, mais ne produit aucune sortie CVE. Les deux comportements selon le système d’exploitation sont architecturalement différents et doivent être évalués séparément.

Action1

Onboarding

Accès à l’essai : libre-service, Gmail accepté, aucun contact commercial. Après l’envoi du formulaire, un code de confirmation arrive par e-mail ; sa saisie mène directement au tableau de bord avec les installateurs d’agents prêts. Aucun assistant d’intégration, aucun formulaire de demande d’essai, aucun délai d’attente.

Installation de l’agent Windows : l’installateur pèse 6.9 Mo et s’exécute en 67 secondes. Un e-mail de confirmation arrive immédiatement après, et le panneau affiche : « L’agent a été installé avec succès. Votre endpoint est maintenant connecté au cloud Action1. »

Installation de l’agent Linux : l’agent Linux pèse 2.3 Mo (.deb) et s’installe en 5 à 6 secondes via une seule commande curl + apt. L’ID d’organisation est intégré dans le paquet ; aucune configuration post-installation n’est nécessaire. Trois voies de déploiement sont proposées : Interactive (pour les primo-utilisateurs), Unattended et Direct. RPM est également disponible pour les systèmes de la famille Red Hat. Après l’installation, l’agent a détecté une mise à niveau du noyau en attente et a correctement signalé l’endpoint Linux comme « Redémarrage requis », en lisant l’état du système d’exploitation spécifique à la distribution plutôt qu’en appliquant une logique Windows à Linux.

Tableau de bord : sans déclencheur d’analyse manuel, 114 vulnérabilités et 3 mises à jour manquantes sont apparues quelques minutes après la mise en ligne de l’agent Windows. Le tableau de bord s’articule autour de deux widgets de triage : une jauge Vulnerability Remediation Compliance avec des bandes SLA (Critique : 1 à 7 jours, Élevée : 8 à 30 jours, Moyenne : 31 à 90 jours, Faible : 90 jours et plus) et une matrice Vulnerabilities to Remediate Deadline Breakdown montrant la gravité × le statut de dépassement des SLA. La même disposition est répétée pour les mises à jour. Une bannière marketing de l’offre gratuit et des boutons de partage social apparaissent également sur le tableau de bord.

Liste des vulnérabilités et priorisation des CVE : la page Vulnerabilities affiche l’ID CVE, le score CVSS, le drapeau CISA KEV, la date de publication, le statut de remédiation, le logiciel vulnérable (avec le chemin de version complet) et le nombre d’endpoints affectés. CISA KEV est une colonne de premier plan qui fait remonter les CVE activement exploitées dans la nature, un signal de triage plus fort que le seul CVSS. EPSS est absent.

Panneau de détail des CVE : chaque CVE ouvre un panneau latéral avec trois onglets : Endpoints (machines affectées avec un bouton Start Remediation), Vulnerable Software (logiciels affectés par plateforme) et Details. L’onglet Details comprend le score de base CVSS, l’Impact Score, l’Exploitability Score, la décomposition des sous-vecteurs CVSS sous forme lisible, un drapeau d’association à un ransomware, des liens multi-sources (NVD, NVD++ via VulnCheck, avis du fournisseur) et une échéance de remédiation automatiquement calculée en fonction de la gravité. Les CVE critiques reçoivent un SLA de 7 jours ; les CVE moyennes à élevées reçoivent 30 jours, calculés rétroactivement à partir de la date de publication de la CVE.

Latence de détection : Firefox ESR 115.0esr a été installé avec un indicateur silencieux, et l’horodatage de fin d’installation a été enregistré à la seconde près. L’agent a téléversé l’inventaire logiciel vers le cloud à T+4 minutes 33 secondes ; le cloud a accusé réception 1 seconde plus tard ; la liste Vulnerabilities s’est remplie avec les CVE de Firefox en 11 minutes après l’installation. L’agent utilise un intervalle d’interrogation de 5 minutes. Le label marketing « temps réel » est inexact ; « quasi temps réel / interrogation toutes les 5 minutes » est la description correcte. Aucun déclencheur d’analyse manuel n’est requis, ce qui le distingue des outils à analyse planifiée.

Détection CVE sous Linux (absente) : un paquet Firefox ESR 102.15.1 délibérément vulnérable (EOL depuis septembre 2023, 50 CVE non corrigées ou plus) a été installé via dpkg. L’agent a détecté l’installation en 66 secondes et a envoyé la version correcte au cloud. La charge utile cloud affichait : "CVE": "", "Security Severity": "Unspecified". La page Vulnerabilities affichait « No vulnerable software ». La même version de Firefox sous Windows produisait 11 CVE ou plus, avec des scores CVSS de 9.8 à 10. L’agent Linux d’Action1 est un suiveur d’écarts de version : il enregistre la version installée, la version la plus récente et la disponibilité des mises à jour, mais n’effectue aucune recherche dans une base de CVE pour les paquets Linux.

Déploiement des correctifs : deux flux parallèles existent. Le flux piloté par les vulnérabilités suit : détail CVE > Start Remediation > assistant en 3 étapes. Trois stratégies sont disponibles : Deploy Updates, Uninstall Software et Document Compensating Controls. La troisième est notable : elle permet de documenter l’acceptation du risque pour les logiciels qui ne peuvent pas être corrigés. Le flux piloté par les mises à jour via Update Approval ajoute le partage de fichiers P2P sur LAN pour les agences, l’orchestration des redémarrages (redémarrage automatique avec une fenêtre popup configurable côté utilisateur et un délai d’expiration) et la possibilité de désactiver entièrement les mises à jour natives de Windows afin que seuls les correctifs approuvés par Action1 se déploient. Ces capacités n’existent que dans le flux piloté par les mises à jour ; l’assistant piloté par les vulnérabilités ne les propose pas.

Délai de déploiement du correctif pour KB5082142 : 1 minute entre Run Now et le statut Success. Cependant, « Success » dans le moteur d’automatisation signifie que le binaire a été écrit sur le disque, et non que le correctif est actif. Sans redémarrage, la page Vulnerabilities continuait d’afficher la CVE corrigée comme Overdue, car le système d’exploitation n’avait pas encore appliqué le changement. Le moteur d’automatisation a qualifié l’opération de succès ; le scanner de vulnérabilités continuait d’afficher la CVE comme Overdue, ce qui est le comportement correct puisque le correctif nécessite un redémarrage pour prendre effet. Après redémarrage, la CVE a été retirée de la liste.

Alertes et notifications : les alertes reposent sur les rapports : un utilisateur s’abonne aux changements (Created / Deleted / Modified) dans les données d’un rapport nommé. Les e-mails d’alerte arrivent rapidement et contiennent des champs structurés : Vendor, Version, Install Type et Installed For. Le champ destinataire n’accepte qu’une seule adresse e-mail ; il n’y a pas de canal Slack, Teams ou webhook. Un mécanisme de suppression silencieuse existe : après le Nième déclenchement de la même règle dans un intervalle de temps, la règle cesse de se déclencher sans aucune indication dans l’interface. L’état de suppression n’est visible que dans le journal local de l’agent. Les utilisateurs qui attendent des alertes après le franchissement du seuil de suppression n’ont aucun moyen de découvrir la cause depuis l’interface.

Empreinte sur l’endpoint : mesurée sur 10 minutes pendant un cycle d’installation de Firefox, d’analyse et d’évaluation des alertes : CPU moyen 0.013 %, CPU maximal 1,56 % au moment du déclenchement du cycle d’interrogation, RAM stable à 51.7 Mo avec une bande de 0.14 Mo sur toute la fenêtre, entrées/sorties disque proches de zéro sauf pour de brèves écritures de cache d’analyse. La revendication « zéro impact sur l’endpoint » est étayée par la mesure. Aucun test de charge synthétique lourde n’a été exécuté.

Reporting : le générateur de rapports propose deux types (Summary avec regroupement, Simple pour les tableaux plats), un sélecteur de colonnes, une étape de filtre, une livraison planifiée, Subscribe, l’export CSV et l’export PDF. Cinq catégories de rapports intégrées incluent Vulnerability Management avec cinq sous-rapports : Select Vulnerabilities, All Critical Vulnerabilities, Documented Compensating Controls, Known Exploited Vulnerabilities et Vulnerability Summary. Ce sont tous des vues de l’état actuel. Il n’existe pas de rapport intégré « Fixed CVEs Over Time » ni « Patch History by CVE ». Une CVE corrigée est retirée de la liste ; elle ne passe pas à un état résolu. Reconstituer quelle CVE a été fermée à quelle date nécessite de croiser manuellement Automation History, qui souffre lui-même d’un problème de pollution de l’historique dû aux entrées Run Now en double.

Principales différences :

• Détection Windows en ≤11 minutes à partir de l’installation de l’agent (interrogation toutes les 5 minutes) ; téléversement install-to-cloud mesuré à 4 minutes 33 secondes
• Panneau de détail CVE : CVSS + drapeau CISA KEV + association ransomware + SLA basé sur la gravité (Critique 7 jours, Moyenne/Élevée 30 jours, automatiquement calculé à partir de la date de publication) + liens multi-sources (NVD, NVD++, avis du fournisseur)
• Agent Linux : 2.3 Mo .deb, installation en 5 à 6 secondes, systemd automatiquement activé ; RPM également disponible. Inventorie les paquets dpkg en ~66 secondes mais ne produit aucune sortie CVE ; la charge utile de l’agent renvoie "CVE": "", "Security Severity": "Unspecified". L’installation de Firefox 102 EOL sous Linux a laissé la liste Vulnerabilities vide.
• Empreinte de l’agent vérifiée par pidstat : 51.7 Mo stable, 0.013 % de CPU en moyenne, pic de 1,56 % pendant l’analyse
• Notifications d’alerte limitées à une seule adresse e-mail ; pas de Slack, Teams ou webhook ; les règles d’alerte cessent silencieusement de se déclencher après N déclenchements, sans indication dans l’interface
• Reporting : Custom Builder + 5 catégories de sous-rapports VM (Select / Critical / Compensating / KEV / Summary) + Schedule + Subscribe ; aucun rapport intégré « Fixed CVEs Over Time »

Méthodologie

Endpoints : Windows Server 2022 Standard 21H2 (Build 20348.3207) et Ubuntu 24.04.4 LTS (noyau 6.8.0-111). Les quatre agents ont fonctionné simultanément sur l’hôte Linux. Sous Windows, NinjaOne et Automox ont été installés séquentiellement sur la même VM.

Logiciels vulnérables : Firefox ESR 115.12.0, 7-Zip 19.00, Edge 148 (Windows) ; Node.js 18.19.1, vsftpd 3.0.5, Apache 2.4.58, LibreOffice 7.1.8.1, archive tar du fournisseur /opt/firefox-115.0esr/ (Linux).

Mesure : pidstat (RSS au niveau processus et CPU), Get-Counter (compteurs de performances Windows), pywinrm et paramiko (exécution de commandes à distance). Les métriques au niveau cgroup ont été exclues pour éviter l’inflation due au cache de pages.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

FAQ

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dogan2026,
  author = {Dogan, Sedat and Sezer, Sena},
  title  = {{Meilleurs outils de gestion des vulnérabilités}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/vulnerability-management-tools}},
  note   = {AIMultiple. Consulté le 16 septembre 2026}
}

Sedat Dogan

CTO

Suivre

Sedat est un leader en technologie et en sécurité de l’information avec 20 ans d’expérience en développement logiciel, infrastructure réseau et cybersécurité. Sedat :
- A 20 ans d’expérience en tant que hacker white-hat et gourou du développement, avec une expertise approfondie des langages de programmation et des architectures de serveurs.
- Est conseiller d’administration auprès d’un VC qui investit dans des entreprises technologiques en phase de démarrage et chez Ödeal, une plateforme de paiement numérique régionale servant 125 000 commerçants.
- A dirigé l’infrastructure technologique et la cybersécurité de sept élections nationales, et a été reconnu au Hall of Fame de la cybersécurité par des leaders technologiques mondiaux dont Twitter.

Voir le profil complet

Recherche effectuée par

Sena Sezer

Analyste sectorielle

Suivre

Sena est analyste sectorielle chez AIMultiple. Elle a obtenu sa licence à Bogazici University.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire