What a vulnerability assessment actually finds

A vulnerability assessment isn't a pass/fail test — it's a prioritized map of exposure, and the value is almost entirely in the prioritization, not the raw finding count.

Why raw finding counts are close to meaningless on their own

A first-time vulnerability scan on a moderately complex environment routinely turns up hundreds or even thousands of findings — outdated library versions, missing security headers, weak TLS configurations on internal-only systems. A report that just lists all of them, unranked, is nearly useless: it either causes teams to panic disproportionately or, more often, causes them to shelve the report entirely because it feels unactionable. The actual value of an assessment is in ruthlessly prioritizing what's genuinely exploitable and impactful, versus what's technically a finding but practically low-risk.

How we actually prioritize: exploitability over theoretical severity

A CVSS severity score alone doesn't tell you what matters — a "critical" severity vulnerability on a system with no external exposure and no path to sensitive data is a lower real-world priority than a "medium" severity finding on an internet-facing system handling customer data. We prioritize based on actual exploitability (is there a known, working exploit in the wild, or is this theoretical) combined with actual business impact (what data or system access would a successful exploit provide) — not the abstract CVSS number alone.

The categories of findings that show up most consistently

Across the assessments we run, a few categories account for most of the genuinely high-priority findings: outdated software with known, actively exploited vulnerabilities (unpatched systems are still the single most common real-world attack vector, not exotic zero-days), overly permissive access — accounts or services with far more permission than their actual function requires, misconfigured cloud storage (publicly accessible S3 buckets or equivalent are a recurring, entirely preventable finding), and weak or default credentials on internal systems that were never intended to be internet-facing but ended up exposed through a misconfiguration.

A concrete example

A manufacturing client's first assessment returned 847 raw findings from automated scanning across their environment. After our prioritization pass — filtering for actual exploitability and business impact — 19 were classified as requiring immediate remediation. Among those 19: an internet-facing admin panel running software with a known, actively exploited remote code execution vulnerability with a patch available for over a year, and a cloud storage bucket containing internal financial documents that was misconfigured for public read access. Both were remediated within 48 hours of the report. The remaining roughly 828 findings were genuine but lower-priority — logged, tracked, and scheduled into normal patch cycles rather than treated as emergencies.

Why this should be recurring, not a one-time exercise

New vulnerabilities get disclosed constantly, and environments change — new services get deployed, configurations drift. A single point-in-time assessment reflects your risk on the day it ran, not an ongoing state. We recommend recurring assessments (typically quarterly for the full scope, with continuous automated scanning for known-CVE detection in between) rather than a single annual exercise.

How Ndakum approaches it

Vulnerability assessment and prioritization is core to our Cybersecurity work, typically using Qualys or Nessus for scanning — but the real value we add is the exploitability-based prioritization on top of the raw scan output.