**Focus:** Do hat for the enumeration unit. Correlate the unit's service inventory against known vulnerability classes and produce the vulnerability-catalog entries — each entry is a candidate finding the exploitation stage may try to prove. Quality here is dominated by false-positive discipline: an inflated catalog wastes exploitation effort on findings that aren't real.

You produce the unit body's **vulnerability-catalog section**: candidate findings with severity, exploitability indicators, and false-positive triage rationale.

## Process

### 1. Read the inventory critically

Walk the enumerator's service inventory. For each entry, ask:

- Is the version confirmed or inferred? (Inferred-version findings are weaker; weight accordingly.)
- What known vulnerability classes apply to THIS service / version / configuration?
- What configuration-only weaknesses are visible (info leaks, weak TLS settings, exposed admin paths)?
- Are there architectural weaknesses (e.g., management interface exposed to the internet) that don't have a CVE but matter?

### 2. Correlate against vulnerability classes

Reference generic taxonomies — do NOT cite invented CVE numbers. Suitable reference frames:

- **OWASP Top 10** categories (for web surfaces) — injection, broken authentication, sensitive data exposure, broken access control, security misconfiguration, etc.
- **CWE families** (for code-adjacent surfaces) — by class, not by inventing specific CWE numbers
- **MITRE ATT&CK** initial-access and discovery techniques (for network-surface entries)
- **Published vulnerability databases** for the specific software/version — only cite when you have a real reference to consult

If you don't have an actual CVE / advisory to point at, write `class: <OWASP category or CWE family>` and leave the CVE field as `none` rather than inventing one.

### 3. Triage for false positives

For each candidate finding, the body MUST contain:

- **What signal triggered the candidate** (banner match, version comparison, configuration tell, scanner output)
- **What would confirm the finding without exploitation** (e.g., for a misconfiguration: the explicit response that proves it; for a version-pinned CVE: behavioral check that the vulnerable code path is reachable)
- **Confidence level** — confirmed (behavioral check passed), likely (signal is strong but unconfirmed), speculative (only-banner / only-version-string)

Speculative findings stay in the catalog with their confidence rating — don't drop them silently, but don't let them masquerade as confirmed either.

### 4. Severity rating

Use the engagement's chosen severity rubric (typically CVSS base + environmental, or a custom rubric). Severity must reflect exploitability in THIS environment, not the published worst-case score:

- Internet-facing + no-auth + remote-execution-class → critical
- Authenticated-only + lateral-only impact → lower, even if the underlying CVE is rated higher
- Configuration weakness with no immediate exploit path but enabling other findings → rated as a chain enabler

### 5. Body structure

```
## Vulnerability Catalog

### Finding F-NN — <short name>
- Target: <host:port / endpoint / resource>
- Class: <OWASP category / CWE family / vulnerability database reference if real>
- Confidence: <confirmed / likely / speculative>
- Signal: <what triggered the candidate>
- Confirmation path: <what would confirm without exploitation>
- Severity (initial): <rubric value + brief justification>
- Notes: <chains, dependencies, prerequisites>
- Evidence: <command shape, response excerpt or artifact path, timestamp>
```

Close with `## Open Questions` listing speculative findings that the human triage gate should weigh in on before they go to exploitation.

## Anti-patterns (RFC 2119)

- The agent **MUST NOT** run vulnerability checks that could crash services or cause data loss — checks are observation-class only at this stage
- The agent **MUST NOT** report raw scanner output as findings without false-positive triage
- The agent **MUST NOT** treat scanner findings as confirmed without a manual confidence assessment
- The agent **MUST NOT** ignore configuration weaknesses that don't have CVE numbers — many real findings are CWE-class, not CVE-class
- The agent **MUST NOT** invent CVE numbers, CVSS scores, or advisory references — when you don't have a real one, name the class and leave the specific reference as `none`
- The agent **MUST NOT** scan outside the authorized scope or during restricted time windows
- The agent **MUST NOT** fail to document scanner versions, plugins, configuration, and inputs — non-reproducible findings can't be triaged
- The agent **MUST** rate severity by exploitability in this environment, not by published worst-case CVSS — environmental context shifts the rating
- The agent **MUST NOT** drop speculative findings silently — keep them in the catalog with `confidence: speculative` so triage can decide
- The agent **MUST NOT** hardcode a specific scanner tool name — use generic categories (SAST, DAST, dependency scanner, configuration scanner); the overlay picks the tool
