Sentrix

Services · Implémentation

Vulnérabilités et correctifs : réanalysés pour confirmer

Analyse, priorisation selon l'exploitabilité et déploiement des correctifs, avec une réanalyse indépendante avant de fermer un ticket : fermé n'est pas corrigé.

Pourquoi c'est important

Un ticket fermé n'est pas la même chose qu'une vulnérabilité corrigée. Un correctif peut échouer silencieusement, s'appliquer à la mauvaise version ou être annulé par un changement ultérieur, et un système de tickets affichera quand même « résolu », à moins qu'on ne réanalyse réellement pour le confirmer.

Correctifs qui échouent silencieusement

Un déploiement de correctif peut signaler un succès dans l'outil alors que la vulnérabilité sous-jacente reste exploitable.

Tickets fermés sur la foi

Un ticket marqué résolu par la personne qui a appliqué le correctif n'équivaut pas à une vérification indépendante.

Régressions après coup

Une reconstruction, un retour en arrière ou une réinstallation d'image ultérieure peut discrètement réintroduire une vulnérabilité déjà corrigée.

Angles morts de l'analyse

Un actif ajouté hors de votre processus normal de provisionnement peut ne jamais être inclus dans la portée de l'analyse.

Ce qui nous distingue

Nous réanalysons pour confirmer, pas seulement pour fermer le ticket. Nous ne faisons pas que déployer des correctifs et fermer des tickets : nous revenons réanalyser pour confirmer que chaque vulnérabilité est réellement fermée, pas seulement marquée résolue, et vous remettons une action précise pour tout ce qui revient ouvert.

  • Vérification des correctifs : confirmée par une réanalyse indépendante, pas seulement par le ticket fermé.
  • Constats rouverts : suivis lorsqu'une vulnérabilité corrigée réapparaît après une reconstruction ou un retour en arrière.
  • Portée de l'analyse : révisée pour les actifs qui pourraient avoir échappé à la couverture normale.
  • Priorisation : revérifiée selon l'exploitabilité actuelle, pas seulement le score de gravité initial.

Exemples de constats de validation

Exemples illustratifs ; ils ne décrivent pas un client en particulier.

  • Élevé : une vulnérabilité critique marquée « corrigée » il y a trois semaines est toujours exploitable à la réanalyse. Action : réappliquer le correctif, confirmer que la bonne version a été ciblée, et réanalyser avant de fermer.
  • Élevé : quatre serveurs sont revenus à un état vulnérable après un retour en arrière d'instantané le mois dernier. Action : recorriger les serveurs concernés et ajouter une étape de vérification post-retour en arrière au processus.
  • Moyen : cinq actifs provisionnés hors du processus standard sont absents de la portée de l'analyse. Action : ajouter les actifs à la portée de l'analyse et confirmer que la réconciliation de l'inventaire se fait régulièrement.
  • Faible : un constat de gravité moyenne datant de deux mois n'a pas de propriétaire de correction documenté. Action : assigner un propriétaire et une date cible, puis confirmer la fermeture par une réanalyse.

Ce que vous obtenez

Analyse couvrant tout le parc

Une analyse des vulnérabilités sur votre infrastructure, vos applications et vos environnements cloud, avec une portée révisée pour inclure les actifs provisionnés hors du processus standard.

Priorisation fondée sur le risque

Des vulnérabilités priorisées selon leur exploitabilité actuelle et votre contexte d'affaires, avec un propriétaire et une date cible pour chaque constat.

Correctifs testés et déployés

Des correctifs testés par étapes avant un déploiement large, planifiés autour de vos fenêtres de maintenance.

Fermeture confirmée par réanalyse

Un ticket ne ferme qu'une fois la correction confirmée par une réanalyse indépendante ; les constats qui reviennent ouverts sont suivis jusqu'à leur fermeture réelle.

Un bilan avec une action par constat rouvert

Chaque vulnérabilité toujours exploitable, chaque actif hors portée et chaque constat sans propriétaire reçoit une action précise.

Notre démarche

  1. Analyse et découverte. Analyse automatisée sur l'ensemble de votre environnement (réseaux, applications, actifs cloud) pour identifier les vulnérabilités, les mauvaises configurations et les correctifs manquants, avec une portée réconciliée à l'inventaire des actifs.
  2. Priorisation selon le risque. Corrélation des vulnérabilités avec l'exploitabilité actuelle et votre contexte d'affaires, pour prioriser la correction selon le risque réel.
  3. Correction coordonnée. Plan de déploiement des correctifs et des mesures de mitigation, testés par étapes, avec automatisation lorsque possible et planification autour de vos fenêtres de maintenance.
  4. Réanalyse et bilan. Réanalyse indépendante de chaque correction avant la fermeture, suivi des constats rouverts, puis remise du bilan avec une action précise pour tout ce qui revient ouvert.

Adapté à votre environnement et à votre tolérance au risque

Analyse continue, priorisation basée sur le risque, déploiement automatisé de correctifs, réanalyse post-correction : la fréquence d'analyse est typiquement continue ou hebdomadaire pour les actifs critiques, avec un balayage complet à cadence régulière.

Après le mandat

Un mandat d'implémentation est un engagement défini. L'analyse continue, le triage et le suivi des correctifs avec des cibles de délai sont offerts via les opérations de sécurité gérées, en boucle fermée. La correction des failles est aussi l'un des 13 contrôles du niveau 1 du PCCC (03.14.01) et un domaine de CAN/DGSI 104 ; ce mandat livre le contrôle et sa preuve. Les postes et serveurs analysés relèvent du service postes et serveurs pour leur EDR et leur durcissement.

Les vulnérabilités que vous connaissez sont celles que vous pouvez corriger.

Parlons de votre processus actuel d'analyse et de correction.

Nous contacter

Questions fréquentes

À quelle fréquence effectuez-vous les analyses ?
La fréquence d'analyse est adaptée à votre environnement et à votre tolérance au risque : typiquement continue ou hebdomadaire pour les actifs critiques, avec un balayage complet à cadence régulière. La portée de l'analyse est aussi révisée pour repérer les actifs provisionnés hors du processus standard, qui échappent souvent à la couverture normale.
Le déploiement de correctifs causera-t-il des interruptions ?
Nous testons les correctifs par étapes avant un déploiement large, et planifions les changements en production selon vos fenêtres de maintenance. Après un retour en arrière, une reconstruction ou une réinstallation d'image, une étape de vérification est ajoutée au processus pour qu'une vulnérabilité déjà corrigée ne soit pas réintroduite en silence.
Pourquoi réanalyser si le ticket est fermé ?
Parce qu'un correctif peut échouer silencieusement, s'appliquer à la mauvaise version ou être annulé par un changement ultérieur, et qu'un système de tickets affichera quand même « résolu ». Un ticket marqué résolu par la personne qui a appliqué le correctif n'équivaut pas à une vérification indépendante ; chez nous, un ticket ferme seulement une fois la correction confirmée par une réanalyse.
Comment priorisez-vous les vulnérabilités ?
Selon l'exploitabilité actuelle et votre contexte d'affaires, pas seulement le score de gravité initial. La priorisation est revérifiée à mesure que le paysage des menaces évolue, chaque constat reçoit un propriétaire de correction et une date cible, et les constats rouverts après une reconstruction ou un retour en arrière sont suivis séparément jusqu'à leur fermeture confirmée.
Cela peut-il devenir un service géré continu ?
Oui. Le mandat d'implémentation met en place le processus (analyse, priorisation, déploiement, réanalyse) et se termine par un bilan. L'analyse continue, le triage et le suivi des correctifs avec des cibles de délai sont ensuite offerts via nos opérations de sécurité gérées, un processus en boucle fermée où un constat n'est clos qu'après réanalyse.

Parlons de votre programme de conformité.

Dernière mise à jour : 2026-09-17