La plupart des plateformes s'arrêtent à la liste. Vulneo va jusqu'au bout : vous choisissez une action, les hôtes concernés sont mis à jour, et vous savez hôte par hôte ce qui s'est passé.
Entre le rapport du scanner et l'hôte à jour, il y a un export, un ticket, un outil de déploiement, une relance, et personne pour confirmer que c'est fait. C'est là que les semaines se perdent.
La liste change de mains et d'outil à chaque étape. Ce qui était urgent le lundi est encore ouvert le vendredi.
Sans filet, mettre à jour cent serveurs d'un coup fait peur, à raison. Alors on attend la prochaine fenêtre, puis la suivante.
L'auditeur demande quand et par qui la vulnérabilité a été corrigée. La réponse est dans trois outils et deux boîtes mail.
Dans la liste priorisée, une action regroupe tous les findings qu'un même correctif ferme. Vous voyez la part de risque qu'elle retire.
Vulneo propose le périmètre : les hôtes concernés, rien d'autre. Une autre personne approuve avant tout départ.
Quelques hôtes d'abord, en canari. S'ils passent, le reste suit. Sinon, la campagne s'arrête d'elle-même.
Un statut par hôte, et le finding ne se ferme que lorsque l'inventaire suivant confirme que la version a changé.
C'est la question que tout le monde pose, et elle est légitime. Vulneo est conçu pour qu'un correctif qui se passe mal reste un incident local, visible, et réversible.
Celui qui propose une campagne ne peut pas l'approuver. La décision est tracée, avec son auteur et son heure.
Une première vague sur un petit nombre d'hôtes. La généralisation n'a lieu que si tout est vert ; sinon, pause automatique.
Quand votre environnement le permet, un point de restauration est pris avant chaque hôte. Le retour arrière est à portée de clic.
Hôte réussi, hôte en échec, redémarrage à prévoir : vous le lisez sur la campagne, pas dans un journal à aller chercher.
Chiffres issus d'un périmètre de démonstration. Les vôtres sortent pendant la démonstration.
Plus d'export à transformer en tickets. L'action est là, le bouton aussi, et le résultat revient au même endroit.
Des délais de correction mesurés sur ce qui a réellement été déployé, pas sur ce qui a été demandé.
Qui a décidé, qui a approuvé, quand chaque hôte a été corrigé et comment on l'a vérifié : dans le journal, en une requête.
Le déploiement de correctifs est la partie de la plateforme qui évolue le plus vite. Nous préférons vous dire où nous en sommes plutôt que de tout promettre.
Les mises à jour de paquets système et de bibliothèques de langages sur vos serveurs Linux, depuis l'agent. Les hôtes sans agent peuvent être couverts par la sonde, dans un cadre que nous définissons avec vous.
Le périmètre s'étend à chaque version : nouveaux environnements, nouveaux types de correctifs, davantage d'automatisation entre la décision et le déploiement. En démonstration, nous vous dirons précisément ce qui s'applique à votre parc.
C'est pour cela que le déploiement commence par un canari sur quelques hôtes, qu'un point de restauration est pris avant chaque hôte quand votre environnement le permet, et que la campagne se met en pause d'elle-même au premier échec. Un correctif qui se passe mal reste un incident local et réversible.
Vous. Vulneo propose une action et un périmètre ; une personne les prépare, une autre les approuve. Rien ne part sans cette seconde validation, et elle est tracée.
Non. Vulneo couvre le chemin le plus court entre une vulnérabilité priorisée et l'hôte corrigé. Vos outils de déploiement gardent leur rôle pour le reste ; les deux cohabitent.
Le finding ne se ferme pas quand la commande a été envoyée, mais quand l'inventaire suivant de l'hôte confirme la nouvelle version. C'est cette confirmation qui sert de preuve.
Non. Il fait partie du palier Pro, avec les campagnes, l'approbation, le canari et le retour arrière. Nous ne vendons pas la correction séparément de la détection.
Une action choisie dans votre propre liste, un canari, une généralisation, la preuve. En quarante-cinq minutes.