What is a vulnerability assessment?

What is a vulnerability assessment?

A vulnerability assessment is a systematic, automated process that scans an organisation's systems, networks, and applications to identify and catalogue known security weaknesses — and assigns each weakness a severity rating. The goal is not to exploit vulnerabilities but to enumerate them: to produce a prioritised list of what needs fixing and how urgently.

The analogy that works best is a health check versus a stress test. A vulnerability assessment is the health check — it identifies conditions that could become serious. A penetration test is the stress test — it proves which ones actually are serious by exploiting them under controlled conditions. Both are necessary. The health check tells you where to look; the stress test tells you what breaks.

The output of a vulnerability assessment is a prioritised report with CVSS scores, affected asset lists, and remediation guidance. It does not include proof of exploitation, business impact analysis, or attack narratives — those come from a penetration test.

VA vs penetration test — a direct comparison

Organisations frequently confuse vulnerability assessments and penetration tests, or believe one replaces the other. They serve different purposes and are most effective when used together:

• What could go wrong (VA) vs what does go wrong (Pen Test)
• Automated scanning (VA) vs human-driven exploitation (Pen Test)
• Broad coverage — all systems (VA) vs deep investigation — specific scope (Pen Test)
• Frequent and lower cost — monthly or quarterly (VA) vs annual or milestone-based, higher cost (Pen Test)
• Output: CVSS-rated vulnerability list (VA) vs Output: proof-of-concept exploits, attack narratives, business impact (Pen Test)
• Finds: known CVEs and misconfigurations (VA) vs Finds: chained vulnerabilities, logic flaws, human factors (Pen Test)

The relationship between them is complementary: run vulnerability assessments continuously to track your patching posture, and commission penetration tests to validate whether the vulnerabilities that remain are truly exploitable in your specific environment.

Understanding CVSS scores

Every vulnerability discovered during a VA receives a CVSS score between 0.0 and 10.0. The score determines remediation priority and helps organisations allocate patching effort where it matters most. The scale is divided into four bands:

• Low (0.1–3.9): Minimal risk. Limited exploitability or minimal impact. Address during normal patching cycles.
• Medium (4.0–6.9): Moderate risk. Worth scheduled remediation, particularly if the affected asset is public-facing or high-value.
• High (7.0–8.9): Significant risk. Prioritise for rapid remediation — actively targeted by threat actors.
• Critical (9.0–10.0): Emergency remediation. Widely exploitable with severe impact. Examples: Log4Shell (CVE-2021-44228, CVSS 10.0), EternalBlue (CVE-2017-0144, CVSS 9.3).

CVSS scores are calculated from multiple factors: attack vector (network vs local), attack complexity, privileges required, user interaction required, and the CIA triad impact (Confidentiality, Integrity, and Availability). A vulnerability that is remotely exploitable, requires no authentication, and results in complete system takeover will score near 10.0. A locally exploitable flaw requiring privileged access with limited impact may score below 4.0.

Key vulnerability assessment tools

The vulnerability assessment tooling landscape is mature. These are the platforms used across the industry and covered in CEH v13 and CompTIA Security+:

• Nessus (Tenable): The industry standard for enterprise vulnerability scanning. Extensive CVE coverage, compliance checks, and clear remediation guidance. Used in the majority of professional VA engagements.
• OpenVAS: Open-source alternative to Nessus. Lower cost, actively maintained community edition, strong CVE coverage.
• Qualys VMDR: Cloud-based continuous vulnerability management. Particularly strong for large, distributed environments where agents provide real-time visibility.
• Microsoft Defender Vulnerability Management: Built into the Microsoft ecosystem. Integrates directly with Intune and Defender for Endpoint for automated remediation workflows.
• Rapid7 InsightVM: Live vulnerability and risk view with remediation project tracking and integration into the broader Rapid7 platform.
• Nikto: Open-source web server scanner. Specifically targets web application vulnerabilities — outdated software, dangerous files, misconfigurations.

The vulnerability management lifecycle

A one-time scan is not a vulnerability management programme. Effective vulnerability management is a continuous cycle with five repeating steps:

1. 1
   Asset Discovery

   You cannot protect what you do not know exists. The first step is building a complete inventory of every asset in scope — servers, endpoints, cloud instances, IoT devices, web applications, and APIs. Shadow IT (systems deployed without security team knowledge) is a persistent challenge here.

2. 2
   Scanning

   Automated scanners probe discovered assets against CVE databases and configuration benchmarks, identifying known vulnerabilities, missing patches, and security misconfigurations. Scans should be run on a defined schedule — weekly for internet-facing assets, at minimum monthly for internal systems.

3. 3
   Prioritisation

   Not all vulnerabilities are equal. CVSS score is the starting point, but effective prioritisation also factors in asset criticality (a CVSS 7.0 on a payment system ranks higher than a 7.0 on a development server) and active exploitability (is this CVE being actively exploited in the wild right now?).

4. 4
   Remediation

   Apply patches where available. Where patches do not exist or cannot be applied immediately, implement compensating controls — firewall rules, configuration hardening, or IDS signatures that detect exploitation attempts targeting the vulnerability.

5. 5
   Verification

   Re-scan after remediation to confirm the vulnerability no longer exists. Without verification, patch management processes may appear complete while actually leaving systems exposed due to failed deployments or misapplied changes.