The common practice of handing raw vulnerability scanner results to a large language model (LLM) for instant exploitability ranking has been replaced by a deterministic, graph‑driven workflow. Practitioners care because the new approach eliminates speculative judgments, provides reproducible evidence, and keeps security decisions auditable.
Why the Shift Matters
Exploitability is not an attribute that lives in a CVE record; it emerges from a chain of relationships that span package managers, build pipelines, container images, deployment descriptors, runtime inventories, and call graphs. When an LLM only sees package names, versions, severity scores, and advisory text, it cannot infer those missing links. The result is a confident‑sounding but ungrounded ranking that can mislead incident response and change management.
Building an Exploitability Graph
To replace the language‑only approach, teams should construct a typed graph that represents the software supply chain. Typical node types include package, artifact, image, application, environment, scan, and policy_exception. Edges capture relationships such as depends on, contains, produced by, deployed as, promoted by, and calls. Most organizations already collect these facts in registries, build metadata stores, deployment records, SBOM generators, and runtime inventory services; the challenge is joining them into a single graph.
Once the graph is assembled, a traversal engine can compute reachability: it can answer whether a vulnerable package appears in a dependency tree that is actually executed in production. The answer is a concrete path – for example, package → artifact → image → application → environment → executed function – which can be presented to reviewers. This deterministic computation replaces the guesswork of an LLM and makes the finding reproducible even if the model service is unavailable.
Integrating LLMs Without Overstepping
LLMs remain valuable for interpreting vague requests, selecting the appropriate analysis workflow, and translating structured findings into human‑readable explanations. The key is to limit the model to language tasks and to feed it only evidence that the graph traversal has already produced. For query generation, the model should output a structured intent (e.g., repository scope, name pattern, package type) rather than raw query strings. A deterministic query builder then enforces policy, caps result sizes, and removes any possibility of destructive operations.
This separation creates a clear security boundary: the model never invents relationships, and the tooling never relies on the model for core reasoning. If the model provider disappears, the graph‑based engine still produces the same exploitability conclusions and the associated evidence.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Adopt a supply‑chain graph as the source of truth for exploitability analysis. Verify that all relevant data sources (registries, build metadata, SBOMs, runtime inventories) are regularly ingested and that the graph stays in sync with production. Replace direct LLM‑driven prioritization with a two‑step flow: deterministic traversal to produce evidence, followed by LLM‑generated narration. Test reproducibility by disabling the model and confirming that findings and paths remain unchanged. Finally, implement a structured‑intent interface for any model‑driven queries to guarantee that only read‑only, policy‑compliant operations can be issued.
