Define what you count before deleting rows
A Linux export repeats the same vulnerability identifier across several packages. A second tool adds rows for the same installations. How can you consolidate without losing systems requiring treatment? The answer determines assessment cases, tickets and evidence to collect.
Here, “satellite” packages mean subpackages built from or associated with a source package. Separate four levels when grouping: tool finding, assessment case, system instance and treatment action. One assessment can cover several instances when their technical conditions are identical.
Understand source packages and their subpackages
An RPM spec file can define multiple subpackages with %package. The same source set can produce an executable, libraries and development files. The source-package link helps organise analysis but does not prove every subpackage contains the vulnerable function.
Retain binary name, established source package, architecture, provenance and full version. An advisory may name a source package while the fix concerns particular installed binaries. Examine affected files, functions and advisory prerequisites before deciding applicability.
Sources: RPM 6.0: spec format and subpackages
Compare versions using RPM rules
RPM comparison uses Epoch, Version and Release according to ordering rules that differ from alphabetical sorting. String comparison or truncating a version to its upstream number can therefore produce an incorrect fix-status verdict.
Also verify the product, branch and channel covered by the fixed-version threshold. Similar build numbers do not establish shared provenance. If versions cannot be compared or provenance is unknown, retain that uncertainty and request the missing information.
Fictional example: six instances and two operations
Source package composant-demo produces composant-demo, composant-demo-libs and composant-demo-devel. All three are installed on A and B: six instances. Two tools each report six rows for DEMO-RPM-01, producing twelve rows for one distinct finding.
Verification establishes that the affected function is in libs; the other contents are excluded with evidence. Two applicable instances remain. Their identical configuration allows a shared assessment, but A and B have different owners and maintenance windows. Tracking therefore retains two operations and update evidence for each system.
| Unit | Count in this example | What is retained |
|---|---|---|
| Rows from two tools | 12 | Provenance and original result |
| Package instances | 6 | System, package, version |
| Applicable instances | 2 | Two libs installations |
| Shared assessment | 1 | Verified shared assumptions |
| Tracked operations | 2 | Owner and evidence per system |
Define when an assessment can be shared
The grouping rule defines keys and boundaries: different versions, relevant architecture, different configuration or provenance not covered by the same advisory. Multiple sources can enrich a case while retaining contradictions. The register stays linked to original rows for verification.
Every instance retains its status and action. Fixing one system does not close the others. If an instance disappears on import, check collection or renaming before concluding treatment occurred. Closure relies on expected evidence: a fixed version, confirmed replacement or removal.
Make workload and coverage clear
Measure consolidation by tracking distinct cases, instances and actions separately. You can identify reused analysis and avoided duplicate tickets. Lower row counts reflect grouping, not an equivalent decrease in risk.
Starting with package inventories, CyberLifeCycle matches vulnerabilities, documents reusable assessments and tracks instances. Your plan separates shared analysis from system-specific operations. Teams get a clearer workload with the instances and evidence required for tracking.
Sources consulted
- RPM 6.0: spec format and subpackagesAccessed on 30 October 2026.
- RPM 6.0: versioning and EVR comparisonAccessed on 30 October 2026.