Avant de supprimer des lignes, définir ce que l’on compte
Votre export Linux répète le même identifiant de vulnérabilité sur plusieurs paquets. Un second outil ajoute des lignes pour les mêmes installations. Comment consolider ce rapport sans perdre les systèmes à traiter ? La réponse détermine le nombre de dossiers à analyser, de tickets à ouvrir et de preuves à recueillir.
Les paquets dits « satellites » sont ici les sous-paquets issus ou associés à un paquet source. Pour les regrouper, séparez quatre niveaux : signalement d’un outil, dossier de qualification, occurrence sur un système et action de traitement. Une analyse peut être partagée par plusieurs occurrences lorsque leurs conditions techniques sont identiques.
Comprendre le paquet source et ses sous-paquets
Un fichier de spécification RPM peut définir plusieurs sous-paquets avec la directive %package. Le même ensemble de sources peut produire un exécutable, des bibliothèques et des fichiers de développement. Le lien au paquet source aide à organiser l’analyse, mais ne démontre pas que chaque sous-paquet contient la fonction vulnérable.
Conservez le nom du binaire, le paquet source établi, l’architecture, la provenance et la version complète. L’avis peut désigner un paquet source alors que la correction concerne certains binaires installés. Pour conclure à l’applicabilité, examinez les fichiers et fonctions concernés, ainsi que les prérequis de l’avis.
Comparer les versions selon les règles RPM
La comparaison RPM repose sur les composantes Epoch, Version et Release. Elle suit leurs règles d’ordre, qui diffèrent d’un tri alphabétique. Une comparaison de chaînes ou une version tronquée au numéro amont peut donc produire un verdict erroné sur l’état de correction.
Vérifiez également le produit, la branche et le canal auxquels s’applique le seuil de correction. Un numéro de construction ressemblant ne suffit pas à établir une provenance commune. Si la version est incomparable ou sa provenance inconnue, conservez ce point dans le dossier et demandez le complément nécessaire.
Exemple fictif : six occurrences et deux opérations
Le paquet source composant-demo produit composant-demo, composant-demo-libs et composant-demo-devel. Les trois paquets sont présents sur A et B, soit six occurrences. Deux outils remontent chacun six lignes pour DEMO-RPM-01. Vous obtenez douze lignes pour un seul signalement distinct.
La vérification établit que la fonction concernée est dans libs ; les autres contenus sont exclus sur preuve. Il reste deux occurrences applicables. Leur configuration identique permet une qualification commune, mais A et B ont des responsables et fenêtres de maintenance distincts. Le suivi conserve donc deux opérations et une preuve de mise à jour pour chaque système.
| Unité | Nombre dans cet exemple | Ce qui est conservé |
|---|---|---|
| Lignes de deux outils | 12 | Provenance et résultat d’origine |
| Occurrences de paquets | 6 | Système, paquet, version |
| Occurrences applicables | 2 | Deux installations de libs |
| Qualification mutualisée | 1 | Hypothèses communes vérifiées |
| Opérations suivies | 2 | Responsable et preuve par système |
Définir les conditions d’une analyse commune
La règle de regroupement précise ses clés et ses limites : versions différentes, architecture pertinente, configuration distincte ou provenance non couverte par le même avis. Plusieurs sources peuvent enrichir un dossier, en gardant leurs éventuelles contradictions. Le registre reste relié aux lignes d’origine pour permettre une vérification.
Chaque occurrence conserve son statut et son action. La correction d’un système ne clôture pas les autres. Si une occurrence disparaît à l’import, vérifiez la collecte ou un éventuel renommage avant de conclure au traitement. La clôture repose sur la preuve attendue : version corrigée, remplacement ou retrait confirmé.
Rendre la charge de travail et la couverture lisibles
Pour mesurer l’effet de la consolidation, suivez séparément les dossiers distincts, les occurrences et les actions. Vous pourrez vérifier quelles analyses ont été réutilisées et quels tickets redondants ont été évités. La baisse du nombre de lignes s’explique par le regroupement ; elle ne représente pas une baisse équivalente du risque.
À partir de vos inventaires de paquets, CyberLifeCycle rapproche les vulnérabilités, documente les qualifications mutualisables et suit les occurrences. Votre plan distingue le travail d’analyse partageable des opérations propres à chaque système. Les équipes disposent ainsi d’une charge plus lisible, avec les occurrences et les preuves nécessaires au suivi.
Sources consultées
- RPM 6.0, format de spécification et sous-paquetsConsulté le 30 octobre 2026.
- RPM 6.0, système de versions et comparaison EVRConsulté le 30 octobre 2026.