A CVE is reported against a package at version 1.2.0. The fix lands in 1.2.1. Some teams upgrade to 1.3.5, which incorporates the fix and also reshapes a few internal call signatures. Other teams are on 1.4.0, where the affected function has been removed entirely. The CVE database often lists the affected versions as "≤ 1.2.0" — but that is a publication artifact, not a technical truth. Whether your specific version is actually affected depends on the exact code path that exists in your installed copy. Version-aware resolution is the ability to make that determination correctly, and it is one of the cleanest places to compare a deterministic engine like Griffin AI's to a Mythos-class general-purpose LLM.
What "version-aware" actually means
Three sub-capabilities, all of which need to work for the analysis to produce correct output:
- Resolve the exact installed version, not the declared version range. Lock files matter.
- Map the CVE to the specific symbols affected in that version, not to the package as a whole.
- Determine whether your code path reaches those specific symbols in your version, not in some hypothetical version.
A correct answer requires all three. Skipping any one of them produces false positives or false negatives.
Where general-purpose LLMs struggle
Mythos-class pure-LLM tools tend to operate on package-level granularity because that is what their training data emphasises. Asked "is this CVE in my dependency graph?", the model can answer based on package presence. Asked "is this CVE actually present at the symbol level in version 1.3.5?", the model often produces confident-sounding but unverified output because the symbol-level data is not consistently in the model's training corpus.
The failure mode is over-reporting. The model says "yes, your version contains CVE-X" because the package is in the graph. The actual CVE was patched in a version below yours, and your code never calls the affected function anyway. The finding is wrong, but it sounds authoritative.
How Griffin AI handles it
Three deterministic steps, in order:
Step 1 — Lockfile resolution. Parse the lockfile (package-lock.json, Cargo.lock, go.sum, etc.) to get the exact installed version of every dependency, including transitives. This is mechanical, fast, and exact.
Step 2 — Symbol-level CVE mapping. Match the CVE to the specific symbols introduced or affected in the relevant version range. The mapping comes from advisory databases that increasingly include symbol-level metadata (GitHub Advisory Database, OSV, vendor-published feeds). Where symbol-level data is absent, Griffin falls back to function-level heuristics with explicit confidence reduction.
Step 3 — Reachability against the version-correct call graph. Build the call graph using the actually-installed version's source. A function that was renamed in 1.2.5 has the new name in your call graph; the old name from the CVE description is mapped to the new name during analysis.
The output is a finding that says either "this CVE is reachable from your code in this version, here's the path" or "this CVE is not reachable in this version because the affected function has been renamed/removed/sanitized."
Why this matters operationally
Three concrete consequences:
False positive rate drops dramatically. A CVE that affected a function that no longer exists in your version is correctly classified as not-affected. Your triage queue fills with real findings, not historical ones.
Compliance narratives become defensible. "We checked the symbol-level reachability in our installed version" is a stronger story than "we checked the package version against the advisory range." Regulators and auditors increasingly distinguish between the two.
Patch pressure stays calibrated. The number of "drop everything and patch" findings shrinks to the ones that are genuinely reachable in your version. Engineering teams can trust the prioritisation.
A concrete example
Consider CVE-2024-X in a popular package. The CVE was disclosed against version 1.4.2 with a fix in 1.4.3. The affected function was processInput, which validated input format. In version 2.0.0, the function was renamed to validateAndProcess and now calls a sanitizer first. You are on version 2.1.7.
A package-level scanner says: "your version is in the affected range" (because 2.1.7 is post-1.4.2). False alarm.
A version-aware scanner says: "the affected function processInput does not exist in your version; the equivalent function validateAndProcess calls a sanitizer that mitigates the original flaw." Correct.
A pure-LLM tool, asked to reason about this, often produces confident output without verifying — which means the answer depends on what the model happens to know about that specific package's history. Sometimes correct, often not.
Where the data quality matters
Symbol-level CVE mapping depends on advisory data quality. The state of the art in 2026 is uneven: GitHub Advisory Database has good symbol metadata for high-volume ecosystems (npm, PyPI, Maven, Go modules); other ecosystems lag. Griffin AI's analysis uses the best available data and falls back to coarser-grained analysis (with explicit confidence reduction) when symbol-level data is missing.
Mythos-class platforms typically don't expose this fallback explicitly, which is part of why their version-aware accuracy varies.
What to evaluate
Three questions to ask any AI-for-security platform:
- Show me a finding where the affected function was renamed in my version. Is the platform correctly identifying that the original function does not exist?
- Show me a finding where the affected version range overlaps with my installed version but my code does not reach the affected symbols. Is the finding correctly suppressed or downranked?
- Walk through the data sources used for symbol-level CVE mapping. What is the fallback when symbol data is missing?
The answers separate version-aware engines from version-aware-shaped UIs.
How Safeguard Helps
Safeguard's version-aware resolution is built into the deterministic engine's call graph construction. Lock-file-resolved versions, symbol-level CVE mapping, and version-correct reachability analysis all happen before Griffin AI's reasoning step runs — so the LLM sees structured evidence about what is and is not affected in the specific version installed. False positives from version-range over-reporting drop to near zero in customer benchmarks. For teams whose patch backlog is choked with version-misclassified findings, version-aware resolution is the single highest-leverage architectural feature to evaluate.