Why correlation matters
A CVE, vendor advisory, product bulletin, and scanner result can describe the same issue differently. The vendor source usually provides product branches, fixed versions, workarounds, configuration dependencies, and revision history needed for a local action. It may not be exhaustive, and product naming often differs from inventory naming.
Correlation workflow
- Start with the stable identifier: CVE, vendor bulletin ID, product family, or package name.
- Map vendor product names and branches to the local inventory. Record platform, edition, hosting model, and support status.
- Read affected and fixed ranges closely. A fixed release may exist for one branch but not another; distribution backports and managed-service responsibility can change the conclusion.
- Separate permanent remediation from a workaround or mitigation. Record prerequisites, scope, side effects, and expiry or revalidation needs.
- Capture advisory revision date, vendor severity, and source links. Updated guidance can change the action path.
Review checklist
- Does one advisory cover multiple CVEs, or does one CVE affect multiple products?
- Which installed product names, versions, and platforms match the vendor terminology?
- Is the vulnerable feature enabled and does the advisory describe a configuration dependency?
- Is the product unsupported, and does that change the available remediation path?
- Does vendor severity differ from CVSS, and what assumptions explain the difference?
- Is the recommended action a patch, configuration change, workaround, or monitoring step?
Common mistakes
Do not assume a product name match proves affected status. Do not call a workaround a permanent fix, or apply a fixed version for one platform to every branch. Treat advisory revisions as meaningful evidence, and retain the version of the guidance used for the decision.
Example
A vendor bulletin covers three CVEs across two maintained branches. Inventory identifies an older unsupported branch and a managed hosted service. The correct record separates the self-managed patch path, vendor support request, and temporary mitigation rather than placing all assets in one generic patch ticket.