Before AI Summarizes a Security Advisory: Verify Versions, Severity, and Fixes

A security advisory summary can keep the correct CVE ID and still misstate the affected versions, severity, exploitation evidence, fix, or next action. Treat every AI-written sentence as a claim that must return to a current, attributable record.

Security information rarely lives in one paragraph. A CVE record may identify the vulnerability and affected products. A vendor advisory may define the exact fixed releases. The National Vulnerability Database may add sourced enrichment. FIRST defines what a CVSS score means. CISA's Known Exploited Vulnerabilities catalog supplies a particular kind of exploitation evidence. A fluent model can compress those layers while quietly dropping their boundaries.

This workflow is for public vulnerability summaries, release notes, customer notices, knowledge-base articles, and internal editorial drafts. It is not a substitute for an organization's vulnerability-management process, incident response, vendor instructions, or qualified security judgment. The accountable security owner—not the model or editor—decides operational priority and approves consequential guidance.

Define The Publication Boundary

Begin with the job the summary must perform. “Explain the vulnerability” is too broad. A support notice may need customers to identify an installed release and open the vendor's update instructions. An executive brief may need to state why a security team is evaluating exposure without claiming that every deployment is affected. Different jobs require different facts and review.

If a real compromise is suspected, leave the publishing lane and follow the organization's incident-response process. Do not wait for an article review to complete, and do not let an AI writing task acquire access to scanners, consoles, ticket systems, or production controls.

Assemble Evidence Field By Field

Separate the evidence from the prose. Create one versioned fact card for each vulnerability and advisory combination. The model may read an approved copy of that card, but the card must be assembled and approved outside the generated narrative.

The current CVE Record Format documentation models affected products, versions, platforms, modules, descriptions, metrics, and public references as distinct fields. That structure is a useful warning against turning a record into one undifferentiated sentence. A summary should preserve the boundaries among those fields even when it uses plainer language.

Do not create one universal source ranking for every field. The product vendor may be the appropriate authority for its affected releases and remediation, the CVE record supplies program data and references, FIRST defines CVSS, and CISA maintains KEV. NVD enrichment can bring several sourced fields together without making every value a vendor assertion. When two sources conflict, record both values, their field-level sources, and their revision times. Do not let AI silently choose one, blend them, or convert disagreement into certainty.

Lock The Facts Before The Model Writes

Give the model only the approved public source excerpts and fact-card fields needed for the reader job. Ask for a labeled draft and require source locators beside consequential sentences during review. Do not ask the model to decide whether an asset is exposed, calculate local business impact, choose a patch window, infer that a missing field means “safe,” or publish without human approval.

Internal hostnames, addresses, version inventories, scanner exports, exploit traces, incident timelines, credentials, support tickets, and unpublished mitigations may reveal an organization's attack surface. Keep them out of an unapproved writing service. Apply the same minimization discipline as the privacy checklist for AI-assisted writing, and treat any untrusted advisory file according to the read-only document summary workflow.

The model's critique of its own draft is not independent verification. It can flag a possible mismatch, but an authorized reviewer must return to the official record, vendor advisory, and applicable organizational evidence.

Resolve The Identifier And Record Status

First confirm that the CVE ID names the vulnerability being summarized. Similar product names, related flaws, chained vulnerabilities, and copied descriptions can cause an AI draft to combine separate records. Preserve aliases only when a source explicitly connects them, and never replace the official identifier with a guessed one.

The NVD Vulnerability API documentation exposes the CVE ID, source identifier, publication time, last-modified time, and NVD status as separate values. Record them separately. The source that supplied a description or metric also matters: an enriched field is not automatically a vendor statement, and a later modification may invalidate yesterday's wording.

If an identifier is only reserved, a record is rejected, or a source marks the issue disputed, the summary must display that state rather than describing a settled published finding. Do not hide uncertainty to make the notice sound cleaner. A qualified reviewer should decide whether the summary should be held, narrowed, or released with an explicit limitation.

Map Every Product And Version State

“Versions before 5” may be shorter than the source but much less accurate. Product names can cover community and enterprise editions, hosted and on-premises services, operating systems, architectures, components, or release branches with different status. Create one row for every product-version combination the summary mentions.

The CVE Project's version-range user guide distinguishes inclusive and non-inclusive upper bounds and requires a version type for ranges because version ordering is not universal. Semantic, Python, RPM, Maven, Git, and vendor-specific schemes can compare the same-looking strings differently. Do not assume semantic-version rules or turn an unspecified custom range into a calculated boundary.

Unknown or under investigation does not mean unaffected. The OASIS Common Security Advisory Framework 2.0 keeps product trees and product status explicit, including known affected, known not affected, fixed, and under-investigation states. Preserve the source's state and update it when the advisory changes.

Do Not Turn Severity Into Risk

The NVD vulnerability metrics guidance states that CVSS supplies a qualitative measure of severity, not a measure of risk. A Base score describes intrinsic technical characteristics under the standard's assumptions. It does not know which product versions an organization actually runs, whether the vulnerable path is reachable, what controls exist, how critical the system is, or what disruption a change may cause.

Always publish the score with its source, CVSS version, and vector. The FIRST CVSS 4.0 specification separates Base, Threat, Environmental, and Supplemental metric groups and requires a published score to be accompanied by its vector so readers can understand how it was derived. “Critical vulnerability” without that context may silently mix a vendor's assessment, an NVD assessment, and a local risk decision.

If sources disagree, do not average scores or choose the largest for drama. Record both values with their versions, vectors, sources, and check times. Ask the security owner whether the reader needs one attributed value, both, or an explanation of why the organization uses a particular assessment. Keep that judgment out of the model's hands.

Keep Exploitation Evidence Separate

CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source for vulnerabilities known to have been exploited in the wild and recommends using it as an input to prioritization. A matching entry is strong, specific evidence that should be recorded with the date checked and required-action wording.

Absence from KEV is not evidence that exploitation has not occurred. The catalog has inclusion criteria and changes over time. Write “not listed when checked” rather than “not exploited,” unless another authoritative source makes the latter claim within a defined scope. Likewise, proof-of-concept code, scanner detection, public discussion, and confirmed exploitation are different evidence states.

Do not copy a federal remediation due date into a universal customer deadline. CISA's binding deadlines apply within their stated federal scope. Other organizations can use KEV as an important input, but their qualified security owners must apply their own authority, exposure, policy, and operational context.

Preserve The Exact Remediation State

A fix, mitigation, and workaround are not interchangeable. CSAF defines separate remediation categories for a vendor fix, mitigation, workaround, none available, and no fix planned. A workaround may reduce exposure in a particular configuration. A mitigation may reduce risk without resolving the vulnerable product. “None available” means neither a fix nor another remediation is currently available; “no fix planned” describes a different vendor position.

Copy the applicable product IDs or version rows into the fact card. Preserve prerequisites, sequencing, service restart, entitlement, and verification language when they are material, but link readers to the authoritative vendor instructions rather than recreating an operational procedure from memory. Do not add exploit steps or speculative technical detail merely to make the article sound expert.

Installation is not verification. NIST SP 800-40 Revision 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. A summary may say that a fix is available when the vendor says so; it should not say an environment is fixed until an authorized process verifies the installed state.

A Fictional Summary Under Review

Consider an expressly fictional placeholder product and advisory. No company, identifier, version, or status in this example describes a real vulnerability. An AI draft says: “A critical zero-day affects every [Fictional Gateway] installation. Attackers are actively exploiting it, and upgrading to version 5 completely removes the risk.”

The fictional source pack says something narrower: [Fictional Vendor] identifies only on-premises [Fictional Gateway] 4.6.0 through 4.6.4 as affected, marks 4.6.5 fixed, and lists its hosted service as under investigation. The vendor labels the severity High but has not published a complete CVSS score and vector. No source in the pack asserts active exploitation, and the catalog check finds no KEV entry. The vendor requires its documented update and a post-installation version check.

The draft invents universality, changes “high” into “critical,” treats an unspecified discovery timeline as a zero-day, invents exploitation, replaces an exact fixed release with a major-version guess, and promises elimination of all risk. A supportable version would attribute the affected on-premises range and fixed release to the fictional vendor, keep the hosted service under investigation, attribute the vendor's High label while saying that no complete vector-backed score is published, avoid an exploitation conclusion, and direct readers to the vendor instructions and their security owner.

The correction is less dramatic because the evidence is narrower. That is the point. A useful advisory summary helps the reader locate the right product state and authoritative action; it does not manufacture urgency from missing fields.

Test Every Consequential Sentence

Turn the final draft into a claim matrix. Each consequential sentence needs a fact-card field, source URL, exact locator, source revision, checked-at time, reviewer, and result. Check links in a clean session and make sure a reader lands on the intended advisory rather than a search page, stale mirror, or general product page.

Protect identifiers, version expressions, vectors, dates, statuses, and action language during editing. The protected-terms workflow can keep those fields outside casual rewriting. After any wording change, compare the entire sentence against the fact card rather than checking only the edited phrase.

Set Revision Triggers Before Release

A security advisory is living content. Archive the fact card, source snapshots or durable locators, prompt and approved inputs where policy requires them, draft comparison, reviewer decision, publication time, and correction path. Show readers when the summary was last reviewed if its claims may change.

Define recheck triggers before release: a CVE record changes state or modification time; a vendor revises affected versions; NVD adds or changes enrichment; CISA adds a KEV entry; a mitigation is withdrawn; a fixed release appears; or the organization's supported-product scope changes. Apply a short freshness window to volatile claims rather than assuming yesterday's accurate sentence remains accurate.

When a correction is needed, update the summary and its review time, record what changed, and avoid silently replacing consequential guidance. If a source conflict remains unresolved, attribute the conflict and let the security owner decide whether to hold publication or state the uncertainty.

Also test the update path before the first release. A reviewer should be able to identify which sentences depend on a changed version range, score, exploitation state, or remediation and replace only the claims the new evidence affects. Recheck headings, snippets, social metadata, notification copy, and cached support text—not only the article body. Otherwise a corrected paragraph can coexist with an obsolete headline or preview that continues to make the earlier claim.

Make The Summary Traceable, Not Merely Urgent

An AI-written vulnerability summary earns trust when a reviewer can reconstruct every claim: which identifier, which product and version, whose score and vector, what exploitation evidence, which remediation state, when it was checked, and who approved the action. Smooth prose cannot replace that record.

The final question is not whether the draft sounds authoritative. It is whether the right security owner can trace it to current evidence and show that the reader is being asked to do exactly what that evidence supports—no more and no less.