loader/.cursor/skills/security/SKILL.md

name, description, category, tags, disable-model-invocation

name	description	category	tags	disable-model-invocation
security	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 autopilot flow (optional step before deploy). Trigger phrases: - "security audit", "security scan", "OWASP review" - "vulnerability scan", "security check" - "check for vulnerabilities", "pentest"	review	security owasp sast vulnerabilities auth injection secrets	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:

# 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                      │
└────────────────────────────────────────────────────────────────┘