Security Deep Dive
Think like an attacker. What would you try to break?
Progress Checklist
Step 0: Scope and Threat Model
Before diving in, understand what we're protecting:
- What data is sensitive? (PII, credentials, financial, health)
- Who are the threat actors? (anonymous users, authenticated users, insiders, automated attacks)
- What's the impact of a breach? (data leak, financial loss, reputation, compliance violation)
- What's already in place? (auth, encryption, monitoring, WAF)
Step 1: Attack Surface Mapping
List every entry point:
# Find API endpoints
grep -rn "router\.\|app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" --include="*.go"
grep -rn "\[Http\(Get\|Post\|Put\|Delete\|Patch\)\]" --include="*.cs"
grep -rn "@app\.\(route\|get\|post\)" --include="*.py"
# Find forms and user input
grep -rn "<form\|<input\|<textarea\|<select" --include="*.html" --include="*.tsx" --include="*.vue"
# Find file upload handlers
grep -rn "upload\|multipart\|formData\|IFormFile" -l
# Find webhook/queue consumers
grep -rn "webhook\|queue\|consumer\|subscriber" -l
For each entry point, note: authentication requirement, input sources, data sensitivity.
Step 2: Auth Flow Analysis
Trace the full authentication and authorization path:
- How are credentials submitted? (form, header, cookie)
- How are they validated? (database lookup, JWT verification, OAuth flow)
- How is the session maintained? (JWT, session cookie, token refresh)
- How is authorization checked? (middleware, per-endpoint, attribute-based)
- What happens on auth failure? (error message, rate limiting, lockout)
Look for:
- Missing auth on endpoints that should require it
- Authorization checks that only check authentication ("is logged in" but not "can access this resource")
- IDOR vulnerabilities (can user A access user B's data by changing an ID?)
- Token handling issues (stored in localStorage? No expiry? No rotation?)
Step 2b: LLM/GenAI Threat Surface
Check if the codebase integrates LLMs:
rg -l "openai|anthropic|langchain|@ai-sdk|ChatCompletion|messages\.create|semantic[.-]kernel|Microsoft\.SemanticKernel|GenerateContent" --type-add 'code:*.{ts,js,py,cs,go}' -t code
If matches found, load ../_shared/owasp-llm-top-10.md and check:
- Prompt construction - How are prompts built? Is user input concatenated directly, or separated into distinct message roles?
- Output consumption - Where does LLM output go? Is it rendered as HTML, used in SQL, passed to eval/exec, or used in file paths?
- Tool/function calling - What tools does the LLM have access to? Can it execute shell commands, run arbitrary SQL, or fetch arbitrary URLs?
- RAG pipeline - Is there a vector store? Are queries filtered by tenant? Can users inject content into the knowledge base?
- System prompts - Do they contain secrets, internal URLs, or security-sensitive logic?
- Rate limiting - Are LLM endpoints rate-limited? Are there token budgets and timeouts?
- Human-in-the-loop - Do destructive actions triggered by the LLM require user approval?
For each finding, assess against the OWASP LLM Top 10 severity levels.
Step 3: Dependency Chain Audit
# JavaScript
npm audit 2>/dev/null
npx better-npm-audit audit 2>/dev/null
# .NET
dotnet list package --vulnerable 2>/dev/null
# Go
govulncheck ./... 2>/dev/null
# Check for abandoned packages
# Look for: last publish date, open issues, maintainer activity
Beyond known CVEs:
- Any dependencies pulling in unexpected transitive dependencies?
- Any dependencies with excessive permissions (file system, network)?
- Supply chain risk: are dependencies from trusted sources?
Step 4: Infrastructure Config
# Docker
grep -r "USER\|EXPOSE\|ENV\|ARG.*secret\|COPY.*\.env" Dockerfile* 2>/dev/null
# Kubernetes
grep -rn "securityContext\|privileged\|runAsRoot\|capabilities" k8s/ 2>/dev/null
grep -rn "kind: Secret" k8s/ 2>/dev/null
# Environment and secrets
grep -rn "password\|secret\|key\|token" .env* docker-compose* 2>/dev/null
Check for:
- Containers running as root
- Exposed ports that shouldn't be public
- Default credentials
- Secrets in plaintext config
- Missing network policies
- Overly permissive CORS
Step 5: Exploitation Paths
For each finding, think through the attack:
- How would you exploit this? Be specific: what request, what payload, what sequence
- What's the impact? Data exposure, privilege escalation, denial of service, RCE
- What's the likelihood? Does the attacker need to be authenticated? Special knowledge?
- How easy is it? Script kiddie vs. targeted attack
Step 6: Report
| Severity |
Criteria |
| Critical |
RCE, auth bypass, mass data exposure. Fix immediately. |
| High |
Privilege escalation, IDOR, SQL injection, XSS. Fix before release. |
| Medium |
Information disclosure, missing headers, verbose errors. Fix soon. |
| Low |
Minor hardening, best practice deviations. Fix when convenient. |
For each finding:
- What the vulnerability is
- Where it exists (file, line, endpoint)
- How it could be exploited
- Recommended fix
- Severity with justification
See ../_shared/security-checklist.md for the detailed checklist, ../codebase-audit/references/owasp-top-10.md for OWASP patterns, and ../_shared/owasp-llm-top-10.md for LLM-specific risks.
1---2name: security-deep-dive3description: Performs red team security analysis with threat modeling, attack surface mapping, auth flow analysis, and dependency chain audits. Goes beyond checklists to think like an attacker. Use when doing security audit, penetration testing, threat modeling, security review, attack surface analysis, red team assessment, or when codebase-audit flags serious security concerns.4---56# Security Deep Dive78Think like an attacker. What would you try to break?910## Progress Checklist1112- [ ] Define scope and threat model13- [ ] Map the attack surface14- [ ] Analyze auth flows15- [ ] Audit LLM/GenAI threat surface (if applicable)16- [ ] Audit dependency chain17- [ ] Review infrastructure config18- [ ] Attempt exploitation paths19- [ ] Report findings with severity2021## Step 0: Scope and Threat Model2223Before diving in, understand what we're protecting:2425- What data is sensitive? (PII, credentials, financial, health)26- Who are the threat actors? (anonymous users, authenticated users, insiders, automated attacks)27- What's the impact of a breach? (data leak, financial loss, reputation, compliance violation)28- What's already in place? (auth, encryption, monitoring, WAF)2930## Step 1: Attack Surface Mapping3132List every entry point:3334```bash35# Find API endpoints36grep -rn "router\.\|app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" --include="*.go"37grep -rn "\[Http\(Get\|Post\|Put\|Delete\|Patch\)\]" --include="*.cs"38grep -rn "@app\.\(route\|get\|post\)" --include="*.py"3940# Find forms and user input41grep -rn "<form\|<input\|<textarea\|<select" --include="*.html" --include="*.tsx" --include="*.vue"4243# Find file upload handlers44grep -rn "upload\|multipart\|formData\|IFormFile" -l4546# Find webhook/queue consumers47grep -rn "webhook\|queue\|consumer\|subscriber" -l48```4950For each entry point, note: authentication requirement, input sources, data sensitivity.5152## Step 2: Auth Flow Analysis5354Trace the full authentication and authorization path:55561. How are credentials submitted? (form, header, cookie)572. How are they validated? (database lookup, JWT verification, OAuth flow)583. How is the session maintained? (JWT, session cookie, token refresh)594. How is authorization checked? (middleware, per-endpoint, attribute-based)605. What happens on auth failure? (error message, rate limiting, lockout)6162Look for:63- Missing auth on endpoints that should require it64- Authorization checks that only check authentication ("is logged in" but not "can access this resource")65- IDOR vulnerabilities (can user A access user B's data by changing an ID?)66- Token handling issues (stored in localStorage? No expiry? No rotation?)6768## Step 2b: LLM/GenAI Threat Surface6970Check if the codebase integrates LLMs:7172```bash73rg -l "openai|anthropic|langchain|@ai-sdk|ChatCompletion|messages\.create|semantic[.-]kernel|Microsoft\.SemanticKernel|GenerateContent" --type-add 'code:*.{ts,js,py,cs,go}' -t code74```7576If matches found, load `../_shared/owasp-llm-top-10.md` and check:77781. **Prompt construction** - How are prompts built? Is user input concatenated directly, or separated into distinct message roles?792. **Output consumption** - Where does LLM output go? Is it rendered as HTML, used in SQL, passed to eval/exec, or used in file paths?803. **Tool/function calling** - What tools does the LLM have access to? Can it execute shell commands, run arbitrary SQL, or fetch arbitrary URLs?814. **RAG pipeline** - Is there a vector store? Are queries filtered by tenant? Can users inject content into the knowledge base?825. **System prompts** - Do they contain secrets, internal URLs, or security-sensitive logic?836. **Rate limiting** - Are LLM endpoints rate-limited? Are there token budgets and timeouts?847. **Human-in-the-loop** - Do destructive actions triggered by the LLM require user approval?8586For each finding, assess against the OWASP LLM Top 10 severity levels.8788## Step 3: Dependency Chain Audit8990```bash91# JavaScript92npm audit 2>/dev/null93npx better-npm-audit audit 2>/dev/null9495# .NET96dotnet list package --vulnerable 2>/dev/null9798# Go99govulncheck ./... 2>/dev/null100101# Check for abandoned packages102# Look for: last publish date, open issues, maintainer activity103```104105Beyond known CVEs:106- Any dependencies pulling in unexpected transitive dependencies?107- Any dependencies with excessive permissions (file system, network)?108- Supply chain risk: are dependencies from trusted sources?109110## Step 4: Infrastructure Config111112```bash113# Docker114grep -r "USER\|EXPOSE\|ENV\|ARG.*secret\|COPY.*\.env" Dockerfile* 2>/dev/null115116# Kubernetes117grep -rn "securityContext\|privileged\|runAsRoot\|capabilities" k8s/ 2>/dev/null118grep -rn "kind: Secret" k8s/ 2>/dev/null119120# Environment and secrets121grep -rn "password\|secret\|key\|token" .env* docker-compose* 2>/dev/null122```123124Check for:125- Containers running as root126- Exposed ports that shouldn't be public127- Default credentials128- Secrets in plaintext config129- Missing network policies130- Overly permissive CORS131132## Step 5: Exploitation Paths133134For each finding, think through the attack:1351361. **How would you exploit this?** Be specific: what request, what payload, what sequence1372. **What's the impact?** Data exposure, privilege escalation, denial of service, RCE1383. **What's the likelihood?** Does the attacker need to be authenticated? Special knowledge?1394. **How easy is it?** Script kiddie vs. targeted attack140141## Step 6: Report142143| Severity | Criteria |144|----------|---------|145| **Critical** | RCE, auth bypass, mass data exposure. Fix immediately. |146| **High** | Privilege escalation, IDOR, SQL injection, XSS. Fix before release. |147| **Medium** | Information disclosure, missing headers, verbose errors. Fix soon. |148| **Low** | Minor hardening, best practice deviations. Fix when convenient. |149150For each finding:1511. What the vulnerability is1522. Where it exists (file, line, endpoint)1533. How it could be exploited1544. Recommended fix1555. Severity with justification156157See `../_shared/security-checklist.md` for the detailed checklist, `../codebase-audit/references/owasp-top-10.md` for OWASP patterns, and `../_shared/owasp-llm-top-10.md` for LLM-specific risks.