Security Audit

When to Use

Use proactively when:

• Security review requested
• Auth/authz implementation
• API endpoint exposure
• LLM/AI integration code
• Dependency updates
• Pre-deployment audit

Triggers: security audit, security review, vulnerability check, pentest, threat model, OWASP, security scan

Do NOT use for: performance optimization, code style review

Dynamic Context

Project dependencies: !cat package.json 2>/dev/null | jq -r '.dependencies // empty | keys[]' 2>/dev/null | head -20 || pip list --format=freeze 2>/dev/null | head -20 || echo "No dependencies found"

Security Audit Skill

Purpose

Systematic security audit covering traditional web security and AI-era attack surfaces.

Usage

/security-audit src/api/           # audit specific directory
/security-audit                    # full project audit
/security-audit --focus llm        # LLM security only
/security-audit --focus deps       # dependency audit only

Audit Pipeline

Execute phases sequentially. Each finding gets a Confidence score (1-10). Only report findings with Confidence >= 6. Below 6 = informational note only.

Phase 1: Architecture & Attack Surface Census

Goal: Map the application's trust boundaries and entry points.

1. Identify all entry points (HTTP endpoints, WebSocket handlers, CLI args, file uploads, queue consumers)
2. Map trust boundaries (public internet, authenticated zone, admin zone, internal services)
3. Identify data flows crossing trust boundaries
4. List all external service integrations (databases, APIs, cloud services)

Output: Attack surface diagram (text-based)

Phase 2: Secrets Archaeology

Goal: Find hardcoded credentials, leaked keys, weak secret management.

# Pattern scan
grep -rn "password\s*=\|api_key\s*=\|secret\s*=\|token\s*=" --include="*.{py,ts,js,go,rs,java}" .
grep -rn "BEGIN.*PRIVATE KEY" .
grep -rn "sk-[a-zA-Z0-9]" .           # OpenAI keys
grep -rn "anthropic-[a-zA-Z0-9]" .    # Anthropic keys
grep -rn "ghp_[a-zA-Z0-9]" .          # GitHub tokens

Check:

• No secrets in source code
• .env files in .gitignore
• No secrets in git history (git log -p | grep -i "password\|secret\|api_key")
• Environment variables used for all credentials
• Rotation policy documented for all secrets

Phase 3: Dependency Supply Chain

Goal: Identify vulnerable or malicious dependencies.

# Node.js
pnpm audit
# Python
uv pip audit   # or pip-audit
# Check for typosquatting
# Check for abandoned packages (no updates >2 years)

Check:

• No critical/high CVEs in direct dependencies
• Lock file committed and up to date
• No wildcard version ranges (*, latest)
• No postinstall scripts from untrusted packages
• Dependencies match expected scope (no unexpected network/fs access)

Phase 4: OWASP Top 10 Scan

For each finding: [A0X] file:line — description (Confidence: N/10)

Phase 5: STRIDE Threat Model

For each major component/flow, evaluate:

Phase 6: LLM & AI Security

This phase applies when the project uses LLM/AI integrations.

Skip if no AI/LLM usage detected. This is the AI-era extension to traditional security auditing.

6.1 Prompt Injection Vectors

Scan for paths where user input reaches LLM prompts:

User Input → [transform?] → System/User Prompt → LLM → [tool calls?] → Response

Check:

• User input never concatenated directly into system prompts without sanitization
• Retrieval-augmented content (RAG) treated as untrusted (can contain injected instructions)
• Tool/function call results validated before re-injection into prompt
• Multi-turn conversations don't allow context manipulation via crafted history
• File uploads (PDF, images) scanned for embedded prompt injection payloads

Injection patterns to grep:

grep -rn "system.*\+.*user\|f\".*{user\|\.format(.*user" --include="*.py" .
grep -rn "role.*system.*\$\|`\$.*`.*system" --include="*.{ts,js}" .

6.2 Tool/Function Call Validation

When LLMs invoke tools (function calling, MCP tools, agent actions):

• Tool inputs are validated/sanitized before execution
• Tool permissions follow least privilege (no shell access unless required)
• Destructive tools (delete, write, execute) require confirmation or are sandboxed
• Tool output is bounded (prevent memory exhaustion from large responses)
• Tool call chains have depth limits (prevent infinite agent loops)

6.3 API Key & Cost Exposure

• LLM API keys not exposed to client-side code
• Per-user/per-session token limits enforced
• No unbounded loops that could amplify API costs (e.g., recursive agent calls)
• Rate limiting on LLM-powered endpoints
• Cost monitoring/alerting configured for LLM API usage
• Model selection not controllable by end-user input (prevent expensive model switching)

6.4 Output Security

• LLM output not rendered as raw HTML (XSS via generated content)
• LLM-generated code not executed without sandboxing
• LLM responses not used to construct SQL/shell commands without parameterization
• Sensitive data not leaked through LLM responses (PII in training data, context leakage)
• Content filtering applied to user-facing LLM output

6.5 Skill & Plugin Supply Chain

When the project loads external skills, plugins, or MCP servers:

• Skill source verified (official registry, known author, signed)
• Skill permissions audited (what tools/files can it access?)
• No skills with Bash or Write access to sensitive paths without justification
• Skill updates don't auto-apply without review
• MCP server configurations reviewed for excessive permissions
• Third-party MCP servers pinned to specific versions

Phase 7: False Positive Filtering

Before reporting, apply these exclusion rules:

• Test files (test_*, *.test.*, *.spec.*) — secrets in fixtures are expected
• Example/template files with placeholder values (example.env, *.template)
• Documentation code blocks showing patterns (not actual credentials)
• Disabled/commented-out code (flag as informational, not critical)
• Development-only configurations (if (process.env.NODE_ENV === 'development'))

Confidence recalibration: If finding depends on assumptions about deployment, reduce Confidence by 2.

Output Format

Summary Table

## Security Audit Summary

| Severity | Count | Status |
|----------|-------|--------|
| Critical | 0     | -      |
| High     | 2     | Fix required before deploy |
| Medium   | 3     | Fix before next release |
| Low      | 5     | Track and address |
| Info     | 2     | No action needed |

LLM Security: [Applicable/Not Applicable]
Overall Risk: [Critical/High/Medium/Low]

Finding Format

### [CRITICAL] A03 — SQL Injection in user search
- **File**: src/api/users.ts:47
- **Confidence**: 9/10
- **Description**: User input interpolated directly into SQL query
- **Impact**: Full database read/write access
- **Fix**: Use parameterized query
- **Evidence**: `db.query(\`SELECT * FROM users WHERE name = '${name}'\`)`

Severity Definitions

Related Skills

• /verify - General verification pipeline
• /cso - Extended security officer review (gstack-compatible)