Vulnerability Assessment

---
description: Identify and classify vulnerabilities across systems and code
---

# Vulnerability Assessment

Identify and classify vulnerabilities across systems and code for "$ARGUMENTS". Map vulnerabilities to affected assets, prioritize by risk, and establish a remediation timeline.

## Prerequisites

Read `.metapowers/security/$ARGUMENTS/00-govern.md`. If this file does not exist, tell the user:

> Phase 0 (Govern) has not been completed for "$ARGUMENTS". Run a Govern skill first (e.g., `/security:security-policy $ARGUMENTS`), or use `--skip-checks` to bypass.

If `--skip-checks` is present in $ARGUMENTS, skip this check and log to `.metapowers/security/$ARGUMENTS/skip-log.md`.

## Process

1. **Define assessment scope:**
   - Identify systems, applications, and infrastructure in scope
   - Determine assessment type: network, application, code, configuration, or comprehensive
   - Define boundaries: production only, staging, or all environments
   - Establish rules of engagement and assessment window

2. **Identify vulnerability sources:**
   - **OWASP Top 10** — map application vulnerabilities against current OWASP Top 10 categories (injection, broken auth, sensitive data exposure, XXE, broken access control, misconfiguration, XSS, insecure deserialization, known vulnerable components, insufficient logging)
   - **CVE databases** — check known vulnerabilities in deployed software versions (NVD, vendor advisories)
   - **Dependency scans** — analyze third-party libraries and packages for known vulnerabilities (npm audit, pip safety, Dependabot, Snyk)
   - **Code analysis** — static analysis (SAST) findings, code review results, secrets in code
   - **Configuration review** — cloud misconfigurations, default credentials, overly permissive permissions, unencrypted storage

3. **Classify by CVSS score and exploitability:**
   - For each vulnerability, record:
     - **CVE/identifier** — CVE number or internal identifier
     - **CVSS base score** (0.0-10.0) and severity (None/Low/Medium/High/Critical)
     - **Exploitability** — is a public exploit available? Is it actively exploited in the wild?
     - **Attack vector** — network, adjacent, local, or physical
     - **Description** — what the vulnerability is and how it can be exploited

4. **Map to affected assets:**
   - Cross-reference each vulnerability with the asset inventory
   - Identify which systems, services, and data stores are affected
   - Note cascading effects: a vulnerability in a shared component affects all dependent assets
   - Highlight vulnerabilities affecting critical or customer-facing assets

5. **Prioritize by risk:**
   - Calculate effective risk: CVSS score x asset criticality modifier
     - Critical asset: 1.5x multiplier
     - High asset: 1.25x multiplier
     - Medium asset: 1.0x multiplier
     - Low asset: 0.75x multiplier
   - Factor in exploitability: actively exploited vulnerabilities get highest priority regardless of score
   - Group into remediation urgency: Immediate (0-48h), Urgent (1-2 weeks), Planned (30 days), Scheduled (90 days)

6. **Write the artifact** to `.metapowers/security/$ARGUMENTS/01-identify.md` with heading:

   ## Vulnerability Assessment

   Include sections:
   - **Assessment Scope** — systems assessed and methodology used
   - **Vulnerability Inventory** — all findings with CVE, CVSS, exploitability, and affected assets
   - **Risk Prioritization** — ranked list by effective risk score
   - **Remediation Timeline** — grouped by urgency with target resolution dates
   - **Trending Analysis** — patterns in vulnerability types indicating systemic issues

## Output

The vulnerability assessment written to `.metapowers/security/$ARGUMENTS/01-identify.md`. Present a summary to the user highlighting:
- Total vulnerabilities found by severity level
- Most critical findings requiring immediate attention
- Systemic patterns across vulnerability types
- Recommended remediation timeline and priorities