Triage Patches and CVEs Across the Fleet

Tier: Foundation · Workflow area: Security & Compliance · ~25 minutes

Patch triage is a matching problem: vendor-published changes on one side, your fleet's versions, features and exposure on the other. Done by hand it is hours of cross-referencing release notes against a spreadsheet; skipped, it becomes either patch-everything-blindly (regression risk) or patch-nothing-yet (breach risk). AI collapses the matching hours — it reads the notes and your inventory and drafts the intersection — while the decisions that matter (patch order, maintenance windows, what needs regression testing) stay with the DBA who signs the change tickets. One rule governs everything: severity claims get verified against the primary source, because a model misremembering a CVSS score is a real failure mode.

When to use

• Quarterly patch cyclesOracle CPU quarters, SQL Server CUs, Postgres minor-release waves; the triage repeats, so the workflow should be banked.
• Out-of-band CVE dropsa high-severity database CVE lands and management wants "are we exposed?" answered today, per instance, with evidence.
• Audit-driven patch hygienedemonstrating a documented, risk-ranked patching process instead of ad-hoc heroics.

When NOT to use

• As the exposure verdict itselfthe model drafts the mapping; whether instance X is actually exploitable depends on configuration facts you verify. AI-asserted "not affected" is a hypothesis until checked against the instance.
• For emergency response to active exploitationa CVE being exploited in the wild against your stack is incident response with vendor guidance, not a triage-and-schedule exercise.
• When the inventory is fictionif you do not actually know versions and installed components per instance, fix the inventory first; triage over guessed versions produces confident nonsense.

The recipe

1. 1.

   Pull a real inventory — versions from the engines, not the wiki.

   Copy

   -- Postgres, per instance
   SELECT version();
   SELECT name, default_version, installed_version
   FROM pg_available_extensions WHERE installed_version IS NOT NULL;
   

   Copy

   -- SQL Server
   SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel'),
          SERVERPROPERTY('ProductUpdateLevel'), SERVERPROPERTY('Edition');
   

   Assemble one table: instance, engine, exact version, installed extensions/components, environment tier (prod/stage/dev), internet exposure (yes/no/via-app), data classification, and HA setup (matters for patch windows). This inventory is the asset the whole playbook stands on — keep it as a maintained file, not a one-off.

2. 2.

   Collect the primary sources, not summaries of summaries. The release notes and advisories themselves: the Postgres release-notes pages for versions between yours and current, the Microsoft CU KB articles, the Oracle Critical Patch Update advisory, and the CVE entries from NVD or the vendor's security page. Paste text, not links alone — you want the model working from the document you archived, and you want that archive for the audit trail.

3. 3.

   Ask for the intersection: notes × inventory, structured.

   Copy

   Below: (a) our database fleet inventory, (b) the release notes and
   security advisories for [engine] versions [X..Y].
   
   Produce a patch triage table with one row per (instance, relevant
   item): instance, current version, item (CVE ID or fix), the vendor's
   stated severity VERBATIM with a quote, whether our configuration
   plausibly makes it relevant (cite the inventory fact: extension
   installed, feature tier, exposure), and what functional areas the
   patch touches (for regression scoping).
   
   Rules:
   - Quote severity and affected-version ranges verbatim from the notes;
     do not restate from your own knowledge.
   - If relevance cannot be determined from the inventory, write
     NEEDS-CHECK with the specific question (e.g., "is logical
     replication in use?").
   - Separate security fixes from behavior changes and deprecations —
     both matter, differently.
   

   The verbatim-quote rule exists because models blend memory with the pasted text; forcing quotes keeps the table anchored to your archived sources.

4. 4.

   Verify the load-bearing rows and resolve every NEEDS-CHECK. Two verification passes, both quick. First: for every row that will drive a priority decision, check the CVE ID, affected-version range and severity against the primary source — a transposed version boundary changes everything. Second: answer the NEEDS-CHECK questions with queries, not memory:

   Copy

   -- "Is logical replication in use?" — asked of the instance
   SELECT COUNT(*) FROM pg_publication;
   SELECT COUNT(*) FROM pg_subscription;
   

   Each answer flips a row to relevant or not-relevant with evidence attached.

5. 5.

   Rank into a plan with regression-risk notes — the human layer. Now the triage becomes a schedule. Priority is exposure-weighted, not just CVSS: an internet-adjacent prod instance with an exploitable relevant CVE outranks a higher-scored CVE on an isolated dev box. Have AI draft per-instance regression notes from the "functional areas touched" column — this CU touches the query optimizer; instance FIN-01 relies on plan-guide pins, add a Query Store regression check to the patch window — then edit them with what you know the model cannot: that FIN-01's app has a history of optimizer sensitivity, that the vendor's last CU on this branch was pulled and reissued. Sequence: dev tier first with a soak period, then staged prod waves aligned to HA failover order.

6. 6.

   File the triage pack and diff it next cycle. The artifact: inventory snapshot, archived advisories, the verified triage table, and the ranked plan with owners and windows. Next quarter, the diff against this pack ("what changed, what was deferred and is now overdue") is where deferred risk becomes visible instead of forgotten — deferrals need re-justification each cycle or they graduate into findings.

Make it yours

• Oracle fleetsthe quarterly CPU advisory's risk matrices map cleanly to this workflow; include one-off patches and the OJVM component question in the inventory, and treat the "affected components" column as the NEEDS-CHECK generator.
• MySQL/MariaDBrelease notes mix security and behavior changes densely; make the model separate them explicitly, and watch for replication-format behavior changes as the classic regression source.
• Managed cloud (RDS/Cloud SQL)the provider applies engine patches, which changes the questions, not the work: triage becomes "which pending maintenance actions do we accelerate vs defer," minor-version auto-upgrade policy per instance, and extension versions that remain your job.

Quality check

• Versions came from the enginesevery inventory row was generated by a query, dated; a wiki-sourced inventory row is a guess.
• Severity and version ranges verified against primary sourcesfor at least every row driving a priority call. Model-remembered CVSS scores are not citable.
• Every NEEDS-CHECK was resolved with a querythe table contains zero unresolved relevance questions at sign-off; "probably not using that feature" is not a disposition.
• Regression notes reflect instance-specific knowledgethe AI draft plus what you added; a plan whose regression column could apply to any fleet was not finished.
• Deferred patches carry a revisit date and a named ownerdeferral is a decision with an expiry, and the next cycle's diff enforces it.