Vulnerability Analysis and Validation
Scanner output is a hypothesis
Automated scanners generate both false positives (version-based guesses, backported patches, banner spoofing) and false negatives (business logic flaws, chained conditions, authenticated-only issues). Your job is validation: reproduce the condition manually, confirm the vulnerable code path, and record minimal, non-destructive proof.
Scoring and prioritisation
CVSS base metrics describe the vulnerability in the abstract - attack vector, complexity, privileges required, user interaction, scope, and confidentiality/integrity/availability impact. Environmental and temporal modifiers, plus asset criticality, determine actual risk. A high base score on an isolated lab-grade host may rank below a medium score on an internet-facing authentication service. Exploitability (public exploit, weaponised, authenticated?) is a separate axis from impact.
Proving without damaging
Use the least intrusive payload that demonstrates the condition: id rather than a reverse shell; SELECT @@version rather than data modification; a benign out-of-band DNS callback rather than file exfiltration. Never run destructive verification against production unless the ROE explicitly says so.
Traps in exam questions
- Equating CVSS 9.8 with "fix first" without considering exposure and business context.
- Reporting a banner version as proof of a CVE without confirming the patch level.
- Treating a second scanner's agreement as validation - two tools reading the same banner agree about nothing.
- Reporting theoretical or unexploited findings as confirmed.
Rule of thumb
No finding enters the report without a reproducible, minimal-impact verification step and the evidence to prove it.
Worked example: a scanner flags an outdated TLS library. Manual testing shows the host negotiates a deprecated cipher but the vulnerable function is unreachable. You downgrade severity and describe the configuration weakness accurately instead of citing the CVE.