Imported from ubercylon8/f0_pentest (skills/network-ops/vuln-scan/SKILL.md). Install upstream with npx skills add ubercylon8/f0_pentest --skill vuln-scan. Copyright stays with the author (Apache-2.0).

Vuln Scan

Runtime: portable (agentskills.io). Prefer the f0_pentest MCP tool servers when wired — f0-recon (nmap/httpx/subfinder), f0-web (nuclei/surface), f0-ad-enum (netexec reads), f0-entra (Entra ID reads), f0-report (findings store, CVSS, reporting); fall back to the documented CLI commands when MCP is unavailable. <active-engagement> is the engagement folder recorded in ~/.f0pentest/engagements/active (or ~/.claude/engagements/active). Active scope: <active-engagement>/scope.yaml. Write outputs to the engagement's numbered subfolders. Discipline for small local models: one tool at a time, never fabricate IDs or output, relay posture findings instead of retrying.

MCP Tools

When the f0_pentest MCP servers are wired, prefer these tools for this skill's work (fall back to the CLI commands below when unwired):

• list_scans (f0-vulnmgmt)
• get_scan (f0-vulnmgmt)
• start_scan (f0-vulnmgmt)
• list_vulns (f0-vulnmgmt)
• get_host_vulns (f0-vulnmgmt)

NETWORK-OPS phase. Run and triage a vulnerability scan against in-scope infrastructure using a Greenbone/OpenVAS appliance over GMP: start a scan the operator already configured, poll it to completion, and triage the CVE / patch-level findings by severity. Every tool talks to the appliance over the network — there is no local binary and no GMP command line involved.

When to Use

• When an in-scope host or subnet needs a vulnerability scan and a Greenbone/OpenVAS scan for it already exists on the appliance.
• When asked to "run the vuln scan", "check on that OpenVAS scan", "what did the Greenbone scan find", or to triage vulnerability findings already on the appliance.

Quick Reference

Procedure

1. Scope first. Confirm the target host(s)/subnet the scan covers are in scope before starting anything. start_scan also refuses on its own unless every host the scan targets is in scope — but check first rather than relying on it to catch a mistake.
2. Confirm a credential exists. A cred_ref for this Greenbone/OpenVAS appliance must already be stored in 06-credentials/. If none exists, stop and ask the operator to add one rather than guessing a cred_ref.
3. Find the scan. Call list_scans with the cred_ref to see the scans already configured on the appliance and pick the scan_id that matches the target.
4. Start it. Call start_scan with the cred_ref and scan_id. This starts a scan the operator already set up on the appliance — it does not create a scan, target, or scan config, and there is no tool that does. If it refuses on scope, stop and tell the operator which host is out of scope rather than retrying.
5. Poll to completion. Call get_scan with the same scan_id periodically until its status is Done. A scan can take a long time; a status of Running is not a failure.
6. Triage by severity. Call list_vulns with the cred_ref, the scan_id, and severity_min=high to pull the vulnerabilities worth acting on first. Widen to medium or low only if the operator wants a fuller picture. Leave report_id empty: that reads the scan's latest finished run, which is what step 5 waited for.
7. Read an earlier run only if asked. To compare against a previous scan, call list_reports with the cred_ref and scan_id, take the report_id of the run the operator wants, and pass it to list_vulns. Do not guess a report_id — it must come from list_reports.
8. Drill into a host. Call get_host_vulns with the cred_ref, the scan_id, and the host to see everything a scan found there, including informational results — the only place those are reachable.
9. Record confirmed issues. Write up each confirmed finding (host, vulnerability, severity) for the report.

Pitfalls

• This skill cannot create scans, targets, or scan configs. Those are set up by the operator directly on the Greenbone/OpenVAS appliance beforehand. If no scan exists for the target yet, stop and say so — do not improvise a workaround.
• Never use gvm-cli, raw GMP commands, or the Greenbone web UI. Every step here goes through the six MCP tools above.
• Right after start_scan, there are no results yet. list_vulns reads the latest finished run, so until the new run completes it reports the previous run's results, or says the scan has no finished report. Poll get_scan first; do not treat that message as a failure.
• severity_min has no info option. Informational results are reachable only through get_host_vulns; list_vulns is for triage, not a full listing.
• start_scan checks scope unconditionally — every host the scan targets must be in the engagement's scope, not just under a strict-scope operator setting.
• Credentials are resolved server-side. Never ask for or handle a raw appliance password — only the cred_ref name reaches the model.

Verification

• Every finding cites an in-scope host, a vulnerability, and a severity.
• start_scan was only called after the target host(s) were confirmed in scope.
• No raw credential value appears anywhere in the writeup — only the cred_ref.