Vulnerability assessment

A vulnerability assessment turns raw findings into risk-ranked decisions. NIST SP 800-115 groups the underlying techniques into review techniques (documentation, log and rule-set review, configuration review), target identification and analysis (discovery, port and service identification, vulnerability scanning) and target vulnerability validation (password cracking, penetration testing). An assessment draws mainly on the first two and validates selectively; a penetration test concentrates on the third. Inputs include authenticated and unauthenticated scan results, configuration baselines, architecture diagrams, interviews with system owners and the asset inventory, which supplies the business context no scanner has.

Prioritisation is where the work lies. A CVSS base score describes the intrinsic severity of a flaw under worst-case assumptions; CVSS v4.0 (FIRST, 2023) separates base, threat, environmental and supplemental metrics precisely because the base score alone is a poor proxy for risk. Modern programmes therefore combine several signals: exploitation evidence (CISA's Known Exploited Vulnerabilities catalogue), exploitation probability (FIRST's EPSS, a daily-updated estimate of the likelihood of exploitation within 30 days), exposure (internet-facing or internal, reachable from user networks or only from an admin segment), compensating controls, and asset criticality - what data and business functions depend on the system. Decision frameworks such as CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) encode this as a decision tree with outcomes Track, Track*, Attend and Act, replacing a single numeric threshold.

Validation removes false positives before remediation effort is spent: a version-based finding may be moot because a backported fix is installed, the vulnerable module is not loaded, or the feature is disabled. Conversely, absence of findings is not proof of absence - unscanned assets, missing credentials and custom applications all produce silent gaps, which is why coverage must be reported alongside findings.

The output is a remediation plan with owners and deadlines, plus explicit risk decisions for items that cannot be fixed in time: mitigation (segmentation, virtual patching, configuration change) or formal acceptance with an owner and an expiry date. This connects the assessment to the organisation's risk management: ISO/IEC 27002:2022 control 8.8 (management of technical vulnerabilities) requires obtaining information about vulnerabilities, evaluating exposure and taking appropriate measures, and NIS2 Art. 21(2)(e) names vulnerability handling and disclosure among the mandatory measures. Assessments recur, because every new CVE, deployment and configuration change alters the picture; a one-off assessment is a snapshot of a moving target.