Analyze CVE Impact Against Your Own Asset Inventory with AI

This is an Advanced task because it is retrieval-grounded reasoning over messy real-world data: the advisory describes affected products, versions, and conditions; your CMDB describes what you actually run; and the impact lives in the join between them, complicated by transitive dependencies, version ambiguity, and stale inventory. AI accelerates the cross-reference and reasons about conditional applicability, but the inventory it reasons over is frequently wrong or incomplete — so every "affected" and every "not affected" is a hypothesis you confirm against reality before you act or report.

When to reach for this

• •
  A high-profile CVE (or a supply-chain advisory) lands and you need a fast, defensible impact assessment across the estate.
• •
  The affected-versions logic is conditional (only with feature X enabled, only certain configs) and needs reasoning, not a string match.
• •
  You must answer "where are we exposed?" for leadership with enough rigor that the answer holds up.

The workflow

1. 1.

   Assemble both sides of the join. The advisory's affected products, versions, and preconditions; and a current export of the relevant inventory — software bill of materials, CMDB, container image manifests. Freshness of the inventory is the single biggest determinant of accuracy.

2. 2.

   Prompt for a matched impact analysis with explicit uncertainty:

   Copy

   You are assessing whether my organization is affected by a CVE. Match the
   advisory's affected criteria against my asset inventory below.
   
   For each potentially-affected asset:
   - state whether it matches the affected version range (be exact about
     version comparisons)
   - state whether the advisory's preconditions (config, enabled features)
     apply, or that you cannot tell from the data
   - classify: AFFECTED / NOT AFFECTED / CANNOT DETERMINE
   Do NOT classify NOT AFFECTED unless the version or precondition clearly
   rules it out. When the inventory is silent or ambiguous, say CANNOT
   DETERMINE and name what you'd need to confirm.
   
   ADVISORY: <affected products/versions/preconditions>
   INVENTORY: <SBOM / CMDB export>
   

   Expected output: three buckets, with CANNOT DETERMINE used honestly for every asset the data can't resolve — that bucket is your manual follow-up list, and it's a feature, not a failure.

3. 3.

   Chase transitive exposure. For library CVEs, the vulnerable component is often a dependency of a dependency. Ask the model to trace which of your assets pull in the affected component transitively, then confirm against the actual dependency tree.

4. 4.

   Confirm the AFFECTED and CANNOT DETERMINE lists against live systems. Query the real hosts/images for the actual installed version — the inventory is a starting point, not truth. Promote confirmed hits to remediation (see the exploitability-prioritization playbook to order them).

5. 5.

   Report impact with confidence levels. Give leadership the affected count, the unresolved count, and what you're doing to close the unknowns — an honest "12 confirmed, 30 still checking" beats a false "we're fine."

Verify before you trust it

• Confirm every AFFECTED against the live asset. Version strings in inventories drift from reality. Query the actual host or image before you spend remediation effort or raise an alarm.
• Distrust NOT AFFECTED and interrogate CANNOT DETERMINE. A clean result reflects inventory coverage, not ground truth. Ask: what assets aren't in this inventory at all? Shadow IT, unmanaged containers, and forgotten hosts are exactly where the exposure hides.
• Verify the version-comparison logic. Models sometimes mishandle version ranges (semver edge cases, backported fixes where a low version number is actually patched). Re-check the boundary cases by hand.
• Confirm transitive claims against the real dependency tree. A claimed transitive pull-in should show up in an actual lockfile or SBOM query, not just the model's inference.

Pitfalls

• Trusting a stale inventory. The whole analysis inherits the CMDB's blind spots. An asset not in the inventory reads as "not affected" and stays exposed.
• Silent NOT AFFECTED. Forcing the model to use CANNOT DETERMINE prevents false all-clears; without that instruction it will guess "not affected" for ambiguous assets.
• Version-range mistakes. Backported patches and semver quirks trip up naive comparison. Verify boundaries.
• Ignoring transitive and container layers. The vulnerable code often arrives as a nested dependency or a base image layer, invisible to a top-level product match.
• Reporting false certainty. Presenting "not affected" as fact when it's really "not found in inventory" is how you get blindsided post-incident. Report confidence, not just conclusions.

Tools

• An LLM (Claude-class)performs the advisory-to-inventory join, reasons about conditional applicability, and honestly surfaces what it can't resolve.
• Trivyscans running images and filesystems for the actual installed version and transitive components, giving you ground truth to confirm the model's matches.
• CISA KEV catalogtells you whether the CVE is being exploited now, which sets how hard you push to resolve the CANNOT DETERMINE bucket.

Client-safe variant

An asset inventory is one of the most sensitive artifacts a client owns — it maps their entire attack surface. Before prompting, replace real hostnames, IPs, and asset IDs with opaque tokens or roles, keeping only the product/version data the CVE match needs; the join works on versions, not names. Where the client bars external tools, run the analysis with a local model — the advisory is public and the inventory stays in-house. Confirm affected assets by querying the client's own systems, keep the impact report inside their boundary, and get per-client approval before any inventory slice leaves it.