security-analysis

What this skill does

# Security Analysis Framework

Perform a comprehensive security vulnerability scan and analysis of the current project. Identifies the technology stack, scans for vulnerabilities in source code and dependencies, assesses real-world risk with context-aware analysis, and produces an actionable remediation roadmap.

## Auto-Activation Confirmation

When triggered automatically via `paths:` (i.e., a dependency manifest was modified), ask the user before proceeding:

> A dependency manifest file was changed (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `requirements.txt`, or `Gemfile`). Would you like to run a full security scan now? This will audit your dependencies for known CVEs and may take 1–15 minutes depending on project size. (y/n)

- **If the user confirms (y / yes):** proceed with the full scan using the instructions below. Default scan mode is `--dependencies-only` when auto-triggered (faster; targets the changed manifests). User may override with `--quick` or no flag for full scan.
- **If the user declines (n / no / anything other than y/yes):** respond with "Security scan skipped. You can run `/security-analysis` manually at any time." and exit immediately — do not perform any scanning.

When invoked directly by the user (not via paths auto-trigger), skip this prompt and proceed immediately.

---

## Input Validation

**Optional Arguments:**
- `<path>` - Directory or file path to analyze (defaults to current working directory)
- `--quick` - Surface scan only: technology detection, dependency audit, and top-level code patterns. Skips deep taint analysis and fuzzing methodology review.
- `--dependencies-only` - Only check dependency vulnerabilities (skip source code analysis)

**Usage:**
```text
/security-analysis                          # Full scan of current project
/security-analysis src/                     # Scan specific directory
/security-analysis --quick                  # Fast surface-level scan
/security-analysis --dependencies-only      # Dependencies only
```

## Proactive Triggers

Suggest this skill when:
1. The user mentions security, vulnerabilities, CVEs, or audit
2. After scaffolding a new project with `/scaffold-plugin` or similar
3. Before a release, deployment, or merge to production
4. When reviewing code that handles authentication, authorization, or user input
5. When the user adds or updates dependencies (package.json, requirements.txt, etc.)
6. After cloning or pulling a new/unfamiliar repository

## Performance

| Scan Mode | Expected Duration | Notes |
|-----------|-------------------|-------|
| Quick (`--quick`) | 1-3 minutes | Technology detection, dependency audit, surface-level code patterns |
| Full scan | 5-15 minutes | Deep taint analysis, data flow tracing, comprehensive code review |
| Dependencies-only (`--dependencies-only`) | 1-2 minutes | Native audit tools and known CVE checks |

Duration scales with codebase size (file count and total LOC). Web searches for CVE verification add latency when network-dependent lookups are required.

## Scope vs `/security-review`

| | `/security-review` (native) | `/security-analysis` (this skill) |
|---|---|---|
| **What it covers** | Pending changes — staged diffs and files you're about to commit | Full project: all source files, all dependencies, transitive CVEs |
| **When it runs** | Pre-commit, ad hoc on in-progress work | On-demand; before releases, after dependency updates, on new repos |
| **Depth** | Focused review of modified lines | Deep taint analysis, data flow tracing, OWASP Top 10 sweep |
| **Duration** | Seconds to ~1 minute | 1–15 minutes depending on mode and codebase size |

**Routing guidance:** Use `/security-review` when you want a fast check on what you're about to ship. Use this skill (`/security-analysis`) when you need full-project assurance — dependency CVE audit, static analysis across the entire codebase, and a prioritized remediation roadmap.

---

## Core Security Analysis Process

### Phase 1: Discovery and Reconnaissance

1. **Technology Stack Detection**: Identify languages, frameworks, and dependencies by scanning for manifest files (package.json, requirements.txt, pom.xml, go.mod, Cargo.toml, etc.)
2. **Attack Surface Mapping**: Enumerate all entry points (APIs, forms, file uploads, CLI arguments, environment variables)
3. **Dependency Inventory**: List all direct and transitive dependencies with version numbers
4. **Configuration Review**: Check for security-relevant configurations (CORS, CSP, auth settings)

### Phase 2: Vulnerability Scanning

#### A. Static Code Analysis

Scan source code for OWASP Top 10 and common vulnerability patterns:
- **Injection Vulnerabilities**: SQL, NoSQL, Command, LDAP, XPath, Template injection
- **Broken Authentication**: Weak password policies, session fixation, credential storage
- **Sensitive Data Exposure**: Hardcoded secrets, unencrypted data, logging sensitive info
- **XML External Entities (XXE)**: Unsafe XML parsing
- **Broken Access Control**: Missing authorization checks, IDOR vulnerabilities
- **Security Misconfiguration**: Default credentials, unnecessary features enabled
- **Cross-Site Scripting (XSS)**: Reflected, Stored, DOM-based
- **Insecure Deserialization**: Unsafe object deserialization
- **Using Components with Known Vulnerabilities**: Outdated dependencies
- **Insufficient Logging and Monitoring**: Missing security event logging

#### B. Dependency Vulnerability Analysis

**IMPORTANT**: Always run native security audit tools FIRST before web search for faster and more accurate results.

For each dependency:
1. **Extract Version Information**: From package manifests
2. **Run Native Security Audit Tools** (Primary Method):
   - **Node.js/JavaScript**: `npm audit` or `npm audit --json`
   - **Python**: `pip-audit` or `safety check`
   - **Java/Maven**: `mvn dependency-check:check`
   - **Java/Gradle**: `./gradlew dependencyCheckAnalyze`
   - **.NET**: `dotnet list package --vulnerable`
   - **PHP/Composer**: `composer audit`
   - **Ruby**: `bundle audit check`
   - **Rust**: `cargo audit`
   - **Go**: `govulncheck ./...`
3. **Parse Audit Results**: Extract CVE IDs, severity levels, and affected versions from tool output
4. **Web Search for CVEs** (Secondary/Verification Method): NVD, Snyk, GitHub Security Advisories
5. **Check Latest Versions**: Compare against current stable releases
6. **Assess Severity**: Use CVSS scores and exploit availability
7. **Verify Patch Availability**: Check if fixes exist and are stable

#### C. Context-Aware Analysis

For each identified vulnerability:
1. **Code Path Tracing**: Is the vulnerable code actually used?
2. **Import Analysis**: Are vulnerable functions imported?
3. **Call Graph Analysis**: Are vulnerable methods called?
4. **Data Flow Analysis**: Does user input reach vulnerable code?
5. **Environment Context**: Is this a dev-only or production dependency?

### Phase 3: Advanced Vulnerability Discovery

Skip this phase if `--quick` flag is set.

#### A. Taint Analysis and Data Flow Tracing
1. **Identify Sources**: Map all entry points (`req.body`, `argv`, `params`, `headers`)
2. **Identify Sinks**: Map dangerous functions (`eval()`, `exec()`, `innerHTML`, `SQL execution`)
3. **Trace Flow**: Trace if input reaches a sink without a sanitizer step
4. **Zero Tolerance**: If ANY user input reaches a sensitive sink without strict validation, flag as CRITICAL

#### B. Logic Abusability
1. **Race Conditions**: Identify concurrent state updates (db transactions, file writes)
2. **Business Logic**: Can you buy an item for $0? Can you access data ID+1?
3. **State Manipulation**: Can you skip a step in a multi-step flow?

#### C. Data Compromise Check
1. **Leakage**: Are PII, secrets, or internal IDs exposed in logs, error messages, or API responses?
2. **Integrity**: Can data be modified without authorization?
3. **Availability**: Can a payload cause a crash or high resource consumption (DoS)?

### Phase 4: Risk Assessment

#### Seve