Vulnerability intelligence at scale needs context, not bigger LLMs

At a glance

What this is: This is a vendor analysis of real-time vulnerability enrichment that argues security teams need better context, not larger LLMs, to identify which CVEs actually affect deployed software.

Why it matters: For IAM and security teams, the lesson is that prioritisation depends on runtime evidence and scoped context, which is the same governance problem that appears when deciding which identities, secrets, and dependencies are truly in use.

By the numbers:

• The pipeline cut inference cost by 55x while keeping accuracy unchanged.
• Oligo Security says the new pipeline covered about 20% more CVEs after adding NVIDIA preprocessing.

Context

Vulnerability intelligence is the process of turning advisories, code signals, and runtime evidence into a decision about what actually matters. In this article, the primary governance problem is not model capability alone but whether enrichment pipelines can connect a CVE to the functions and dependencies that are really present in production.

That problem sits squarely in operational security governance: teams do not need more noise, they need narrower, higher-confidence context around exposure. When runtime traces, advisories, and patch diffs are analysed together, the question shifts from volume to evidence quality.

Oligo Security uses that argument to show why specialised pipelines can outperform broader model-first approaches for vulnerability prioritisation. The starting position is typical of modern security operations, where scale exposes the gap between raw findings and actionable risk.

Key questions

Q: What breaks when vulnerability enrichment lacks runtime context?

A: Teams end up triaging installed components as if they were active exposure, which creates false positives and hides true risk in code paths that actually execute. Without runtime context, prioritisation is based on possibility rather than evidence, so remediation queues drift away from operational reality.

Q: Why does function-level evidence matter more than package-level findings?

A: Package-level findings only prove that a dependency exists. Function-level evidence shows whether the vulnerable behaviour is reachable in the deployed application, which is the difference between a theoretical issue and a real attack surface. That makes function-level context the better unit for decisioning.

Q: How should security teams decide when to use smaller models in vulnerability analysis?

A: Use smaller instruction-tuned models when the task is bounded, repetitive, and domain-specific, such as entity extraction or advisory parsing. Reserve larger models for cases that require deeper cross-document reasoning. The decision should be based on task shape, latency, and cost, not model branding.

Q: What is the difference between advisory data and decision-grade vulnerability intelligence?

A: Advisory data describes the vulnerability. Decision-grade intelligence connects that vulnerability to the functions, runtime traces, and deployed dependencies that prove whether it matters in your environment. The second is operationally useful because it supports prioritisation, while the first mainly supports awareness.

Technical breakdown

Why function-level vulnerability context matters

A CVE tells you that a component contains a known flaw, but it does not tell you whether the vulnerable code path is actually executed in your environment. Function-level vulnerability intelligence narrows that gap by mapping advisory data, patches, and runtime traces to the specific functions that matter. That lets enrichment systems distinguish installed-but-unused code from active risk. In practice, this is not a model-size problem. It is a context-assembly problem: the pipeline must join noisy security artefacts into evidence that supports a remediation decision, not just a classification label.

Practical implication: prioritise pipelines that can prove code-path use, not just enumerate affected packages.

Why smaller instruction-tuned models can beat larger general-purpose LLMs

For high-volume security workflows, latency and cost matter as much as raw reasoning capacity. A smaller instruction-tuned model can outperform a larger general-purpose LLM when the task is tightly scoped, the vocabulary is domain-specific, and the inputs are preprocessed into the right shape. That is especially true for named entity recognition, advisory parsing, and function extraction. The technical lesson is that model choice should follow task structure, not model prestige. Security teams should expect better economics when they separate reasoning-heavy steps from repetitive classification steps.

Practical implication: split enrichment workloads into reasoning and extraction stages instead of sending every task to the largest model.

How preprocessing changes CVE coverage and decision quality

Preprocessing is the step that turns fragmented advisories into usable security context. In this article, the pipeline improves coverage by enriching CVEs with GitHub Security Advisories and other structured signals before inference runs. That matters because single-source advisory data often omits the details needed to identify vulnerable functions or confirm exploitability. Without that preprocessing layer, models see too little structure and produce incomplete outputs. With it, the system can cross-reference functions, commits, and runtime presence, which makes the enrichment output defensible enough for operational use.

Practical implication: treat preprocessing as part of the control plane for vulnerability triage, not as optional data cleanup.

NHI Mgmt Group analysis

Context quality, not model size, is the real control variable in vulnerability intelligence. Security teams rarely fail because they lack more CVE data. They fail because the data they already have is not assembled into a decision-grade view of what is actually running. The practical implication is that enrichment architecture should be judged by evidence density and decision precision, not by raw model scale.

Function-level exposure is the missing governance layer in vulnerability prioritisation. A package-level alert says something is installed, but not whether the vulnerable code path is active. That distinction changes the entire remediation queue, because runtime context determines whether a finding is theoretical or urgent. The practical implication is that teams should govern vulnerabilities at the function and execution layer, not only at the package inventory layer.

Specialised security pipelines will continue to replace broad general-purpose inference for operational triage. The pattern here is not unique to CVEs. Any security workflow that depends on domain-specific evidence, from code reachability to identity trust signals, will favour smaller, better-shaped models over larger generic ones. The practical implication is that security architecture should be designed around task specificity, not model generality.

Identity and vulnerability programmes are converging around the same evidence problem. Whether a team is validating a vulnerable function, a service account, or an access path, the issue is the same: prove current use before spending response effort. That makes runtime evidence a shared governance theme across vulnerability management, NHI oversight, and access decisioning. The practical implication is to unify evidence standards across security domains instead of letting each one invent its own.

Right-sized inference creates a new operational ceiling for real-time security analysis. When enrichment can run in seconds and stay economically viable, the bottleneck shifts from compute cost to process design. That changes what is realistic for continuous triage, near-real-time exposure scoring, and response automation. The practical implication is that teams should reassess which enrichment steps belong in the detection path rather than the offline reporting path.

What this signals

Function-level exposure is becoming the practical boundary for vulnerability governance. Teams that still triage at package level will keep over-prioritising noise and under-prioritising reachability. The broader lesson is that security operations need evidence of active use before response resources are committed.

Specialised inference pipelines are now a governance choice, not just an architecture choice. When a workload depends on near-real-time enrichment, cost and latency determine whether the control is actually usable. That is why task-specific model design is increasingly part of the vulnerability management programme itself.

For practitioners

• Prioritise function-level evidence Require enrichment outputs to identify whether vulnerable functions are actually present and executed in production before they enter the remediation queue.
• Separate extraction from reasoning Use smaller, task-specific models for named entity recognition and advisory parsing, and reserve larger models for cases that genuinely need deeper inference.
• Add runtime validation to triage Cross-check suggested vulnerable functions against runtime traces so teams can distinguish installed dependencies from code paths that create real exposure.
• Treat preprocessing as control logic Build advisory enrichment and code-context joining into the pipeline itself so coverage gaps do not surface only after a vulnerability has been published.

Key takeaways

• Vulnerability management fails when advisories are treated as complete truth instead of as inputs that still need runtime context.
• The article shows that right-sized, task-specific inference can improve both speed and coverage without sacrificing accuracy.
• Security teams should judge enrichment pipelines by whether they surface decision-grade evidence about active code paths.

Key terms

• Function-level vulnerability intelligence: A security approach that determines whether a vulnerable function is actually present and exercised in a real environment. It goes beyond package-level vulnerability lists by combining advisory data, runtime evidence, and code-path analysis to support more accurate remediation decisions.
• Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.
• Advisory Enrichment: Advisory enrichment is the process of adding structured security meaning to vulnerability notices by combining them with patch data, dependency graphs, and other signals. The goal is to turn incomplete advisory text into decision-grade intelligence for remediation and prioritisation.
• Task-Specific Model: A task-specific model is built to perform a narrow function rather than many general-purpose language tasks. These models can be more efficient because they avoid unnecessary compute for broad capabilities. In practice, they are often preferable when the use case is stable and well defined.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.