Vulnerability Report Summarizer

Overview

Parses raw vulnerability scan output from common scanners, deduplicates and normalizes findings, scores them using CVSS methodology, maps relevant findings to MITRE ATT&CK techniques, and produces audience-appropriate reports. Executive reports focus on risk posture and business impact. Technical reports include full finding details, affected assets, and step-by-step remediation guidance.

Workflow

<Definition - CVSS Scoring> Common Vulnerability Scoring System used to rate findings:

• Base Score: Intrinsic qualities of the vulnerability (attack vector, complexity, privileges required, user interaction, scope, impact on confidentiality/integrity/availability). Range 0.0-10.0.
• Temporal Score: Characteristics that change over time (exploit code maturity, remediation level, report confidence). Modifies the base score downward.
• Environmental Score: Characteristics relevant to the specific deployment (modified base metrics, security requirements for CIA). Organization-specific adjustment.

When scanners provide only a base score, use it as-is. Do not fabricate temporal or environmental modifiers. </Definition - CVSS Scoring>

<Definition - Severity Tiers> Findings are classified into five tiers based on CVSS base score:

• Critical (9.0-10.0): Immediate exploitation risk. Likely requires emergency patching or isolation. Typical SLA: 24-72 hours.
• High (7.0-8.9): Significant risk if exploited. Prioritize in next patch cycle. Typical SLA: 7-14 days.
• Medium (4.0-6.9): Moderate risk, often requiring specific conditions to exploit. Typical SLA: 30 days.
• Low (0.1-3.9): Minor risk with limited impact. Address in regular maintenance. Typical SLA: 90 days.
• Informational (0.0): No direct security risk. Configuration notes, best-practice suggestions, or scanner metadata. No SLA. </Definition - Severity Tiers>

<Definition - MITRE ATT&CK Mapping> Where a finding corresponds to a known adversary technique, map it to the relevant MITRE ATT&CK tactic and technique ID (e.g., T1190 - Exploit Public-Facing Application). Only map when the relationship is clear and documented. Do not force mappings for findings that lack a direct ATT&CK correlation. </Definition - MITRE ATT&CK Mapping>

<Definition - Scanner Format Detection> Supported input formats and their identifying markers:

• Nessus (.nessus XML, .csv export): Look for "Plugin ID", "Risk", "Host", "Protocol" columns or NessusClientData_v2 XML root.
• Qualys (.xml, .csv): Look for "QID", "Severity", "CVSS Base" columns or QUALYS XML namespace.
• OWASP ZAP (.xml, .json, .html): Look for "OWASPZAPReport" root element or "site" > "alerts" JSON structure.
• Generic CSV/JSON: Fall back to column-header heuristics. Require at minimum: finding name/title, severity or CVSS score, and affected host/URL. </Definition - Scanner Format Detection>

<Workflow - VulnReport description="End-to-end vulnerability scan parsing, analysis, and report generation." tools=[file_read, file_read_pdf, file_write, run_python, open_in_session_tab] triggers=["summarize this vulnerability scan", "create security report", "prioritize these vulnerabilities", "executive summary of scan results", "remediation plan from scan"]

1. [Agent] Read the scan file using file_read, file_read_pdf, or run_python depending on file type. Determine the scanner format using the Scanner Format Detection definition. If the file is unrecognized or unparseable, stop and inform the user with specific guidance on supported formats. If fails: If the file cannot be accessed at all, report the path and access error to the user and stop.

2. [Agent] Parse the scan output into a normalized internal structure. Extract for each finding: title/name, CVE (if present), CVSS score (if present), severity tier, affected host(s) or URL(s), port/protocol (if applicable), scanner plugin ID, and description. Use run_python for structured parsing of XML, CSV, or JSON. If fails: If parsing produces no structured findings, report the parsing failure and ask the user to re-export the scan in a supported structured format.

3. [Agent] Deduplicate findings per Rule 8. Group identical vulnerabilities (same CVE or same plugin ID with same signature) across hosts. Produce a deduplicated list with per-finding host counts. Separate informational findings into their own bucket per Rule 12. If fails: If deduplication cannot complete, report the error and proceed with the raw finding list, noting that duplicates may remain.

4. [Think] Score and classify each finding into severity tiers. If the scanner provided CVSS scores, use them directly. If only text severity labels exist, map to CVSS ranges per the Gotchas note on Nessus CSV. Flag any findings where severity appears inconsistent with the description (potential false positive candidates per Rule 7).

5. [Agent] For findings at High severity or above, attempt MITRE ATT&CK mapping. Match CVE descriptions and vulnerability types to known techniques. Only assign mappings with clear documented correlation per Rule 10. Record unmapped findings without forcing a match. If fails: If ATT&CK mapping cannot be resolved, record the affected findings as having no mapping and continue.

6. [Think] Prioritize findings for remediation. Weighting factors: severity tier (primary), number of affected hosts (secondary), whether a public exploit exists (tertiary, if noted in scanner output), and ATT&CK mapping presence (indicates known adversary usage). Produce a ranked remediation list.

7. [Decide] Branch based on report_audience:

   • If "executive": Generate using the Executive Summary template. Exclude internal hostnames per Rule 3. Aggregate by category.
   • If "technical": Generate using the Technical Detail template. Include full asset-level detail.
   • If "both": Generate both reports as separate sections in a single document, with the executive summary first.

8. [Decide] If include_remediation is true, append the prioritized remediation plan. For each finding in priority order, include: what to fix, why it matters (risk context per Rule 6), and general remediation guidance. Per Rule 11, do not assume environment architecture.

9. [Agent] Write the completed report to the session workspace as a Markdown file. File naming: vulnerability-report-{audience}-{date}.md. Open in the session tab using open_in_session_tab. If fails: If the report cannot be written or opened, report the error, retry once, and present the report inline if the retry fails.

10. [Ask user] Present a brief completion summary: total findings processed, breakdown by severity tier, number of false positive candidates flagged, and confirmation of where the report was saved. Ask if they want adjustments to scope, audience, or detail level. If fails: If the user does not respond with a clear decision, restate the summary and ask whether any adjustments are needed.

</Workflow - VulnReport>

<Template - Executive Summary>

markdownCopy code
# Security Assessment Summary

**Report Date:** {{date}}
**Scan Source:** {{scanner_name}}
**Scope:** {{target_count}} targets assessed
**Overall Risk Posture:** {{risk_rating}}

## Key Findings

| Severity | Count | Change from Prior (if available) |
|----------|-------|----------------------------------|
| Critical | {{critical_count}} | TBD |
| High | {{high_count}} | TBD |
| Medium | {{medium_count}} | TBD |
| Low | {{low_count}} | TBD |

**Informational items excluded from risk totals:** {{info_count}}

## Top Risks

{{For each Critical and High finding, grouped by category:}}

### {{category_name}}
- **Business Impact:** {{what an attacker could achieve}}
- **Affected Area:** {{generalized description, no hostnames}}
- **Instances:** {{count}}
- **Recommended Action:** {{one-line remediation summary}}

## Remediation Priority

1. {{highest_priority_action}}
2. {{second_priority_action}}
3. {{third_priority_action}}

## False Positive Candidates

{{count}} findings flagged for validation before remediation resources are allocated.

---
*This report contains no internal infrastructure identifiers. For asset-level detail, refer to the technical report.*

</Template - Executive Summary>

<Template - Technical Detail>

markdownCopy code
# Vulnerability Assessment - Technical Report

**Report Date:** {{date}}
**Scanner:** {{scanner_name}} {{scanner_version}}
**Scan Duration:** {{duration, if available}}
**Targets:** {{target_list_or_count}}

## Summary Statistics

- Total unique findings (deduplicated): {{total}}
- Critical: {{critical_count}}
- High: {{high_count}}
- Medium: {{medium_count}}
- Low: {{low_count}}
- Informational: {{info_count}}
- False positive candidates: {{fp_count}}

## Findings by Severity

### Critical

{{For each critical finding:}}

#### {{finding_title}}
- **CVE:** {{cve_id or "No CVE assigned"}}
- **CVSS Base Score:** {{score}}
- **MITRE ATT&CK:** {{technique_id - technique_name, or "No mapping"}}
- **Affected Hosts:** {{host_list with ports}}
- **Description:** {{finding_description}}
- **Risk Context:** {{what exploitation enables}}
- **Evidence:** {{scanner output excerpt, if available}}
- **Remediation:** {{step-by-step fix}}
- **False Positive Flag:** {{yes/no with reasoning if yes}}

### High

{{Same structure as Critical}}

### Medium

{{Same structure, condensed descriptions}}

### Low

{{Tabular format: Title | CVE | Hosts | Score}}

### Informational

{{Tabular format: Title | Hosts | Notes}}

## Remediation Plan (Priority Order)

| Priority | Finding | Severity | Hosts Affected | Recommended Action | SLA |
|----------|---------|----------|----------------|-------------------|-----|
{{ranked rows}}

## Methodology Notes

- Deduplication method: {{method used}}
- Scoring source: {{scanner-provided vs. estimated}}
- Limitations: {{any data quality issues encountered}}

</Template - Technical Detail>

Data Isolation Rules

1. All scan data exists only in session-scoped variables and workspace files. Nothing persists after the session ends.
2. Do not call save_to_memory, kg_add, or any persistence tool with scan contents, finding details, or infrastructure identifiers.
3. Do not write scan data to paths outside the session workspace (artifacts/ directory).
4. If a tool call fails and returns scan data in an error message, do not echo that data back to the user in raw form. Summarize the error without the payload.
5. Do not use web_search, url_fetch, or any network tool to look up internal hostnames or IP addresses found in the scan. CVE lookups against public databases are permitted.
6. If the user requests sharing the report via email or messaging, confirm the audience classification matches the recipient before proceeding. Block sending technical reports (containing hostnames) to distribution lists without explicit confirmation.