Vulnerability intelligence at scale needs context, not bigger LLMs

At a glance

What this is: This analysis argues that real-time vulnerability intelligence works best when specialised models are given the right context, not when generic LLMs are made larger.

Why it matters: For IAM, NHI, and security teams, better vulnerability prioritisation depends on trusted context, faster enrichment, and control over where automated intelligence pipelines can be used operationally.

👉 Read Oligo Security's analysis of real-time vulnerability intelligence with NVIDIA AI

Context

Vulnerability intelligence is the process of turning raw advisory data, runtime signals, and code metadata into a decision about what actually matters. The problem is not a shortage of findings, but a shortage of context that tells teams which vulnerabilities are reachable, exploitable, or relevant to the environment. In identity-heavy programmes, that same context problem appears when access and entitlement data are incomplete.

Oligo Security's article is really about the economics and accuracy of enrichment pipelines, not just model performance. For security teams, the important question is whether the pipeline can support operational prioritisation at scale without creating blind spots, wasted triage, or slow response cycles.

Key questions

Q: How should security teams prioritise vulnerabilities when code scans and runtime data disagree?

A: Treat runtime evidence as the tie-breaker. If a vulnerability appears in static analysis but the vulnerable function is never executed, it should not compete with issues that are both present and reachable. The right process combines advisory enrichment, code-path validation, and runtime confirmation before remediation is escalated.

Q: Why do generic LLMs struggle with vulnerability enrichment at scale?

A: Generic LLMs often add cost without adding enough task-specific precision. Vulnerability enrichment depends on structured inputs, domain cues, and consistent preprocessing, so a smaller instruction-tuned model can outperform a larger one when the workflow is tightly scoped and operationally well designed.

Q: What signals show that a vulnerability intelligence pipeline is working?

A: Look for lower enrichment latency, better function-level coverage, fewer false positives, and more confident links between advisories and actual runtime exposure. A pipeline is working when it reduces triage noise and helps teams decide faster which issues are truly relevant.

Q: How can teams avoid spending too much on enrichment pipelines?

A: Right-size the model for each task, keep preprocessing disciplined, and measure cost against validated security outcomes instead of raw throughput. If the pipeline enriches quickly but does not improve prioritisation, the spend is not translating into risk reduction.

Technical breakdown

Why function-level vulnerability enrichment matters

Traditional vulnerability databases describe a CVE at package or advisory level, but that is not enough to decide whether a specific function is actually exposed in a running application. Function-level enrichment ties advisory data to code paths, runtime traces, and patch context so defenders can distinguish theoretical risk from active risk. This is especially important when multiple advisories, obfuscated strings, or incomplete metadata make simple matching unreliable. The real technical shift is from listing vulnerabilities to proving relevance.

Practical implication: Use function-level evidence to decide which vulnerabilities deserve immediate remediation.

Why right-sized models outperform generic LLMs in security pipelines

Security enrichment tasks do not all require the same model class. Reasoning-heavy steps may need a larger instruction-tuned model, while high-volume detection and extraction tasks often work better with smaller, faster models optimised for the job. The article shows that performance gains come from matching model capacity to task complexity and from feeding the model better context, not from assuming larger means better. That is an architectural design choice, not a generative AI slogan.

Practical implication: Separate deep reasoning workloads from latency-sensitive detection workflows.

How preprocessing changes CVE coverage and confidence

Preprocessing is the step that normalises and enriches source material before the model reasons over it. In vulnerability intelligence, this can mean pulling in GitHub Security Advisories, commits, and line references so the model has enough structure to identify vulnerable functions accurately. Without that layer, enrichment pipelines tend to miss distributed evidence, undercount affected code, or produce incomplete outputs. The article's key technical point is that preprocessing is not overhead, it is part of the security control plane.

Practical implication: Treat preprocessing as a mandatory control layer in vulnerability intelligence pipelines.

NHI Mgmt Group analysis

Context quality is now the limiting factor in vulnerability intelligence. The article shows that better outputs came from feeding the model the right advisory and runtime context, not from using a larger generic model. In practice, that means the bottleneck is no longer raw detection capacity but the quality of the evidence pipeline that supports prioritisation.

Function-level relevance is the new threshold for actionability. A CVE that exists in a dependency tree is not automatically a remediation priority if the vulnerable code path never runs. This is the same failure mode security teams see when they triage at package level instead of exposure level. Practitioners should treat execution evidence as the deciding signal, not the advisory alone.

Identity and security programmes both suffer when context is separated from control decisions. In NHI and IAM operations, teams often know a credential, token, or entitlement exists but cannot prove its real usage footprint. The article's pipeline logic mirrors that governance problem: without runtime validation, teams can spend heavily on findings that do not change risk.

Specialised AI security pipelines are becoming a governance issue, not just a tooling choice. Once enrichment can happen within seconds of publication, the question becomes how quickly teams can translate signal into control action. That affects vulnerability management, incident response, and eventually how machine and human identity programmes share prioritisation data.

Ephemeral trust windows are not the only issue. Context windows are too. The useful concept here is context debt: the gap between what the model needs to know and what the pipeline can reliably provide at decision time. Security teams should treat that gap as an operational risk because it directly shapes false positives, false negatives, and remediation cost.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why enrichment and validation still matter at the point of control.
• For broader context on secrets sprawl and remediation pressure, see Guide to the Secret Sprawl Challenge.

What this signals

Context debt is becoming a measurable programme risk. When security teams cannot quickly connect an advisory to a real code path or runtime footprint, they either over-prioritise noise or under-prioritise exposure, and both outcomes weaken remediation discipline. That is why the governance problem is no longer only detection, but evidence quality.

The practical signal for IAM and NHI teams is that security pipelines are moving closer to control systems. If vulnerability enrichment can happen within seconds of publication, then entitlement review, workload identity governance, and remediation workflows need to consume that signal without waiting for periodic manual triage.

The article's approach aligns well with broader identity governance thinking. Teams that already struggle to reconcile secrets, workloads, and access paths should expect similar value from structured enrichment, and should compare their current controls with the NIST Cybersecurity Framework 2.0 before they scale automation.

For practitioners

• Build a function-level prioritisation layer Require runtime evidence, code-path relevance, and advisory enrichment before a vulnerability enters the top remediation queue. Use execution data to separate installed-but-unused dependencies from genuinely exposed functions.
• Separate reasoning from extraction workloads Use larger models only where deeper correlation is needed and reserve smaller models for high-volume enrichment, NER, and classification. This keeps latency and cost under control without sacrificing task quality.
• Standardise preprocessing inputs Pull advisory feeds, GitHub Security Advisories, patch metadata, and code references into a consistent preprocessing stage so downstream models do not have to infer structure from incomplete text.
• Measure remediation against exposure, not volume Track how many findings are confirmed in runtime, how many are noise, and how long it takes to move from publication to validated priority. That gives teams a better control signal than raw alert counts.

Key takeaways

• Vulnerability management improves when teams can prove that a vulnerable function is actually reachable in runtime, not merely listed in an advisory.
• The article's results show that smaller, task-specific models can deliver faster and cheaper enrichment than general-purpose LLMs when the pipeline is properly structured.
• Security teams should treat preprocessing, runtime validation, and task-specific model selection as control decisions, not implementation details.

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.
• Context debt: The gap between the information a security model needs to make a reliable decision and the information the pipeline actually provides at decision time. It shows up as false positives, false negatives, and slow triage when enrichment inputs are incomplete or inconsistent.
• Right-sized model: A model selected for the complexity and latency profile of a specific task rather than for general capability. In security pipelines, right-sizing means using larger models for deep reasoning and smaller models for extraction or classification where speed and cost matter more.
• Preprocessing layer: The stage that normalises and enriches source material before model inference. In vulnerability workflows, preprocessing can add advisories, commits, metadata, and other structured cues so downstream analysis has enough context to produce accurate and consistent results.

What's in the full article

Oligo Security's full article covers the operational detail this post intentionally leaves for the source:

• The full model comparison behind the 55x cost reduction and 2.5x response-time improvement
• The preprocessing design used to increase CVE coverage and improve function-level enrichment
• The runtime validation method that cross-checks suggested functions against production execution data
• The pipeline architecture used to move from evaluation to production without sacrificing accuracy

👉 Oligo Security's full article covers the pipeline design, accuracy trade-offs, and enrichment workflow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity governance in your organisation, it is worth exploring.