Vulnerability Assessment: Process, Tools, Prioritisation and a Free Lab

A vulnerability assessment is a systematic process of finding, rating and reporting the security weaknesses in systems, networks and applications, such as missing patches, misconfigurations, default passwords and vulnerable software libraries. It relies mainly on automated scanners followed by manual checking, and it stops at identifying and ranking weaknesses; it does not exploit them. The output is a prioritised list of findings with a fix for each.

The hard part is not running a scanner. It is deciding which of hundreds of findings to fix first. This guide covers the full process, with extra depth on prioritisation using CVSS 4.0, EPSS and the CISA KEV catalogue, including the April 2026 change at the National Vulnerability Database that affects every scanning programme.

What a vulnerability assessment finds

• Missing security patches in operating systems, servers, databases and network devices.
• Vulnerable components: an outdated library inside an application or container image (for example, an old Log4j version).
• Misconfigurations: open admin panels, directory listing, unnecessary services, weak TLS settings, public cloud storage buckets.
• Weak authentication: default or blank passwords, missing multi-factor authentication on remote access.
• Web application flaws that can be detected safely, such as reflected cross-site scripting, missing security headers and exposed debug endpoints.

Most of these map to a CVE (Common Vulnerabilities and Exposures) identifier, such as CVE-2021-44228 for Log4Shell. Configuration problems usually map to benchmarks such as the CIS Benchmarks instead.

Types of vulnerability assessment

The vulnerability assessment process, step by step

Authenticated vs unauthenticated scans

An unauthenticated scan sees what an outside attacker sees: open ports and the version banners services reveal. An authenticated (credentialed) scan logs in to each host and reads the installed package list, so it finds far more missing patches with fewer false positives. A mature programme runs both: unauthenticated from outside for the attacker’s view, authenticated inside for completeness.

Why validation matters

Scanners often judge by version number. Linux distributions such as Ubuntu and Red Hat back-port security fixes without changing the upstream version, so a server reporting “OpenSSH 8.9” may already be patched. Reporting such findings unverified wastes the fixing team’s time and damages the credibility of the whole report.

How to prioritise vulnerabilities: CVSS, EPSS, KEV and SSVC

A typical scan of a mid-sized network returns thousands of findings, many rated High or Critical. Fixing them in CVSS order is the most common mistake in vulnerability management, because CVSS measures how bad a vulnerability would be if exploited, not how likely it is to be exploited. Use four signals together.

CVSS 4.0

The Common Vulnerability Scoring System version 4.0 became generally available on 1 November 2023, replacing 3.1. It has four metric groups: Base (the intrinsic severity), Threat (replacing 3.1’s Temporal group), Environmental (your specific setup) and Supplemental (extra context such as automatability that does not change the score). Scores are labelled by which groups were used: CVSS-B (base only), CVSS-BT, CVSS-BE and CVSS-BTE. The severity bands did not change:

Almost every published score is CVSS-B, a base score with no information about your environment. That is why the other signals are needed.

EPSS (Exploit Prediction Scoring System)

EPSS is a free, daily-updated machine-learning estimate of the probability that a CVE will be exploited in the wild in the next 30 days. Version 4 was released in March 2025. Its value is in showing how few vulnerabilities actually attract attackers. In the EPSS data for 27 September 2026, covering 380,066 CVEs:

• 61% had an EPSS below 0.01 (under 1% chance of exploitation in 30 days)
• only 4.5% had an EPSS of 0.1 or more
• only 1.1% had an EPSS of 0.5 or more

CISA Known Exploited Vulnerabilities (KEV)

The KEV catalogue lists vulnerabilities with reliable evidence of active exploitation. On 25 September 2026 it contained 1,726 entries, compared with close to 400,000 CVE records in the NVD, so fewer than 1 in 200 known vulnerabilities is on it. US federal agencies must fix KEV entries by the listed due dates under Binding Operational Directive 22-01; everyone else can use it as a free “fix these first” list. It is available as a JSON or CSV feed that most scanners can import.

SSVC

Stakeholder-Specific Vulnerability Categorization is a decision tree that turns a few questions (Is it exploited? Is it automatable? What is the technical impact? How important is the affected system?) into one of four actions: Track, Track*, Attend or Act. It is useful when a team needs a documented, repeatable reason for each decision.

Worked example: ranking four findings

An illustrative scan of a college’s network returns these four findings. Their scores are realistic but the findings are invented for teaching.

Ranked by CVSS alone, the order is A, B, C, D, and the admissions website (C) waits behind an internal workstation. Ranked by real risk:

1. A, fix within 24 to 72 hours. Critical, exploited in the wild, and reachable from the internet.
2. C, fix this week. Only “Medium” on CVSS, but attackers are actively using it and the site is public. This is the finding CVSS-only programmes miss.
3. B, next patch cycle (within 30 days). Severe in theory, but very unlikely to be exploited and not exposed. Record the reasoning in the report.
4. D, backlog / configuration hardening (within 90 days). Low risk, but cheap to fix with the next configuration change.

A simple rule that works for small teams: anything in KEV first, then EPSS above about 0.1 on exposed or critical systems, then CVSS within each group. Adjust the thresholds to how much fixing capacity you have.

What changed in 2025 and 2026

• NVD enrichment cut back (15 April 2026). NIST, which runs the National Vulnerability Database, now prioritises adding scores and affected-product data only for CVEs in the KEV catalogue, in US federal software, and in software designated critical under Executive Order 14028. Other CVEs are marked “Lowest Priority”, and NIST no longer re-scores CVEs that their publisher has already scored. Unenriched CVEs published before 1 March 2026 were moved to “Not Scheduled”. If your scanner or dashboard relies only on NVD scores, expect many new CVEs with no NVD score; use the publisher’s (CNA’s) score, vendor advisories, KEV and EPSS instead. Our NIST explainer covers the background.
• CVE programme funding stabilised. The MITRE-run CVE programme came within hours of a funding lapse in April 2025. In January 2026 the CVE Board was told there would be no funding cliff in March 2026, with the programme reported to be moving to a protected line in CISA’s budget.
• EPSS version 4 arrived in March 2025, and CVSS 4.0 scores are now common in vendor advisories alongside 3.1.
• India: CERT-In audit guidelines (25 July 2025). CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines call for covered organisations to audit their ICT systems at least once a year, more often for critical assets, and before major changes go live, using CERT-In empanelled auditors where required.

Vulnerability assessment vs penetration testing (and VAPT)

In India the two are usually bought together as VAPT (vulnerability assessment and penetration testing), and regulators such as RBI, SEBI and CERT-In ask for VAPT reports. They are complementary: a VA tells you what is broken across the whole estate, and a penetration test tells you how bad it would be if someone used it.

Free and commercial tools

Hands-on: run your first vulnerability assessment in a home lab

Only scan systems you own or have written permission to test. In India, unauthorised access or scanning can attract liability under Sections 43 and 66 of the Information Technology Act, 2000. A home lab keeps you on the right side of the law.

1. Build the lab. Install VirtualBox. Create two virtual machines on a host-only network: Kali Linux (your scanner) and Metasploitable 2, a deliberately vulnerable Linux machine made for practice. Never connect Metasploitable to the internet.
2. Discover services. From Kali, find the target’s address, then run:
   nmap -sV -sC -p- 192.168.56.101
   (replace the IP with your target’s). -sV detects versions, -sC runs safe default scripts and -p- checks all 65,535 TCP ports.
3. Scan for vulnerabilities. Run a Greenbone (OpenVAS) or Nessus Essentials scan against the same IP, and a web scan with nikto -h http://192.168.56.101.
4. Validate. You should find, among many others, the vsftpd 2.3.4 backdoor (CVE-2011-2523), the Samba “usermap script” flaw (CVE-2007-2447) and the distcc daemon flaw (CVE-2004-2687). Look each up and confirm that the version Nmap reported matches the vulnerable range.
5. Prioritise. Look up each CVE’s EPSS score at the FIRST website and check whether it appears in the CISA KEV catalogue, then rank them as in the worked example.
6. Write the report using the structure below. This single exercise, written up well, makes a strong portfolio item for security internships.

How to write a vulnerability assessment report

Write each fix as an action a system owner can take without further research: “Upgrade Apache HTTP Server on web01 from 2.4.49 to the current 2.4.x release” is useful; “Update software” is not.

A note on the other meaning

Outside IT, “vulnerability assessment” also means analysing how exposed people, buildings or infrastructure are to hazards such as floods, earthquakes or climate change, for example in disaster management plans or the seismic assessment of existing buildings. The idea is the same: identify weaknesses, rate them, and prioritise action. This page covers the cybersecurity meaning.

Frequently asked questions

What is vulnerability assessment in cyber security?

It is the process of identifying, rating and reporting security weaknesses in an organisation’s systems, networks and applications, mainly with automated scanners plus manual validation, so that they can be fixed in order of risk before attackers use them.

What are the steps of a vulnerability assessment?

Scope and permission, asset discovery, scanning, validation of findings, risk-based prioritisation, and finally reporting, remediation and a rescan to confirm each fix.

How often should a vulnerability assessment be done?

Internet-facing systems should be scanned at least weekly and internal systems at least monthly, plus after any major change. In India, CERT-In’s 2025 guidelines expect a full cyber security audit at least once a year, and sector regulators may require more.

Is vulnerability assessment the same as penetration testing?

No. A vulnerability assessment finds and ranks weaknesses broadly without exploiting them. A penetration test manually exploits selected weaknesses to show real impact. Together they are called VAPT.

Which is the best free vulnerability assessment tool?

For networks, Greenbone Community Edition (OpenVAS) is the most complete free scanner, and Nessus Essentials is free for a small number of IPs. For web applications use ZAP, and for containers and code dependencies use Trivy. Pair any of them with Nmap for discovery.

Related on EngineeringHulk: how to become a cyber security engineer · intrusion prevention systems · NIST standards and CSF 2.0 · computer networks notes · IP subnet calculator