Using LLMs to Turn Vulnerability Alerts into Clear Remediation Plans

A vulnerability alert is a claim. A remediation plan is a commitment: this asset, this owner, this fix, by this date, verified this way.

Getting from one to the other usually involves a security analyst gathering context from several systems and writing it up by hand. That step is a good fit for an LLM, provided the workflow keeps the facts anchored to real data.

Here is one way to structure it.

Step 1: Normalize the finding

Different scanners describe the same issue differently. Before any model gets involved, normalize findings into a common schema:

• Vulnerability identifier (CVE, GHSA, vendor ID)
• Affected component and installed version
• Asset identifier and environment
• Detection source and timestamp

This step should be deterministic code, not an LLM. It is the foundation everything else stands on.

Step 2: Enrich with trusted context

Attach the data a human would otherwise look up:

• Fixed versions from the advisory or OSV
• KEV status and EPSS score
• Asset owner and service from the CMDB or cloud tags
• Exposure: internet-facing, internal, isolated
• Existing mitigations, if recorded

Each field should carry its source. When a value is unknown, say so explicitly rather than leaving it blank. The model needs to see the gaps.

Step 3: Ask for a plan, not an opinion

Now the LLM gets a bounded package: the normalized finding, the enrichment, the advisory text, and, if useful, the team's remediation runbook.

The request should be specific. Produce a structured plan with:

• A one-paragraph summary of the issue in plain language
• The recommended action, such as upgrading to a named version, rebuilding an image, or applying a configuration change
• Alternatives if the primary action is blocked
• Expected impact and risk of the change
• How to verify the fix
• Which input facts support each recommendation

Ask for structured output, such as JSON with defined fields, alongside the readable version. That makes validation possible.

Step 4: Validate against the source data

Before anything goes to a human, check the plan mechanically:

• Does the recommended version actually appear in the advisory's fixed versions?
• Does the named owner match the CMDB?
• Does the priority match the policy rules for this exposure and exploitation status?

If a check fails, reject the plan or flag it for review. This is the step that stops a confident-sounding but wrong recommendation from reaching an engineer.

Step 5: Assign and communicate

Create the ticket in the owning team's queue with the plan attached. A good ticket answers the questions an engineer will ask before they ask them: what is affected, why it matters, what to do, and how to know it worked.

Set the due date from policy, not from the model. The LLM can explain the deadline; it shouldn't choose it.

Step 6: Support the fix

When the remediation is a dependency or image update, the plan can feed automation that opens a pull request. When it is a manual change, the plan becomes the change description.

Engineers will have questions. Letting them ask follow-ups in the ticket, answered from the same bounded context, reduces back-and-forth with security. The model should say plainly when the sources don't answer a question.

Step 7: Verify, then close

A ticket marked "done" is not a fixed vulnerability. Closure should depend on evidence:

• A rescan shows the component at a fixed version
• The deployed artifact, not just the repository, contains the fix
• Any temporary mitigation is removed or documented as permanent

Only close the finding when verification passes. If it fails, reopen the ticket automatically with the new evidence.

What the LLM is doing here

Notice what the model does and doesn't do in this workflow. It reads, summarizes, explains, and drafts. It doesn't decide what is vulnerable, set deadlines, or close findings. Those come from data and policy.

That division matters. It lets you get the speed benefit of language models while keeping every decision traceable to a source a person can check.

Where to start

Pick one finding type with clean data, such as direct dependencies in a handful of repositories. Run the workflow end to end. Measure time to assignment, time to fix, and how often plans fail validation. Then widen the scope.