Learn Vulnerability Assessment

Short lessons that use OpenVAPT itself as the textbook. Every exercise runs on the built-in simulated lab, so you can follow along on any computer without touching a real server.

1. Assessment Versus Penetration Testing
2. Anatomy of a Check
3. Reading a CVSS Vector
4. Lab: Scan, Fix, Verify
5. Why Scope Is Enforced in Code
6. Write Your Own Check

Assessment Versus Penetration Testing

VAPT combines two activities. A vulnerability assessment looks for known weaknesses and rates them, without exploiting anything. A penetration test goes further: a skilled, authorised tester tries to exploit weaknesses to show real impact. OpenVAPT does only the first part, automatically, on one machine. NIST SP 800-115 calls the missing part the attack phase.

Anatomy of a Check

Open any check page. Each check has the same parts, defined in internal/check/check.go:

• Metadata: id, title, domain, severity and CVSS vector.
• Rationale: why the weakness matters, in plain words.
• Detection: exactly what is read and what counts as a failure.
• Fix and Verify: what to change, and how to confirm it worked.
• References and Standards: public sources and CWE, OWASP and NIST mappings.
• Run: the Go function that does the work through the read-only System.

Reading a CVSS Vector

Take CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, used by the exposed secrets check. AV:N means attackable over the network. AC:L means low complexity. PR:N and UI:N mean no account and no user action are needed. S:U means the impact stays in the same component. C:H, I:H and A:H mean high impact on confidentiality, integrity and availability. Together these score in the Critical range.

Lab: Scan, Fix, Verify

No time to build it? Open the real reports produced from the simulated lab: vulnerable server report and hardened server report (also as JSON, SARIF and Markdown).

Build the tool (see Download), then run:

openvapt demo --lab vulnerable --out lab-before
openvapt demo --lab hardened   --out lab-after
openvapt diff lab-before/report.json lab-after/report.json

Open lab-before/report.html in a browser. For three findings, read the fix, then find the matching line in internal/lab/lab.go that differs between the vulnerable and hardened servers. The diff shows every finding moving to Fixed.

Questions to discuss: Which findings would matter most on an internet-facing shop? Which CVSS ratings would you change for a server on a private network, and why?

Why Scope Is Enforced in Code

A policy that says "only scan your own machine" can be ignored. A dialer that refuses non-loopback addresses cannot. Read CheckAddr in the walkthrough and its unit test, then consider why host names such as localhost are deliberately rejected.

Write Your Own Check

1. Copy a small check such as internal/checks/host/logging_time.go.
2. Give it a new id, fill in every documentation field and cite at least one public source. Registration refuses checks without them.
3. Read what you need only through the sys.System interface.
4. Make the vulnerable lab trigger it and the hardened lab pass it in internal/lab/lab.go.
5. Run go test ./.... The engine tests fail until both labs behave correctly.
6. Open a pull request, as described on Contribute.