What a Vulnerability Risk Assessment Actually Looks Like
A vulnerability scan gives you a list. A risk assessment turns that list into a set of decisions — what to fix first, what to accept, what to mitigate in other ways, and why.
The distinction matters because most vulnerability scanners will find more issues than any organisation can remediate simultaneously. CVSS scores are a useful starting point for severity, but they don't tell you which vulnerabilities are actually exploitable in your environment, or which ones an attacker would be most likely to use. That context is what a risk assessment adds.
This post walks through a worked example: a production web server running Apache 2.4.57, assessed using Nikto and cross-referenced against the NIST National Vulnerability Database. The approach follows NIST SP 800-30, which is the methodology we use for structured vulnerability risk work.
Step 1: The Scan
Nikto is a web server scanner — it checks for outdated server software, exposed files, insecure configurations and other common web server issues. Run against the web server, the key finding was the server banner: Apache/2.4.57 (Ubuntu).
The version disclosure itself is a finding (as covered in our security headers post — suppressing this takes one line of Apache config). More importantly, it gives us the Apache version to look up.
Step 2: CVE Research
Searching for Apache 2.4.57 vulnerabilities across NVD (nvd.nist.gov), CVEdetails.com and the Apache security advisory page returns a cluster of CVEs fixed in versions 2.4.59 and 2.4.60 that apply to this server:
CVE-2024-38476 — Critical (CVSS 9.8)
A vulnerability in how Apache handles backend response headers allows an attacker to cause sensitive information disclosure or Server-Side Request Forgery (SSRF). Public proof-of-concept code exists. This is the highest priority finding.
CVE-2024-40898 — Important
A mod_rewrite vulnerability on Windows systems that can leak NTLM hashes to a malicious server. Lower priority here since the server runs Ubuntu, but worth noting for completeness.
CVE-2024-38477 — Important
A null pointer dereference in mod_proxy that can crash the server — a Denial of Service vector. Not as severe as the SSRF vulnerability but still requires remediation.
CVE-2024-24795 — Medium
HTTP response splitting that could enable HTTP desync attacks. Fixed in 2.4.59.
Step 3: Contextualise Using NIST SP 800-30
NIST SP 800-30 frames risk as a function of threat likelihood and impact. For each finding, you need to assess not just what the vulnerability is, but:
- Who is likely to exploit it? — opportunistic scanners, targeted attackers, nation-state actors?
- What is the realistic exploit path? — is it network-accessible? Does it require authentication? Is there public exploit code?
- What is the business impact if exploited? — data exposure, service disruption, reputational damage, regulatory consequences?
For CVE-2024-38476 on a public-facing production web server:
Threat likelihood: High. CVSS 9.8. Public PoC code available. Web servers are continuously scanned by automated exploit tools. The vulnerability does not require authentication.
Impact: Very High. SSRF from a web server in an MSP environment could allow an attacker to pivot to internal systems, access metadata services in cloud environments, or exfiltrate data that should not be accessible from the internet. In an environment handling client data, the regulatory consequences of a breach (UK GDPR notification, reputational damage to clients) amplify the impact further.
Overall risk: Very High. This finding requires immediate remediation.
Contrast this with CVE-2024-40898, the NTLM hash leakage vulnerability. On a Linux server, the mod_rewrite paths that trigger this vulnerability don't behave the same way. The likelihood of successful exploitation in this context drops from High to Low-Medium. The risk is still real — if the server configuration changes or the analysis is wrong — but the urgency is lower than the critical SSRF.
Step 4: The EPSS Factor
One additional data source worth incorporating is EPSS — the Exploit Prediction Scoring System. Where CVSS scores severity based on characteristics of the vulnerability, EPSS scores the probability of exploitation in the wild within the next 30 days, based on real-world threat intelligence data.
A vulnerability with a high CVSS score and a low EPSS score may be severe in theory but rarely exploited in practice. A vulnerability with a moderate CVSS score and a high EPSS score may be actively being used by attackers right now. EPSS data is available free from first.org and is increasingly included in commercial vulnerability management platforms.
Using both together — CVSS for severity characterisation, EPSS for exploitation likelihood — gives a more accurate picture than either alone.
Step 5: Recommendations
The output of the risk assessment is a prioritised remediation plan, not a ranked list of CVSS scores:
Immediate (within 24-48 hours): Upgrade Apache to 2.4.62 (which fixes all identified CVEs). If an immediate upgrade isn't possible, implement compensating controls — restrict access to the affected mod_proxy and mod_rewrite functionality, implement a WAF rule to detect SSRF attempts, and increase monitoring for anomalous outbound connections from the web server.
Short term (within one week): Suppress server version headers (ServerTokens Prod, ServerSignature Off). Verify that Apache upgrade has resolved all identified CVEs by checking the installed version and re-running the scan.
Ongoing: Subscribe to Apache security advisories. Establish a patch management cadence that brings high/critical severity patches to production within 14 days — which aligns with the Cyber Essentials requirement. Consider a Web Application Firewall (WAF) for any public-facing server handling sensitive data.
What Makes a Good Risk Assessment
The difference between a useful vulnerability risk assessment and a document that sits unread on a shared drive comes down to a few things:
Context-specificity. A CVSS score is context-free. A risk rating needs to reflect your environment — your server's operating system, your network architecture, your business function, your regulatory exposure. CVE-2024-40898 is Important on Windows and Low-Medium on Ubuntu. The scan output doesn't know which you're running; the assessment does.
Actionable output. The question the assessment should answer is: "what should I do first, and by when?" Not "here is a list of things that are bad."
Evidence. NIST SP 800-30 is explicit that risk assessments should be evidence-based. The CVE IDs, CVSS scores, EPSS data, and PoC references aren't just citations — they're the evidence that supports the risk rating and the urgency of the remediation recommendation.
A vulnerability scanner tells you what's there. A risk assessment tells you what to do about it — and in what order.
For MSPs managing security across multiple clients, building a repeatable vulnerability assessment process — scan, CVE research, contextualise, prioritise, recommend — is more valuable than any individual finding. The process is what ensures that the next assessment is as rigorous as this one, regardless of who does it.