For vulnerability triage, give the model the advisory text, the affected package and version, how your code uses it, and how the service is exposed. Ask for a recommendation with stated assumptions, not a verdict. The model organizes evidence well. It should not be the thing that decides risk.
What triage actually needs
Triage answers a few questions: is the vulnerable code present, can it be reached, can an attacker get input to it, what is the impact here, and is a fix available. A bare CVE number answers none of them, and a model asked only about a CVE will fall back on general knowledge that may be stale or wrong.
So bring the facts to the model.
Inputs to include
- The advisory text, pasted from the source you trust (the vendor advisory or the database entry), labeled as data.
- Package name, installed version, and fixed version if one exists.
- The code that imports or calls the affected function, if you have it.
- Exposure: internet facing, internal only, batch job, build tool only.
- Existing controls, such as a gateway that strips the relevant input.
Pasting the advisory matters. Anthropic's guidance on reducing hallucinations suggests restricting the model to the provided documents rather than its general knowledge, which keeps it from filling gaps with plausible details.
A prompt shape
You are helping triage one dependency vulnerability for a web service.
Use only the advisory and code below. Do not use outside knowledge about this CVE.
Return:
1. Is the affected function used? Quote the line, or say "not found in the code provided".
2. Can untrusted input reach it? Explain the path, or say "unclear".
3. Assumptions you made.
4. Suggested priority (urgent, scheduled, accept) and what a human should verify.
<advisory>...</advisory>
<code>...</code>
<exposure>Internet facing API behind a gateway.</exposure>
Keep the decision human
Two risks sit on either side. A model can over-escalate by treating every match as critical. It can also under-escalate by accepting a plausible reason the code is safe. Require the "assumptions" and "what to verify" fields so a reviewer sees what the answer depends on.
Pair it with objective signals that the model should not be asked to guess: severity scores, exploit prediction, and the known exploited catalog. See what is EPSS and what is the CISA KEV catalog.
Check the model against your own history
Take twenty closed findings where the team made a decision with full context. Run them through the prompt and compare. Count disagreements and read each one. This takes an afternoon and tells you more than a vendor demo.
Where tooling beats prompting
Whether a vulnerable function is called is a program analysis question. Safeguard's reachability analysis computes it from the code, which gives you a fact to hand to the model or the reviewer instead of a guess. The free scan at gold.safeguard.sh/scan is a way to see that output on a real project.
Quick check
Can the model read the advisory itself if I give it the CVE id?
Not reliably. Unless it has a retrieval tool pointing at a trusted source, it answers from memory. Paste the advisory text.
Sources
Last reviewed: 19 October 2026.
