Paquet signalé vulnérable : vérifier les correctifs rétroportés
Reliez le paquet installé à l’avis du distributeur pour vérifier un correctif rétroporté, traiter un écart de scanner et conserver une conclusion limitée.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un scanner signale une bibliothèque ancienne. L’équipe système répond que le distributeur a déjà corrigé le problème sans changer la version amont affichée. Faut-il fermer le constat ou demander une nouvelle mise à jour ? Aucune de ces décisions ne devrait reposer sur le seul numéro visible dans une bannière.
La vérification utile relie une vulnérabilité déterminée, un paquet précis, son fournisseur et l’état réellement déployé. Voici une méthode d’investigation indépendante du scanner, illustrée par les documentations publiques de distributions Linux. Elle ne suppose ni que tous les anciens paquets sont corrigés, ni qu’un outil de détection se trompe systématiquement.
1. Identifier le composant réellement signalé
Notre recommandation : conserver le constat initial avec sa date, la méthode de détection, le composant supposé et la référence de vulnérabilité. Précisez si l’observation vient d’une bannière réseau, d’un inventaire authentifié, d’une image de conteneur ou d’un fichier. Ces observations n’offrent pas toutes la même précision sur le paquet installé.
Relevez ensuite l’identité complète du composant : nom du paquet, version complète, architecture, distribution et édition, origine du dépôt et ressource concernée. Distinguez la version effectivement installée de celle simplement disponible au téléchargement. Une capture d’un dépôt proposant une mise à jour ne prouve pas son installation.
Vérifiez aussi où le composant se trouve. Le paquet du système hôte, une copie dans un conteneur, un binaire installé manuellement et une bibliothèque embarquée dans une application sont des objets distincts. Une correction de l’un ne démontre pas que les autres ont été traités.
2. Comprendre ce que le rétroportage change à la preuve
Red Hat décrit le rétroportage comme l’application d’un correctif à une ancienne version distribuée. Sa documentation explique pourquoi une comparaison limitée au numéro amont peut alors produire des faux positifs. Cette pratique ne permet pas de déclarer corrigé un paquet sans retrouver la mise à jour correspondante. Source : Red Hat, rétroportage de correctifs
La FAQ sécurité Debian décrit également le choix de conserver une version stable et d’y appliquer les corrections nécessaires, plutôt que de remplacer systématiquement le logiciel par une nouvelle version amont. La référence utile reste le paquet corrigé annoncé pour la distribution concernée. Source : FAQ sécurité Debian
Nous recommandons de séparer deux questions : le fournisseur a-t-il publié une correction applicable, et cette correction est-elle présente sur la ressource examinée ? Une affirmation générale sur la politique du distributeur ne répond pas à la seconde. Une ancienne version amont n’est donc ni une preuve suffisante de vulnérabilité, ni une preuve de correction.
3. Relier l’avis au bon paquet et à la bonne distribution
Retrouvez l’avis officiel correspondant au problème signalé. Vérifiez les produits, versions de distribution et paquets qu’il couvre, les éventuelles conditions d’application et la version indiquée comme corrigée. Si plusieurs paquets binaires proviennent d’un même paquet source, faites confirmer leur correspondance plutôt que de rapprocher seulement des noms ressemblants.
Ubuntu publie des avis pour les problèmes corrigés dans ses paquets officiels et fournit des données OVAL par version de distribution. Ces éléments peuvent soutenir la vérification dans leur périmètre ; ils ne décrivent pas automatiquement une compilation tierce portant un nom similaire. Source : Ubuntu Security Notices
La version complète compte. La politique Debian distingue notamment l’époque, la version amont et la révision Debian, avec des règles de comparaison définies. Ne retirez pas ces éléments pour appliquer un simple tri de chaînes de caractères. Source : Debian Policy, champ Version
Notre recommandation : utiliser la comparaison prévue par l’écosystème du paquet, dans le contexte exact de l’avis. Ne comparez pas comme une même série des versions issues de distributions ou de dépôts différents. Si le composant est reconstruit, modifié ou fourni par un tiers, recherchez les éléments de ce fournisseur ; ne lui attribuez pas la correction du paquet officiel par analogie.
4. Vérifier le déploiement et les suites nécessaires
Nous recommandons de recueillir un inventaire récent sur la ressource exacte, puis de le rapprocher de l’avis. Conservez l’heure de collecte et l’identité de la machine ou de l’image. Un inventaire antérieur à la maintenance ne décrit pas nécessairement l’état actuel ; une preuve obtenue sur un autre nœud ne couvre pas toute une flotte.
Relisez les instructions de mise à jour et de remise en service du fournisseur. Si elles demandent un redémarrage de service, une reconstruction d’image ou une autre étape, vérifiez sa réalisation et son résultat. La présence d’un paquet corrigé sur disque ne doit pas être utilisée seule pour conclure sur le code encore exécuté par un processus.
Pour une application empaquetant sa propre copie du composant, demandez une preuve portant sur cet artefact et son déploiement. Pour un conteneur, vérifiez la version effectivement exécutée, pas uniquement l’image récemment construite. Ces contrôles doivent rester proportionnés au constat ; ils n’impliquent pas de lancer un test d’exploitation sur la production.
5. Résoudre l’écart avec le scanner sans masquer le reste
Si le constat persiste, nous recommandons de demander quelle donnée et quelle règle le produisent. Une détection fondée sur une bannière, une collecte d’inventaire périmée et une mauvaise correspondance de paquet appellent des corrections différentes. Conservez les observations qui soutiennent le désaccord au lieu de remplacer le constat par « faux positif » sans justification.
Exemple entièrement fictif : une alerte repose sur la version amont affichée par un service. L’inventaire récent identifie un paquet officiel dont la révision correspond à celle corrigée dans l’avis applicable. Après vérification des étapes de remise en service, le dossier peut conclure sur cette vulnérabilité, ce paquet et cette ressource. Il ne peut pas déclarer sûre une copie embarquée qui n’a pas été examinée.
Une exception éventuelle doit reprendre ce périmètre, son propriétaire et son motif de réexamen. N’excluez pas un produit entier parce qu’une occurrence a été expliquée. Si la provenance du composant ou la correction restent indéterminées, gardez ce statut et attribuez la prochaine recherche à un responsable.
6. Conserver une décision que l’on peut refaire
Une fiche de vérification devrait réunir le constat initial, l’identité complète du paquet, l’avis officiel, la comparaison applicable, l’observation du déploiement et les limites. Distinguez « correction publiée », « paquet installé », « remise en service vérifiée » et « couverture encore inconnue ». Ces états évitent de transformer une étape accomplie en résolution globale.
Pour valider votre méthode, utilisez des inventaires de test dont les résultats attendus sont connus : paquet antérieur au correctif, paquet corrigé conservant une ancienne version amont, paquet d’une autre distribution, copie tierce et inventaire périmé. Vérifiez qu’un statut indéterminé reste possible lorsque la preuve manque. Un numéro qui paraît plus récent ne doit pas remplacer la correspondance avec l’avis.
Enfin, recontrôlez la décision après un changement de dépôt, de distribution, d’artefact ou de règle de détection. La conclusion utile reste limitée et traçable : quel composant a été examiné, quel correctif s’y applique et quelle observation confirme son état ?