Rank CVE and SBOM Findings into a Defensible Remediation Plan

Tier: Core · Hands-on time: ~45 minutes

The division of labor that works: scanners and vulnerability databases are the source of truth; AI ranks, explains, and drafts the plan; exploitability data (KEV/EPSS) anchors the ranking to reality instead of CVSS theater. The output is a remediation plan you can defend to a security team and a change-advisory board.

When to use

• •
  Post-scan triage: image/host/dependency scan produced hundreds of findings and "fix all criticals" is not a plan.
• •
  Release gates: SBOM diff between the current and proposed release needs a risk-change summary for change advisory.
• •
  A client or auditor asks for your patch-prioritization rationale and "we sort by CVSS" will not survive questioning.

Skip AI for a single fresh CVE on the front page of the internet — go straight to the advisory, your exposure check, and the patch.

Prerequisites

• •
  Scanner output in machine-readable form: Trivy/Grype JSON, plus Syft-generated SBOMs (CycloneDX/SPDX) for the diff use case.
• •
  Current CISA KEV catalog and EPSS scores (both free downloads) for the CVEs in scope — fetch these fresh; model training data is stale by definition.
• •
  Deployment context per component: internet-facing or internal, prod or dev, data sensitivity. A short YAML/CSV you maintain is enough.
• •
  Agreement that severity comes from the scanner and the databases — AI never invents or adjusts a score.

The workflow

1. 1.

   Merge the evidence before prompting. Join scanner findings with KEV membership, EPSS score, and your deployment-context file into one table (a 20-line script; have AI write it). Prompting with unjoined fragments produces confident nonsense.

2. 2.

   Ask for ranking with stated rules.

   Copy

   Attached: merged vulnerability findings (scanner severity, KEV yes/no,
   EPSS, component, deployment context). Produce a remediation plan:
   
   Ranking rules, in order: (1) KEV-listed AND internet-facing; (2) KEV-listed;
   (3) EPSS > 0.1 on prod components; (4) scanner-critical on prod;
   (5) everything else grouped by component so one upgrade closes many.
   
   For each of the top 20: what it is (2 lines, plain language), why this
   rank (cite the fields), the fix (version bump / base-image update /
   config), and blast radius of the fix.
   
   Then: group the remaining findings into upgrade batches by component.
   Do not change any severity or score. Do not add CVEs not in the data.
   Flag any row where the data fields conflict.
   

3. 3.

   Verify the top of the list hard. For the top 10: open the actual advisory, confirm the affected-version range matches what you run (scanners false-positive on backported fixes constantly), and confirm KEV/EPSS values against the source files. The plan's credibility lives or dies in its top 10.

4. 4.

   Check reachability where it matters. For expensive fixes (major-version bumps, base-image swaps), ask the AI to help determine whether the vulnerable code path is even loaded (which package feature, which config enables it) — then verify in the code/config yourself. Deprioritize with a written reason, never silently.

5. 5.

   Do the SBOM diff for release advisory. Diff old vs new SBOM (syft + a diff, or Dependency-Track). Ask for a change-advisory paragraph: components added/removed/bumped, net new vulnerabilities introduced, vulnerabilities closed, license changes. This becomes the security section of the change record — reviewed, then attached to the release.

6. 6.

   Ship as PRs and tickets with the rationale embedded. Have AI draft: dependency-bump PRs in batches from step 2's grouping, and tickets for the top 20 with the two-line explanation and rank rationale inline. Rationale-in-ticket is what makes the plan defensible six months later.

Tool variants

• Trivy/Grype + Syft + chat assistant: default zero-cost path for images and filesystems.
• Dependency-Track: continuous SBOM analysis with policy; use AI on its findings export for the ranked narrative and batch planning.
• Commercial platforms (Snyk/Wiz-class) with built-in AI prioritization: treat their ranking as a second opinion; the verification of the top 10 against advisories stays yours either way.
• CI integration: run the merged-triage script in CI on SBOM change; AI drafts the risk-change comment on the release PR automatically, human approves the release.

Verification

• •
  Top 10 findings each verified against the primary advisory: correct affected-range for your actual versions.
• •
  KEV/EPSS values in the plan spot-checked against the freshly downloaded sources — no model-remembered scores.
• •
  Every deprioritized finding has a written reachability or context reason attached.
• •
  SBOM-diff summary reconciles with the raw diff counts (components added/removed match).

Pitfalls

• Model-remembered vulnerability data. LLMs will fluently describe a CVE with the wrong affected versions or a plausible-but-wrong fix version — that is why the advisory check on the top 10 is non-negotiable.
• CVSS-only sorting. Thousands of 9.8s that are unreachable in your estate bury the KEV-listed 7.5 on your internet edge.
• Fixing findings one CVE at a time. Most wins come from base-image refreshes and batched bumps — the grouping step is where the leverage is.
• False positives from backports. Distro-patched packages carry old version strings; scanners flag them, and an unverified plan inherits the noise.
• Letting the AI editorialize severity. "This seems less serious than rated" without a reachability argument is exactly the sentence an auditor will find.

Restricted-environment variant

• •
  SBOMs and scan results reveal your (or your client's) exact software inventory — treat them as confidential. Do not paste into public tools without approval; component inventory is reconnaissance gold.
• •
  Client-safe path: local model via Ollama for the ranking/explanation step (the merged table is small after joining), or the client's approved enterprise tenant. KEV/EPSS lookups are public data and safe from any network.
• •
  For regulated clients, map this playbook's output to their patch-SLA clauses (e.g., criticals in 15 days): have the AI annotate each top-20 item with the contractual deadline from the client's policy doc.

Success criteria

• •
  Thousand-finding scan output becomes a ranked, batched plan in under an hour, with rationale attached to every top item.
• •
  Zero score/version errors found when the security team reviews your top 10.
• •
  Release change records now include an SBOM-based risk-change paragraph as routine.
• •
  Patch prioritization survives an auditor's "why this order?" without improvisation.