Vulnerability Assessment 2026: Method, Tools and Report Template

[Blackhatpakistan]

A vulnerability assessment is the structured, non-destructive process of finding, classifying, and prioritizing security weaknesses across an environment - networks, applications, containers, cloud accounts - without exploiting them, and NIST SP 800-115 is the technical guide that defines how the discovery, analysis, and reporting phases are supposed to run. It answers one question: what is exposed, how badly, and in what order do we fix it.

TL;DR - Run a vulnerability assessment as a repeatable six-step loop: scope the asset inventory, scan with authenticated and unauthenticated checks, validate the hits to kill false positives, score with CVSS v4 base plus EPSS and CISA KEV context, write a report owners can act on, then retest the fixes. OpenVAS for full-network baselines, nmap for service truth, nuclei for fast template coverage. The output that matters is a prioritized remediation queue with owners and dates - a scanner dump with 4,000 rows and no priorities is paperwork, not security.

WHAT A VULNERABILITY ASSESSMENT ACTUALLY IS

An assessment is discovery and ranking, not exploitation. No payload execution, no privilege escalation, no pivoting - those belong to a penetration test. The deliverable is a register of weaknesses, each one tied to an asset, a severity, a business context, and a fix. Three properties separate a real assessment from running a scanner once:

- Repeatable - the same scope and method every cycle so results compare across quarters.

- Authenticated - credentialed scans see patch levels and misconfigs that external sweeps miss entirely.

- Prioritized - severity is the start of triage, not the end of it. A 7.5 on an internet-facing login form outranks a 9.8 on a printer nobody can reach.

Assessments map directly to compliance evidence too: PCI DSS 11.3.2 wants quarterly external scans from an Approved Scanning Vendor, HIPAA risk analysis wants an inventory-backed annual review, and ISO 27001 Annex A gathers the same artifact. Treat the register as the single source of truth and the audits get quiet.

ASSESSMENT VS PENETRATION TEST

The confusion costs organizations real budget. Core differences:

- Goal - assessment enumerates and scores known weakness classes; a pentest simulates an attacker chain to prove impact.

- Method - assessment is tool-driven with light manual validation; pentest adds manual exploitation, custom payloads, social engineering.

- Output - assessment produces a prioritized vulnerability register; pentest produces an attack narrative with proven paths.

- Frequency - assessment runs quarterly or monthly; pentest runs annually or after major change.

- Rules - both need written scope, but assessment tolerates noisy scanning where pentest needs stealth to model real adversaries.

Buy the assessment first. A pentest against an unpatched, uninventoried estate just tells you what the scanner would have listed cheaper.

FOUR TYPES OF ASSESSMENT

- Network - internal and external sweeps of hosts, ports, services, and OS patch state. External answers "what can the internet touch," internal answers "what can a workstation reach after one phish."

- Application - SAST plus DAST against web apps and APIs: OWASP Top 10 coverage, auth flows, business logic. This is where SQL injection and access control findings surface.

- Cloud - configuration posture across AWS, Azure, or GCP: public storage buckets, over-scoped IAM roles, disabled logging, unencrypted volumes. CIS Benchmarks are the reference hardening maps.

- Container and CI - image base-layer CVEs, secrets committed to repos, and pipeline steps that run arbitrary code on merge. An assessment that skips the pipeline misses where most modern breaches start.

THE SIX-STEP METHOD

- Inventory - every asset, owner, and environment tag. Scanners only test what you feed them, and the gap between the CMDB and reality is where breaches live.

- Scan - authenticated internal sweeps, unauthenticated external sweeps, application DAST, cloud config audit. Run against staging first when the target is fragile.

- Validate - reproduce each high and critical finding manually. Scanners report symptoms; you need the root cause confirmed before anyone spends remediation hours.

- Score - CVSS v4 base score for severity, EPSS for exploit probability, CISA KEV for confirmed in-the-wild exploitation. Combine the three or you will over-patch the wrong thing.

- Report - one page for executives with business risk language, technical detail per finding with evidence and fix, owners assigned, target dates set.

- Retest - verify the fix, close the entry, and keep the finding history. A register without retest tracking is a to-do list nobody reads.

SCANNING WITH OPENVAS AND NMAP

OpenVAS (GVM) gives the full-network baseline. The default "Full and very deep" config is too slow for weekly runs - keep a "Full and fast" task for cadence and schedule the deep profile monthly. nmap then provides the service-level truth the scanner glosses over:

# 1 - discover live hosts, then full service sweep

nmap -sn 10.10.10.0/24 -oG hosts.gnmap

nmap -sV -sC -p- --min-rate 1500 -iL hosts.gnmap -oX sweep.xml

# 2 - targeted vuln scripts against the interesting ports

nmap --script vuln -p 443,445,3389 10.10.10.24 -oN vuln.txt

For web estates, nuclei runs template-based checks in minutes instead of hours - keep templates pinned and reviewed, because an auto-updated template set can start probing endpoints your scope excludes:

nuclei -u https://staging.example.com -t cves/ -severity medium,high,critical \

  -H "Authorization: Bearer $SCAN_TOKEN" -o nuclei-findings.txt

Run everything against staging first, throttle destructive templates, and never point a scanner at production during a release freeze without written sign-off.

SCORING WITH CVSS V4, EPSS AND KEV

CVSS v4 base score tells you severity but ignores your environment. EPSS gives daily exploit-probability percentages, and the CISA Known Exploited Vulnerabilities catalog confirms what attackers already use. A finding scoring CVSS 8.8 with EPSS 0.4% and no KEV entry waits; the same 8.8 sitting in KEV gets a 48-hour clock.

# CVSS v4 base score for a network-reachable, low-complexity finding

python3 -c "from cvss import CVSS4; print(CVSS4('CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N').score)"

# EPSS probability for the affected product, plus KEV check

curl -s "https://api.first.org/data/v1/epss?product=openssl&limit=1" | python3 -m json.tool

curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | grep -c "CVE-2024-"

Score once per finding, store the numbers in the register, and recalculate on retest. Scores drift as EPSS moves - a finding triaged last quarter may deserve promotion today.

VALIDATING BEFORE YOU REPORT

Every high and critical gets manual confirmation. The scanner said what it saw; you prove what it means. Check authentication context, confirm the vulnerable component version directly, and reproduce the condition with the minimum proof that leaves no data touched:

# confirm the exposed admin path is real, not a WAF ghost

curl -sk -o /dev/null -w "%{http_code}\n" "https://staging.example.com/admin"

curl -skI "https://staging.example.com/admin" | grep -i "server:"

# confirm the component version from the response itself

curl -s "https://staging.example.com/" | grep -io "openssl/[0-9.]*"

# replay the exact request in Burp Repeater, compare status and body diff

Two full-time analysts spend roughly an hour per hundred findings on validation, and that hour deletes the false-positive pile that kills scanner credibility with engineering teams.

REPORT TEMPLATE THAT GETS FIXED

The report format decides whether findings get fixed or filed. One page of executive summary first, then per-finding entries in this shape:

## FINDING-014 - Inactive TLS 1.0 on external load balancer

Severity : CVSS v4 7.1 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N)

EPSS     : 12.4%   KEV: no   Asset: lb-ext-01 (10.10.10.5:443)

Evidence : nmap ssl-enum-ciphers shows TLSv1.0 accepted, CBC suites

Impact   : downgrade attacks against session traffic on the login path

Fix      : disable TLS 1.0/1.1 at the listener, keep TLS 1.2+ with AEAD only

Owner    : platform-team   Due: sprint-41   Retest: pending

Executives read the first page. Engineers read their own finding block. Nobody reads a 400-row scanner PDF - attach it as an appendix, never as the deliverable.

CADENCE: HOW OFTEN TO RUN IT

- External network - monthly minimum, weekly if the estate changes fast.

- Internal network - quarterly with credentialed scans, monthly for regulated environments.

- Application - every release candidate via DAST in CI, full authenticated pass each quarter.

- Cloud config - continuous with drift detection (AWS Config, Security Hub, or open-source equivalents), weekly review of new findings.

- Container images - build-time gate on critical CVEs, registry re-scan when new CVEs land for installed packages.

Retest every high and critical fix within ten business days of closure. The cycle only works when the register shrinks - and the register only shrinks when someone retests.

FAQ

- Q: How long does a vulnerability assessment take?

A: External network sweep runs in hours; a credentialed internal assessment over a few thousand hosts takes two to four days including validation, and application assessments scale with authenticated scope.

- Q: Do we need credentials for the scan?

A: For internal assets, yes - credentialed scans check patch state, local misconfigs, and installed software that unauthenticated sweeps cannot see. External scans stay unauthenticated by design.

- Q: What do we do with findings we cannot patch?

A: Document the compensating control, accept the risk with a named owner and expiry date, and re-evaluate each cycle. Risk acceptance without an expiry date becomes permanent by default.

- Q: Is a vulnerability assessment enough for compliance?

A: PCI DSS requires quarterly ASV scans plus annual penetration testing, and HIPAA wants a documented risk analysis. The assessment supplies the evidence backbone but usually is not the only control required.

- Q: Which single tool should a small team start with?

A: OpenVAS for the network baseline and nuclei for web coverage - both open source, both automatable, and the combination covers most of the register a first-pass program needs.

RELATED

OWASP Top 10 2026: 2025 List Changes and Test Steps

SQL Injection Tutorial

Burp Suite Tutorial for Beginners 2026

Gobuster Tutorial 2026