Vulnerability identification and analysis
Vulnerability identification and analysis
This domain tests whether you can find weaknesses and then reason about them: verify what a scanner claims, classify the root cause, and place it in the client's business context rather than pasting raw tool output into a report.
Core rules and concepts
- Every finding is verified manually. Scanner output is a hypothesis until you reproduce it with a request, a payload or a configuration extract.
- Classify consistently. Reference CVE for the specific instance, CWE for the weakness class (for example CWE-89 for SQL injection), and CVSS v3.1 or v4.0 for the base score. Note that the base score is context-free.
- Contextualise severity. Exposure (internet versus internal), asset criticality, data sensitivity, compensating controls such as a WAF or network segmentation, and exploit likelihood (EPSS, public exploit availability) all move the real rating.
- Look for chains. A medium-severity information leak plus a medium-severity authentication weakness can equal a critical path. Analyse combinations, not just isolated items.
- Identify the root cause. A missing patch, a design flaw and a misconfiguration need different remediation owners and different language.
Worked example
A scanner reports "TLS 1.0 enabled" as medium on an external IP. Reasoning: confirm which device terminates TLS, whether authentication traffic traverses it, whether the suite list permits forward secrecy, and whether the client's PCI DSS obligations forbid the protocol outright. If the endpoint carries cardholder login traffic and the client is in scope for PCI DSS, raise it to high with the compliance driver cited. If it is a marketing brochure site with no session data, keep it low and say why. The analysis, not the tool, sets the rating.
Traps that cost marks
- Reporting unverified scanner output and being challenged during the retest.
- Using the CVSS base score alone without a contextual modifier.
- Labelling informational observations as vulnerabilities, which dilutes the report.
- Missing a chained exploit path because findings were reviewed one at a time.
- Describing the symptom rather than the root cause, so remediation fixes the instance and not the class.