ui/.cursor/skills/security/SKILL.md

---
name: security
description: |
  OWASP-based security audit skill. Analyzes codebase for vulnerabilities across dependency scanning,
  static analysis, OWASP Top 10 review, and secrets detection. Produces a structured security report
  with severity-ranked findings and remediation guidance.
  Can be invoked standalone or as part of the autodev flow (optional step before deploy).
  Trigger phrases:
  - "security audit", "security scan", "OWASP review"
  - "vulnerability scan", "security check"
  - "check for vulnerabilities", "pentest"
category: review
tags: [security, owasp, sast, vulnerabilities, auth, injection, secrets]
disable-model-invocation: true
---

# Security Audit

Analyze the codebase for security vulnerabilities using OWASP principles. Produces a structured report with severity-ranked findings, remediation suggestions, and a security checklist verdict.

## Core Principles

- **OWASP-driven**: use the current OWASP Top 10 as the primary framework — verify the latest version at https://owasp.org/www-project-top-ten/ at audit start
- **Evidence-based**: every finding must reference a specific file, line, or configuration
- **Severity-ranked**: findings sorted Critical > High > Medium > Low
- **Actionable**: every finding includes a concrete remediation suggestion
- **Save immediately**: write artifacts to disk after each phase; never accumulate unsaved work
- **Complement, don't duplicate**: the `/code-review` skill does a lightweight security quick-scan; this skill goes deeper

## Context Resolution

**Project mode** (default):
- PROBLEM_DIR: `_docs/00_problem/`
- SOLUTION_DIR: `_docs/01_solution/`
- DOCUMENT_DIR: `_docs/02_document/`
- SECURITY_DIR: `_docs/05_security/`

**Standalone mode** (explicit target provided, e.g. `/security @src/api/`):
- TARGET: the provided path
- SECURITY_DIR: `_standalone/security/`

Announce the detected mode and resolved paths to the user before proceeding.

## Prerequisite Checks

1. Codebase must contain source code files — **STOP if empty**
2. Create SECURITY_DIR if it does not exist
3. If SECURITY_DIR already contains artifacts, ask user: **resume, overwrite, or skip?**
4. If `_docs/00_problem/security_approach.md` exists, read it for project-specific security requirements

## Progress Tracking

At the start of execution, create a TodoWrite with all phases (1 through 5). Update status as each phase completes.

## Workflow

### Phase 1: Dependency Scan

**Role**: Security analyst
**Goal**: Identify known vulnerabilities in project dependencies
**Constraints**: Scan only — no code changes

1. Detect the project's package manager(s): `requirements.txt`, `package.json`, `Cargo.toml`, `*.csproj`, `go.mod`
2. Run the appropriate audit tool:
   - Python: `pip audit` or `safety check`
   - Node: `npm audit`
   - Rust: `cargo audit`
   - .NET: `dotnet list package --vulnerable`
   - Go: `govulncheck`
3. If no audit tool is available, manually inspect dependency files for known CVEs using WebSearch
4. Record findings with CVE IDs, affected packages, severity, and recommended upgrade versions

**Self-verification**:
- [ ] All package manifests scanned
- [ ] Each finding has a CVE ID or advisory reference
- [ ] Upgrade paths identified for Critical/High findings

**Save action**: Write `SECURITY_DIR/dependency_scan.md`

---

### Phase 2: Static Analysis (SAST)

**Role**: Security engineer
**Goal**: Identify code-level vulnerabilities through static analysis
**Constraints**: Analysis only — no code changes

Scan the codebase for these vulnerability patterns:

**Injection**:
- SQL injection via string interpolation or concatenation
- Command injection (subprocess with shell=True, exec, eval, os.system)
- XSS via unsanitized user input in HTML output
- Template injection

**Authentication & Authorization**:
- Hardcoded credentials, API keys, passwords, tokens
- Missing authentication checks on endpoints
- Missing authorization checks (horizontal/vertical escalation paths)
- Weak password validation rules

**Cryptographic Failures**:
- Plaintext password storage (no hashing)
- Weak hashing algorithms (MD5, SHA1 for passwords)
- Hardcoded encryption keys or salts
- Missing TLS/HTTPS enforcement

**Data Exposure**:
- Sensitive data in logs or error messages (passwords, tokens, PII)
- Sensitive fields in API responses (password hashes, SSNs)
- Debug endpoints or verbose error messages in production configs
- Secrets in version control (.env files, config with credentials)

**Insecure Deserialization**:
- Pickle/marshal deserialization of untrusted data
- JSON/XML parsing without size limits

**Self-verification**:
- [ ] All source directories scanned
- [ ] Each finding has file path and line number
- [ ] No false positives from test files or comments

**Save action**: Write `SECURITY_DIR/static_analysis.md`

---

### Phase 3: OWASP Top 10 Review

**Role**: Penetration tester
**Goal**: Systematically review the codebase against current OWASP Top 10 categories
**Constraints**: Review and document — no code changes

1. Research the current OWASP Top 10 version at https://owasp.org/www-project-top-ten/
2. For each OWASP category, assess the codebase:

| Check | What to Look For |
|-------|-----------------|
| Broken Access Control | Missing auth middleware, IDOR vulnerabilities, CORS misconfiguration, directory traversal |
| Cryptographic Failures | Weak algorithms, plaintext transmission, missing encryption at rest |
| Injection | SQL, NoSQL, OS command, LDAP injection paths |
| Insecure Design | Missing rate limiting, no input validation strategy, trust boundary violations |
| Security Misconfiguration | Default credentials, unnecessary features enabled, missing security headers |
| Vulnerable Components | Outdated dependencies (from Phase 1), unpatched frameworks |
| Auth Failures | Brute force paths, weak session management, missing MFA |
| Data Integrity Failures | Missing signature verification, insecure CI/CD, auto-update without verification |
| Logging Failures | Missing audit logs, sensitive data in logs, no alerting for security events |
| SSRF | Unvalidated URL inputs, internal network access from user-controlled URLs |

3. Rate each category: PASS / FAIL / NOT_APPLICABLE
4. If `security_approach.md` exists, cross-reference its requirements against findings

**Self-verification**:
- [ ] All current OWASP Top 10 categories assessed
- [ ] Each FAIL has at least one specific finding with evidence
- [ ] NOT_APPLICABLE categories have justification

**Save action**: Write `SECURITY_DIR/owasp_review.md`

---

### Phase 4: Configuration & Infrastructure Review

**Role**: DevSecOps engineer
**Goal**: Review deployment configuration for security issues
**Constraints**: Review only — no changes

If Dockerfiles, CI/CD configs, or deployment configs exist:

1. **Container security**: non-root user, minimal base images, no secrets in build args, health checks
2. **CI/CD security**: secrets management, no credentials in pipeline files, artifact signing
3. **Environment configuration**: .env handling, secrets injection method, environment separation
4. **Network security**: exposed ports, TLS configuration, CORS settings, security headers

If no deployment configs exist, skip this phase and note it in the report.

**Self-verification**:
- [ ] All Dockerfiles reviewed
- [ ] All CI/CD configs reviewed
- [ ] All environment/config files reviewed

**Save action**: Write `SECURITY_DIR/infrastructure_review.md`

---

### Phase 5: Security Report

**Role**: Security analyst
**Goal**: Produce a consolidated security audit report
**Constraints**: Concise, actionable, severity-ranked

Consolidate findings from Phases 1-4 into a structured report:

```markdown
# Security Audit Report

**Date**: [YYYY-MM-DD]
**Scope**: [project name / target path]
**Verdict**: PASS | PASS_WITH_WARNINGS | FAIL

## Summary

| Severity | Count |
|----------|-------|
| Critical | [N] |
| High     | [N] |
| Medium   | [N] |
| Low      | [N] |

## OWASP Top 10 Assessment

| Category | Status | Findings |
|----------|--------|----------|
| [category] | PASS / FAIL / N/A | [count or —] |

## Findings

| # | Severity | Category | Location | Title |
|---|----------|----------|----------|-------|
| 1 | Critical | Injection | src/api.py:42 | SQL injection via f-string |

### Finding Details

**F1: [title]** (Severity / Category)
- Location: `[file:line]`
- Description: [what is vulnerable]
- Impact: [what an attacker could do]
- Remediation: [specific fix]

## Dependency Vulnerabilities

| Package | CVE | Severity | Fix Version |
|---------|-----|----------|-------------|
| [name] | [CVE-ID] | [sev] | [version] |

## Recommendations

### Immediate (Critical/High)
- [action items]

### Short-term (Medium)
- [action items]

### Long-term (Low / Hardening)
- [action items]
```

**Self-verification**:
- [ ] All findings from Phases 1-4 included
- [ ] No duplicate findings
- [ ] Every finding has remediation guidance
- [ ] Verdict matches severity logic

**Save action**: Write `SECURITY_DIR/security_report.md`

**BLOCKING**: Present report summary to user.

## Verdict Logic

- **FAIL**: any Critical or High finding exists
- **PASS_WITH_WARNINGS**: only Medium or Low findings
- **PASS**: no findings

## Security Checklist (Quick Reference)

### Authentication
- [ ] Strong password requirements (12+ chars)
- [ ] Password hashing (bcrypt, scrypt, Argon2)
- [ ] MFA for sensitive operations
- [ ] Account lockout after failed attempts
- [ ] Session timeout and rotation

### Authorization
- [ ] Check authorization on every request
- [ ] Least privilege principle
- [ ] No horizontal/vertical escalation paths

### Data Protection
- [ ] HTTPS everywhere
- [ ] Encrypted at rest
- [ ] Secrets not in code/logs/version control
- [ ] PII compliance (GDPR)

### Input Validation
- [ ] Server-side validation on all inputs
- [ ] Parameterized queries (no SQL injection)
- [ ] Output encoding (no XSS)
- [ ] Rate limiting on sensitive endpoints

### CI/CD Security
- [ ] Dependency audit in pipeline
- [ ] Secret scanning (git-secrets, TruffleHog)
- [ ] SAST in pipeline (Semgrep, SonarQube)
- [ ] No secrets in pipeline config files

## Escalation Rules

| Situation | Action |
|-----------|--------|
| Critical vulnerability found | **WARN user immediately** — do not defer to report |
| No audit tools available | Use manual code review + WebSearch for CVEs |
| Codebase too large for full scan | **ASK user** to prioritize areas (API endpoints, auth, data access) |
| Finding requires runtime testing (DAST) | Note as "requires DAST verification" — this skill does static analysis only |
| Conflicting security requirements | **ASK user** to prioritize |

## Common Mistakes

- **Security by obscurity**: hiding admin at secret URLs instead of proper auth
- **Client-side validation only**: JavaScript validation can be bypassed; always validate server-side
- **Trusting user input**: assume all input is malicious until proven otherwise
- **Hardcoded secrets**: use environment variables and secret management, never code
- **Skipping dependency scan**: known CVEs in dependencies are the lowest-hanging fruit for attackers

## Trigger Conditions

When the user wants to:
- Conduct a security audit of the codebase
- Check for vulnerabilities before deployment
- Review security posture after implementation
- Validate security requirements from `security_approach.md`

**Keywords**: "security audit", "security scan", "OWASP", "vulnerability scan", "security check", "pentest"

**Differentiation**:
- Lightweight security checks during implementation → handled by `/code-review` Phase 4
- Full security audit → use this skill
- Security requirements gathering → handled by `/problem` (security dimension)

## Methodology Quick Reference

```
┌────────────────────────────────────────────────────────────────┐
│              Security Audit (5-Phase Method)                    │
├────────────────────────────────────────────────────────────────┤
│ PREREQ: Source code exists, SECURITY_DIR created               │
│                                                                │
│ 1. Dependency Scan    → dependency_scan.md                     │
│ 2. Static Analysis    → static_analysis.md                     │
│ 3. OWASP Top 10      → owasp_review.md                        │
│ 4. Infrastructure     → infrastructure_review.md               │
│ 5. Security Report    → security_report.md                     │
│    [BLOCKING: user reviews report]                             │
├────────────────────────────────────────────────────────────────┤
│ Verdict: PASS / PASS_WITH_WARNINGS / FAIL                      │
│ Principles: OWASP-driven · Evidence-based · Severity-ranked    │
│             Actionable · Save immediately                      │
└────────────────────────────────────────────────────────────────┘
```