GCIH Integrating LLMs with Offensive Operations Practice Question
A security team is integrating an LLM into an automated vulnerability triage pipeline that ingests scanner output and produces prioritized remediation tickets. The team wants to reduce the risk of the LLM fabricating vulnerability details or misattributing CVEs. Which TWO practices best address this concern? (Choose two.)
⚠ Common exam trap
The trap here is treating an LLM's self-reported confidence score or a fine-tuning pass as a factual safeguard, when only external grounding and authoritative validation actually prevent fabricated CVEs.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Validate the LLM's CVE attributions against an authoritative source such as the NVD API before creating tickets.
Fabrication and misattribution are best controlled by grounding output in verifiable evidence and validating identifiers against authoritative sources. Requiring citations to raw scanner findings forces the model to anchor claims, while NVD validation deterministically catches invented or mismatched CVEs. Higher temperature, fine-tuning, and self-reported confidence scores do not provide ground truth and can increase or fail to reduce the risk of incorrect vulnerability details reaching remediation tickets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Fine-tune the model on the organization's historical ticket data to teach it the correct CVE mappings.
Why it's wrong here
Fine-tuning can improve stylistic alignment but does not guarantee factual correctness and may reinforce patterns from outdated or incorrect historical data. It also cannot keep pace with newly published CVEs. Fine-tuning alone is not a reliable safeguard against fabrication because the model can still generate confident incorrect mappings for unseen inputs.
- ✓
Validate the LLM's CVE attributions against an authoritative source such as the NVD API before creating tickets.
Why this is correct
Cross-checking CVE identifiers against NVD or a similar authoritative database catches misattributions and invented identifiers before they propagate into remediation workflows. The LLM may confuse similar CVEs or invent plausible identifiers, and an external validation step provides deterministic ground truth. This is a reliable control against hallucinated or mismatched vulnerability references.
- ✓
Ground the LLM's output by requiring it to cite the specific scanner finding ID and raw output line for every claim it makes.
Why this is correct
Requiring citation of the source finding ID and raw output line forces the model to anchor its statements in retrieved evidence. Claims without a supporting citation can be flagged or rejected automatically. This grounding technique substantially reduces fabrication because the model must point to verifiable input rather than generate plausible-sounding but unsupported vulnerability details.
- ✗
Ask the LLM to express a confidence score for each CVE attribution and auto-approve tickets above 90 percent confidence.
Why it's wrong here
LLM-generated confidence scores are not calibrated probabilities and are frequently high even when the underlying claim is wrong. Auto-approving based on a self-reported score creates a false sense of safety and lets fabricated attributions through. Independent validation against authoritative data is required; the model's own confidence is not a trustworthy gate.
- ✗
Increase the model's temperature setting so it explores a wider range of possible vulnerability interpretations.
Why it's wrong here
Higher temperature increases randomness and creative variation, which directly increases the likelihood of fabricated or inconsistent output. For a triage pipeline that must be factually precise, this is counterproductive. Lower temperature or deterministic decoding is preferred when accuracy and reproducibility matter more than diversity of phrasing.
About these practice questions
One of 322 original GCIH practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCIH practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCIH exam.