Why do generic LLMs struggle with vulnerability enrichment at scale?

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.

Why This Matters for Security Teams

Generic LLMs struggle at scale because vulnerability enrichment is not a free-form language task. It is a classification and normalization workflow that depends on reliable parsing, stable schemas, and repeatable preprocessing. When teams push broad models into this pipeline, they often get plausible text that looks useful but does not consistently improve triage quality, deduplication, or routing. That creates hidden operational cost, especially when analysts must verify output manually.

The issue is amplified by the way vulnerabilities arrive in real environments: mixed formats, noisy metadata, partial indicators, duplicate records, and inconsistent product naming. Security teams need enrichment that is deterministic enough to support automation and auditability, not just readable summaries. Guidance from the NIST AI Risk Management Framework reinforces that AI systems should be evaluated in context of their actual task and operational impact, while NHIMG’s OWASP NHI Top 10 discussion shows how brittle identity and context assumptions quickly become security problems when workflows are loosely governed. In practice, many security teams discover the failure mode only after enrichment has already polluted downstream reporting and ticketing.

How It Works in Practice

Effective vulnerability enrichment works best when the model is constrained to a narrow, well-instrumented job. The model should receive structured fields such as CVE, product, version, package metadata, exploit references, and asset context, then return a limited set of normalized outputs. That usually means a smaller instruction-tuned model, retrieval-backed prompts, or a rules-first pipeline where the model fills gaps rather than invents the core record.

Current practice also favors deterministic preprocessing before any model call. Canonicalization, vendor mapping, confidence scoring, and source deduplication should happen upstream so the model is not asked to infer what a parser can already establish. This is aligned with the operational guidance in the NIST AI 600-1 Generative AI Profile, which emphasizes task suitability and controlled deployment. For security-specific risk framing, the CSA MAESTRO agentic AI threat modeling framework is useful even outside pure agentic systems because it pushes teams to define boundaries, trust assumptions, and failure paths explicitly.

• Use schema-enforced input fields so enrichment cannot drift into narrative output.
• Prefer task-specific prompts with fixed labels over open-ended summarization.
• Score and filter model output against known sources before it reaches analysts.
• Measure precision, recall, and rework rate, not token cost alone.
• Keep human review for ambiguous cases, especially when product names or exploitability signals are incomplete.

NHIMG’s analysis of the AI LLM hijack breach is a reminder that security workflows fail fast when they rely on assumptions the model cannot verify. These controls tend to break down when enrichment must process high-volume, multi-source feeds with inconsistent vendor taxonomy because the model starts smoothing over differences that matter operationally.

Common Variations and Edge Cases

Tighter enrichment controls often increase implementation overhead, requiring organisations to balance accuracy against speed and maintenance burden. That tradeoff matters because not every vulnerability source has clean metadata, and not every team has the same tolerance for false positives. Current guidance suggests that teams should treat generic LLMs as one component in a larger workflow, not the primary source of truth.

There is no universal standard for this yet, but a practical pattern is emerging. Use a generic model for language normalization, then pass results through deterministic checks, exploit-intelligence lookups, and asset-specific context before assignment or escalation. This becomes especially important when records are sparse, when third-party advisories conflict, or when enrichment is tied to SLAs that affect patch prioritisation. In those cases, the value is not in making the model “smarter,” but in narrowing the decision it is allowed to make.

For teams comparing approaches, NHIMG’s Ultimate Guide to NHIs is useful for understanding why operational identity, not model scale, often determines security workflow reliability. The same logic applies here: if the enrichment pipeline cannot explain why a record was classified a certain way, the output is not ready for automation. In edge cases such as zero-day disclosures, duplicate advisories, or vendor-specific naming collisions, the safest posture is conservative enrichment with explicit confidence thresholds rather than expansive model inference.

Related resources from NHI Mgmt Group

• What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
• Why do organisations struggle with segregation of duties at scale?
• How should security teams use LLMs in vulnerability research without overtrusting them?
• Why do universities struggle to manage identity risk at scale?