Using LLMs to Explain Security Findings to Developers

Security tools are written by security people, for security people. Their output reflects that: CVE IDs, CWE categories, CVSS vectors, and a link to an advisory.

Developers receiving that output often have to do a fair amount of translation before they can act. Which service? Which file? Does it matter for how we use this library? What do I actually change?

When that translation doesn't happen, findings sit. LLMs are well suited to doing the translation, as long as they keep the technical substance intact.

What a developer needs to know

A useful explanation answers a predictable set of questions:

• What is the issue? In a sentence or two, without jargon that requires a lookup.
• Where is it? The repository, service, file, dependency, or image, specifically.
• What is the impact? What an attacker could do, under what conditions.
• Does it apply here? Which conditions hold in this codebase or environment, and which are unknown.
• What should I do? The recommended fix, with alternatives if it is blocked.
• How will we know it is fixed? The check that will close the finding.
• Who owns it, and by when? Based on ownership data and policy.

Most scanner output covers the first item and part of the second. The rest is where time goes.

How an LLM helps

Give the model the raw finding, the advisory, relevant source code or configuration, and ownership and priority data. Ask for an explanation organized around those questions.

The result can turn something like "CVE in transitive dependency, CVSS 8.1" into: this service's image includes a version of a compression library with a heap overflow when handling crafted archives; the service accepts archive uploads on a public endpoint; upgrade the base image to the version that includes the fix; a rescan of the deployed image will confirm.

That is the same technical content, presented in the order a developer needs it.

Keep the technical detail

There is a failure mode where "explaining" becomes "simplifying until it is vague." Developers notice, and it erodes trust.

Good explanations keep:

• The exact identifiers: CVE, package name, affected and fixed versions
• The specific file paths, functions, or configuration keys involved
• The precise conditions for exploitation
• Links to the advisory and fix commit

Plain language is about structure and clarity, not removing information.

Show the evidence

Every claim in the explanation should be traceable. If the model says the service accepts archive uploads, it should point to the handler. If it says a configuration option is enabled, it should point to the file.

This does two things. It lets developers verify quickly instead of taking security's word for it. And it exposes model errors early, when someone checks a reference and finds it doesn't say what the explanation claims.

When something can't be determined from the available context, the explanation should say so plainly. "We could not confirm whether this option is set in production configuration" is more useful than a guess.

Fit the developer's workflow

The best explanation is wasted if it lives somewhere developers don't look.

• Put it in the ticket or pull request, not a separate portal.
• Match the team's conventions for ticket structure and labels.
• Keep the summary short and put details below it.
• Let developers ask follow-up questions in place, answered from the same context.

Guardrails

• Facts come from data. Versions, severity, exploitation status, and deadlines come from authoritative sources and policy, not model output.
• Validate structured fields. Check that recommended versions match the advisory and owners match the service catalog.
• Treat inputs as untrusted. Code comments and advisory text can contain instructions meant to mislead the model.
• Don't let tone override urgency. A friendly explanation shouldn't make a P1 sound optional.

Measuring the effect

Track signals tied to developer behavior: time from ticket creation to first response, how often tickets are reassigned or questioned, and time to fix. If developers act sooner and ask fewer clarifying questions, the explanations are working.

The point

Developers don't ignore security findings because they don't care. They ignore findings that cost too much effort to understand. An LLM that turns raw findings into clear, evidence-backed, actionable explanations removes that cost while keeping every technical detail intact.