---
task: analyzeVulnerability()
responsavel: "@omar-santos"
responsavel_type: Agent
atomic_layer: Task
elicit: true

Entrada:
  - campo: vulnerability_data
    tipo: string
    origem: User Input
    obrigatorio: true
  - campo: affected_systems
    tipo: string
    origem: User Input
    obrigatorio: true

Saida:
  - campo: vulnerability_analysis
    tipo: string
    destino: Console
    persistido: false

Checklist:
  - "[ ] CVSS 3.1 scoring applied to each finding"
  - "[ ] Risk-based prioritization completed with business context"
  - "[ ] Remediation guidance and timeline provided"
---

# Task: Vulnerability Analysis & Prioritization

**Task ID:** CYBER-007
**Version:** 1.0.0
**Command:** `*analyze-vulnerability`
**Agent:** Omar Santos (omar-santos) or Chris Sanders (chris-sanders)
**Purpose:** Analyze, classify, and prioritize vulnerabilities with actionable remediation guidance.

---

## Inputs

| Input | Source | Required |
|-------|--------|----------|
| `vulnerability_data` | Scan results, CVE, or description | YES |
| `affected_systems` | User or scan output | YES |
| `business_context` | System criticality, data classification | PREFERRED |
| `existing_controls` | Compensating controls in place | NO |
| `compliance_requirements` | Regulatory framework | NO |
| `scan_tool_output` | Raw scanner output | NO |

## Preconditions

1. Vulnerability data is available (scan results, CVE IDs, or descriptions)
2. Affected systems are identified
3. Authorization to assess the target environment is confirmed

## Execution Phases

### Phase 1: Identification & Enrichment

1. Parse vulnerability input — CVE IDs, scanner output, or manual descriptions
2. Enrich each vulnerability with CVE details, CWE classification, and vendor advisories
3. Determine affected software versions and confirm applicability
4. Check exploit availability — public exploits (Exploit-DB, GitHub), Metasploit modules
5. Assess weaponization status — is this actively exploited in the wild? (CISA KEV catalog)
6. Deduplicate findings — merge scanner overlap, normalize naming

### Phase 2: Classification (CVSS Scoring)

1. Apply CVSS 3.1 base scoring for each vulnerability:
   - **Attack Vector** — Network, Adjacent, Local, Physical
   - **Attack Complexity** — Low, High
   - **Privileges Required** — None, Low, High
   - **User Interaction** — None, Required
   - **Scope** — Unchanged, Changed
   - **Impact** — Confidentiality, Integrity, Availability (None/Low/High)
2. Apply temporal metrics where data exists (exploit maturity, remediation level)
3. Apply environmental metrics based on business context
4. Map to severity categories: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9)

### Phase 3: Prioritization

1. Combine CVSS score with business context:
   - System criticality (crown jewels vs low-value assets)
   - Data classification (PII, financial, public)
   - Exposure (internet-facing vs internal-only)
   - Exploit availability and active exploitation
2. Apply risk-based prioritization matrix:
   - **P1 — Patch Immediately:** CVSS >= 9.0 OR actively exploited + internet-facing
   - **P2 — Patch This Week:** CVSS >= 7.0 + exploit available
   - **P3 — Patch This Month:** CVSS >= 4.0, no active exploitation
   - **P4 — Schedule Remediation:** CVSS < 4.0, compensating controls exist
3. Group related vulnerabilities for batch remediation
4. Identify dependencies — patches that require downtime or testing

### Phase 4: Remediation Planning

1. For each vulnerability, provide specific remediation:
   - **Patch** — Vendor patch version, download link, known issues
   - **Workaround** — Configuration changes, compensating controls
   - **Mitigation** — Network segmentation, WAF rules, monitoring
2. Assess remediation risk — will the fix break functionality?
3. Define testing requirements before production deployment
4. Create remediation timeline with responsible parties
5. Recommend validation method — re-scan, manual verification, regression testing
6. Document accepted risks for vulnerabilities not immediately remediable

## Output Format

```yaml
vulnerability_analysis:
  analyst: "omar-santos | chris-sanders"
  total_findings: 0
  severity_distribution:
    critical: 0
    high: 0
    medium: 0
    low: 0
  findings:
    - id: "VULN-001"
      cve: "CVE-YYYY-NNNNN"
      cwe: "CWE-NNN"
      title: "{vulnerability name}"
      cvss_base: 0.0
      cvss_temporal: 0.0
      severity: "CRITICAL | HIGH | MEDIUM | LOW"
      priority: "P1 | P2 | P3 | P4"
      affected_systems: ["{systems}"]
      exploit_available: true
      actively_exploited: false
      remediation:
        patch: "{patch details}"
        workaround: "{interim fix}"
        mitigation: "{compensating control}"
      validation: "{how to verify fix}"
  remediation_timeline:
    immediate: ["{P1 items}"]
    this_week: ["{P2 items}"]
    this_month: ["{P3 items}"]
    scheduled: ["{P4 items}"]
  accepted_risks: ["{documented risk acceptances}"]
```

## Veto Conditions

- **NEVER** dismiss vulnerabilities without analysis
- **NEVER** recommend ignoring actively exploited vulnerabilities
- **NEVER** assign severity without CVSS justification
- **NEVER** provide remediation without testing recommendations
- **NEVER** skip business context in prioritization

## Completion Criteria

- [ ] All vulnerabilities enriched with CVE/CWE data
- [ ] CVSS 3.1 scoring applied to each finding
- [ ] Exploit availability and active exploitation status checked
- [ ] Risk-based prioritization completed with business context
- [ ] Remediation guidance provided for each vulnerability
- [ ] Remediation timeline created with priorities
- [ ] Validation methods defined for each fix
