VAPT Series Part 3: Vulnerability Assessment

A Quick Recap

So far in this series, we've covered:

1. Introduction to VAPT and setting up a personal lab
2. Lab environment setup
3. Reconnaissance and information gathering

With a solid picture of the target's attack surface in hand, it's time to move to the next phase: Vulnerability Assessment (VA) — systematically identifying, cataloguing, and prioritizing weaknesses across that surface.

A note before we start:_ As always, everything here assumes a lab environment or a system you own or are explicitly authorized to assess. Scanning or assessing systems without permission is illegal in most jurisdictions. This post is about_ methodology and concepts_, not about causing harm._

Vulnerability Assessment vs. Penetration Testing

These two terms get used interchangeably a lot, but they're distinct phases with different goals:

Vulnerability AssessmentPenetration TestingGoalIdentify and catalogue weaknessesProve weaknesses are exploitable, show real impactApproachBroad, mostly automated scanningNarrow, manual, human-drivenOutputList of findings with severity ratingsChained attack paths, proof-of-concept, business impactRisk to targetLowHigher (active exploitation)

Think of VA as "what could be wrong here" and pen testing as "let's prove it's actually wrong, and show what happens if it is." A mature assessment always does VA first — it's the map that tells you where to focus the more time-intensive, higher-risk pen testing effort.

What Actually Happens in This Phase

1. Asset Prioritization

Not every asset from the recon phase deserves equal attention. Internet-facing systems, systems handling sensitive data, and systems central to business operations generally get prioritized first.

2. Automated Scanning

This is where most people's mental image of "vulnerability assessment" lives — running scanners against in-scope assets to identify known weaknesses: outdated software versions, missing patches, misconfigurations, weak default settings, and exposed services.

Modern scanners typically work off templated detection rules — structured checks (often written in YAML or similar formats) that describe a specific weakness and how to test for its presence. This makes scanning engines extensible: new checks can be added as new vulnerabilities are disclosed, without changing the underlying scanning logic. Categories of checks commonly include:

• Outdated or end-of-life software versions
• Missing security patches (CVE-based detection)
• Default or weak credentials on exposed services
• Misconfigurations (open directories, verbose error messages, insecure headers)
• Exposed configuration files or backups
• Weak TLS/SSL configurations

3. Manual Verification

Automated tools are fast but noisy. False positives are common — a scanner might flag a version string as vulnerable even if the vendor backported a fix. This phase involves manually checking a sample of findings to confirm they're real before they go into a report. Skipping this step is one of the fastest ways to lose credibility with a client.

4. Severity Rating

Findings get ranked — usually using a standard framework like CVSS (Common Vulnerability Scoring System) — based on factors like:

• Exploitability (how easy is this to trigger?)
• Impact (what happens if it's exploited — data loss, system compromise, service disruption?)
• Exposure (is this internet-facing or internal-only?)

This turns a long list of raw findings into something a business can actually act on: "fix these five things this week, these ten within the month."

5. Documentation

Every finding should be recorded with:

• A clear description of the issue
• The affected asset
• Evidence (screenshots, scan output, version info)
• Severity rating and justification
• Remediation guidance

This documentation becomes the backbone of the vulnerability assessment report — often the actual deliverable a client pays for.

Common Categories of Vulnerabilities You'll Encounter

CategoryExamplesConfiguration issuesDefault credentials, unnecessary open ports, verbose errorsPatch managementOutdated software with known, publicly disclosed weaknessesAccess controlOverly permissive file/service permissionsEncryption weaknessesWeak or outdated TLS versions, self-signed certs in productionApplication-layer issuesInput validation gaps, outdated frameworks/libraries

A Simple Vulnerability Assessment Workflow

1. Confirm scope — Reconfirm what's authorized before scanning anything.
2. Run automated scans — Cover breadth quickly across in-scope assets.
3. Triage results — Sort by likely severity and remove obvious noise.
4. Manually verify a sample — Confirm scanner accuracy before trusting the full list.
5. Assign severity — Apply a consistent scoring framework (e.g., CVSS).
6. Document everything — Write findings clearly enough that someone non-technical could understand the risk.
7. Hand off / prioritize — Decide what feeds into the next phase (penetration testing) versus what goes straight to a remediation list.

Why This Phase Is Often Underrated

It's easy to see vulnerability assessment as "the boring scanning part" compared to the more dramatic exploitation work in penetration testing. But in most real-world engagements, VA is where the majority of actionable findings come from. Exploitation makes for a great story in a report, but a client fixing fifteen misconfigurations found during VA often reduces more real-world risk than one clever exploit chain.

Good testers respect this phase — it's not a formality before "the real work," it is the real work, just with a different shape.

What's Next

With a prioritized list of findings in hand, the next post moves into Exploitation — taking the highest-severity vulnerabilities identified here and demonstrating, in a lab environment, how they can actually be leveraged to gain access or impact. This is where VA findings get put to the test to confirm real-world risk rather than theoretical risk.

If you're following the series, thanks for sticking with it — and as always, feel free to share topic requests for future posts.