Step 1: Threat Modeling (STRIDE)

Analyze threats using STRIDE:

Threat	Description	Example
Spoofing	Impersonating users/systems	Stolen credentials
Tampering	Modifying data	SQL injection
Repudiation	Denying actions	Missing audit logs
Information Disclosure	Data leaks	Exposed secrets
Denial of Service	Blocking access	Resource exhaustion
Elevation of Privilege	Gaining unauthorized access	Broken access control

For AI/agentic systems, extend STRIDE with:

Goal Hijacking (Spoofing + Tampering): Adversarial prompts redirect agent objectives
Memory Poisoning (Tampering + Information Disclosure): Persistent context corruption
Tool Misuse (Elevation of Privilege): Legitimate tools abused beyond intended scope

Step 2: OWASP Top 10 2025 Analysis

IMPORTANT: The OWASP Top 10 was updated in 2025 with two new categories and significant ranking shifts. Use this updated list, not the 2021 version.

Rank	ID	Vulnerability	Key Change from 2021
1	A01	Broken Access Control	Stable at #1; SSRF consolidated here
2	A02	Security Misconfiguration	Up from #5
3	A03	Software Supply Chain Failures	NEW — replaces Vulnerable Components
4	A04	Cryptographic Failures	Down from #2
5	A05	Injection	Down from #3
6	A06	Insecure Design	Down from #4
7	A07	Authentication Failures	Stable (renamed)
8	A08	Software or Data Integrity Failures	Stable
9	A09	Security Logging and Alerting Failures	Stable
10	A10	Mishandling of Exceptional Conditions	NEW

Check for each vulnerability:

A01: Broken Access Control (includes SSRF from 2021)
- Verify authorization on every endpoint; deny by default
- Check for IDOR (Insecure Direct Object Reference) vulnerabilities
- Validate/sanitize all URLs; use allowlists for outbound requests (absorbed SSRF)
- Enforce CORS policies; restrict cross-origin requests
A02: Security Misconfiguration (up from #5 — now #2, affects ~3% of tested apps)
- Harden defaults; disable unnecessary features, ports, services
- Remove sample/default credentials and example content
- Ensure consistent security settings across all environments (dev/staging/prod)
- Review cloud storage ACLs, IAM policies, and network security groups
A03: Software Supply Chain Failures (NEW — highest avg exploit/impact scores)
- Maintain an SBOM (Software Bill of Materials) for all dependencies
- Enforce lockfiles (package-lock.json, yarn.lock, poetry.lock) and verify integrity
- Use private registry scoping to prevent dependency confusion attacks
- Audit postinstall scripts; disable or allowlist explicitly
- Pin dependencies to exact versions and verify hashes/signatures
- Monitor CVE databases and security advisories (Dependabot, Snyk, Socket.dev)
- Harden CI/CD pipelines; enforce separation of duty (no single actor: write → deploy)
- Block exotic transitive dependencies (git URLs, direct tarballs) in production
A04: Cryptographic Failures (down from #2)
- Use strong algorithms: AES-256-GCM, SHA-256+, bcrypt/scrypt/Argon2 for passwords
- Never store plaintext passwords; enforce TLS 1.2+ everywhere
- Rotate secrets and keys; use envelope encryption for data at rest
A05: Injection (down from #3)
- Parameterize all queries (SQL, NoSQL, LDAP, OS commands)
- Validate and sanitize all inputs; apply output encoding for XSS prevention
A06: Insecure Design (down from #4)
- Threat model early in SDLC; use secure design patterns
- Apply principle of least privilege at design time
A07: Authentication Failures
- Implement MFA; prefer phishing-resistant methods (WebAuthn/Passkeys)
- Use OAuth 2.1 (mandatory PKCE, remove implicit/ROPC grants)
- Enforce secure session management; invalidate sessions on logout
A08: Software or Data Integrity Failures
- Verify dependencies with SRI hashes and cryptographic signatures
- Protect CI/CD pipelines; require signed commits and artifacts
A09: Security Logging and Alerting Failures
- Log all security events (auth failures, access control violations, input validation failures)
- Protect log integrity; never log secrets or PII
- Alert on anomalous patterns
A10: Mishandling of Exceptional Conditions (NEW)
- Ensure errors fail securely — never "fail open" (default to deny on error)
- Validate logic for edge cases: timeouts, partial responses, unexpected nulls
- Return generic error messages to clients; log detailed context server-side
- Test error handling paths explicitly (chaos/fault injection testing)

Step 3: OWASP Agentic AI Top 10 (ASI01-ASI10) — For AI/Agent Systems

When the codebase involves AI agents, LLMs, or autonomous systems, perform this additional assessment. Released December 2025 by OWASP GenAI Security Project.

ASI	Risk	Core Attack Vector
ASI01	Agent Goal Hijack	Prompt injection redirects agent objectives
ASI02	Tool Misuse	Legitimate tools abused beyond intended scope
ASI03	Identity & Privilege Abuse	Credential inheritance/delegation without scoping
ASI04	Supply Chain Vulnerabilities	Malicious tools, MCP servers, agent registries
ASI05	Unexpected Code Execution	Agent-generated code bypasses security controls
ASI06	Memory & Context Poisoning	Persistent corruption of agent memory/embeddings
ASI07	Insecure Inter-Agent Communication	Weak agent-to-agent protocol validation
ASI08	Cascading Failures	Error propagation across chained agents
ASI09	Human-Agent Trust Exploitation	Agents manipulate users into unsafe approvals
ASI10	Rogue Agents	Agents act outside authorized scope

ASI01 — Agent Goal Hijack: Attackers manipulate planning logic via prompt injection in user input, RAG documents, emails, or calendar invites.

Mitigations: Validate all inputs against expected task scope; enforce task boundary checks in routing layer; use system prompts that resist goal redirection; log unexpected task deviations for review.

ASI02 — Tool Misuse: Agents use tools beyond intended scope (e.g., file deletion when only file read was authorized).

Mitigations: Whitelist/blacklist tools per agent role; validate tool parameters before execution; enforce principle of least privilege for tool access; monitor tool usage patterns for anomalies.

ASI03 — Identity & Privilege Abuse: Agents inherit or delegate credentials without proper scoping, creating attribution gaps.

Mitigations: Assign each agent a distinct, scoped identity; never reuse human credentials for agents; audit all credential delegation chains; enforce short-lived tokens for agent actions.

ASI04 — Supply Chain Vulnerabilities (Agentic): Malicious MCP servers, agent cards, plugin registries, or tool packages poison the agent ecosystem.

Mitigations: Verify integrity of all tool/plugin sources; use registry allowlists; audit MCP server provenance; apply same supply chain controls as A03 to agent tooling.

ASI05 — Unexpected Code Execution: Agent-generated or "vibe-coded" code executes without traditional security controls (sandboxing, review).

Mitigations: Sandbox code execution environments; review agent-generated code before execution in production; apply static analysis to generated code; never execute code from memory/context without validation.

ASI06 — Memory & Context Poisoning: Attackers embed malicious instructions in documents, web pages, or RAG corpora that persist in agent memory and influence future actions.

Mitigations: Sanitize all data written to memory (learnings, vector stores, embeddings); validate memory entries before use; never execute commands sourced from memory without explicit approval; implement memory rotation and auditing (see ADR-102).

ASI07 — Insecure Inter-Agent Communication: Agent-to-agent messages lack authentication, integrity checks, or semantic validation, enabling injection attacks between agents.

Mitigations: Authenticate all agent-to-agent messages; validate message schemas; use signed inter-agent payloads; apply semantic validation (not just structural) to delegated instructions.

ASI08 — Cascading Failures: Errors or attacks in one agent propagate uncontrolled through multi-agent pipelines.

Mitigations: Define error boundaries between agents; implement circuit breakers; require human-in-the-loop checkpoints for high-impact actions; never auto-retry destructive operations on failure.

ASI09 — Human-Agent Trust Exploitation: Agents present misleading information to manipulate users into approving unsafe actions.

Mitigations: Display agent reasoning and provenance transparently; require explicit human confirmation for irreversible actions; detect urgency/fear manipulation patterns; maintain audit trails of all user-agent interactions.

ASI10 — Rogue Agents: Agents operate outside authorized scope, take unsanctioned actions, or resist human override.

Mitigations: Enforce hard authorization boundaries at the infrastructure level (not just prompt level); implement kill-switch mechanisms; log all agent actions with human-reviewable audit trail; test override/shutdown paths regularly.

Step 4: Supply Chain Security Review

Perform this check for all projects with external dependencies:

# Check for known vulnerabilities
npm audit --audit-level=high
# or
pnpm audit

# Verify lockfile integrity (ensure lockfile is committed and not bypassed)
# Check that package-lock.json / yarn.lock / pnpm-lock.yaml exists and is current

# Scan for malicious packages (behavioral analysis)
# Tools: Socket.dev, Snyk, Aikido, Safety (Python)

Dependency Confusion Defense:

Scope all internal packages under a private namespace (e.g., @company/package-name)
Configure registry resolution order to prefer private registry
Use publishConfig and registry scoping to prevent public registry fallback for private packages
Block exotic transitive dependencies (git URLs, direct tarball URLs)

Typosquatting Defense:

Audit all npm install / pip install commands for misspellings
Use allowlists for permitted packages in automated environments
Delay new dependency version installs by 24+ hours (minimumReleaseAge) to allow malware detection

CI/CD Pipeline Hardening:

Enforce separation of duty: no single actor writes code AND promotes to production
Sign all build artifacts and verify signatures before deployment
Pin action versions in GitHub Actions (use commit SHA, not floating tags)
Restrict pipeline secrets to minimum required scope

Step 5: Modern API Authentication Review

OAuth 2.1 (current standard — replaces OAuth 2.0 for new implementations):

OAuth 2.1 removes insecure grants:
  - Implicit grant (response_type=token) — REMOVED: tokens in URL fragments leak
  - Resource Owner Password Credentials (ROPC) — REMOVED: breaks delegated auth model

OAuth 2.1 mandates:
  - PKCE (Proof Key for Code Exchange) for ALL authorization code flows
  - Exact redirect URI matching (no wildcards)
  - Sender-constraining tokens (DPoP recommended)

DPoP — Demonstrating Proof of Possession (RFC 9449):

Binds access/refresh tokens cryptographically to the client's key pair
Prevents token replay attacks even if tokens are intercepted
Implement for all public clients (SPAs, mobile apps) where bearer token theft is a concern

// DPoP proof JWT structure (sent in DPoP header with each request)
// Header: { "typ": "dpop+jwt", "alg": "ES256", "jwk": { client_public_key } }
// Payload: { "jti": nonce, "htm": "POST", "htu": "https://api.example.com/token", "iat": timestamp }
// Signed with client private key — server verifies binding to issued token

Passkeys / WebAuthn (FIDO2) — for user-facing authentication:

Phishing-resistant: credentials are origin-bound and never transmitted
Replaces passwords and SMS OTP for high-security contexts
Major platforms (Windows, macOS, iOS, Android) support cross-device sync as of 2026
Implementation: use navigator.credentials.create() (registration) and navigator.credentials.get() (authentication)
Store only the public key and credential ID server-side (never the private key)

// WebAuthn registration (simplified)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge, // random bytes from server
    rp: { name: 'My App', id: 'myapp.example.com' },
    user: { id: userId, name: userEmail, displayName: userName },
    pubKeyCredParams: [{ alg: -7, type: 'public-key' }], // ES256
    authenticatorSelection: { residentKey: 'preferred', userVerification: 'required' },
  },
});
// Send credential.id and credential.response to server for verification

Step 6: Security Code Review

Look for common issues:

// BAD: SQL Injection
const query = `SELECT * FROM users WHERE id = ${userId}`;

// GOOD: Parameterized query
const query = `SELECT * FROM users WHERE id = $1`;
await db.query(query, [userId]);

// BAD: Hardcoded secrets
const apiKey = 'sk-abc123...';

// GOOD: Environment variables / secret manager
const apiKey = process.env.API_KEY;

// BAD: shell: true (shell injection vector)
const { exec } = require('child_process');
exec(`git commit -m "${userMessage}"`);

// GOOD: shell: false with array arguments
const { spawn } = require('child_process');
spawn('git', ['commit', '-m', userMessage], { shell: false });

// BAD: Fail open on error (dangerous for auth/authz)
try {
  const isAuthorized = await checkPermission(user, resource);
  if (isAuthorized) return next();
} catch (err) {
  return next(); // WRONG: allows access on error
}

// GOOD: Fail securely (deny on error — A10:2025)
try {
  const isAuthorized = await checkPermission(user, resource);
  if (!isAuthorized) return res.status(403).json({ error: 'Forbidden' });
  return next();
} catch (err) {
  logger.error('Permission check failed', { err, user, resource });
  return res.status(403).json({ error: 'Forbidden' }); // Default deny
}

Step 7: Authentication/Authorization Review

Verify:

Strong password requirements OR passkey/WebAuthn (preferred in 2026)
Secure session management (HTTPOnly, Secure, SameSite=Strict cookies)
JWT validation (signature, expiry, audience, issuer)
Role-based access control (RBAC) enforced server-side
API authentication: OAuth 2.1 + PKCE (not OAuth 2.0 implicit/ROPC)
DPoP sender-constraining for public clients handling sensitive data
Phishing-resistant MFA (WebAuthn preferred over SMS OTP)

Step 8: Generate Security Report

Create findings report:

## Security Assessment Report

### Critical Findings

1. SQL injection in /api/users endpoint
   - Risk: Data breach
   - Fix: Use parameterized queries

### High Findings

2. Missing rate limiting on login
   - Risk: Brute force attacks
   - Fix: Implement rate limiting

3. OAuth 2.0 implicit grant in use (deprecated)
   - Risk: Access token exposure in URL fragments / browser history
   - Fix: Migrate to Authorization Code + PKCE (OAuth 2.1)

### Medium Findings

4. No lockfile committed for npm dependencies
   - Risk: Supply chain attack via dependency resolution drift
   - Fix: Commit package-lock.json; add lockfile verification to CI

### Recommendations

- Enable HTTPS everywhere; enforce HSTS
- Implement CSP headers
- Add security logging for auth events
- Migrate to OAuth 2.1 (remove implicit/ROPC grants)
- Implement passkey/WebAuthn for phishing-resistant authentication
- Run `npm audit` / `pnpm audit` in CI with failure on high/critical

</execution_process>

<best_practices>

Defense in Depth: Layer security controls; no single control is sufficient
Least Privilege: Minimal permissions for users, services, and AI agents
Fail Securely: Default to deny — especially on errors (A10:2025)
Validate Everything: Never trust input from any source, including agent memory
Keep Secrets Secret: Use secret managers; rotate regularly; never commit credentials
Supply Chain Hygiene: Lock dependencies, verify integrity, monitor for compromise
Human-in-the-Loop for Agents: Require explicit approval for irreversible agentic actions
Modern Auth Standards: OAuth 2.1 + PKCE, DPoP, and Passkeys/WebAuthn over legacy flows

</best_practices>

Review the authentication flow in src/auth/ for security issues

Example Response:

## Security Review: src/auth/

### Findings

#### CRITICAL: Weak Password Hashing

- File: src/auth/password.js:23
- Issue: Using MD5 for password hashing
- Fix: Use bcrypt with cost factor >= 12

#### HIGH: No Rate Limiting

- File: src/auth/login.js
- Issue: Login endpoint has no rate limiting
- Fix: Add rate limiting (5 attempts/minute)

#### HIGH: OAuth 2.0 Implicit Grant in Use

- File: src/auth/oauth.js:45
- Issue: Using response_type=token (implicit grant, deprecated in OAuth 2.1)
- Fix: Migrate to Authorization Code flow with PKCE

#### MEDIUM: Session Not Invalidated

- File: src/auth/logout.js
- Issue: Logout doesn't invalidate server-side session
- Fix: Clear session from store on logout

### Recommendations

1. Implement bcrypt for password hashing (cost factor >= 12)
2. Add rate limiting middleware (5 req/min on /login)
3. Migrate OAuth flows to Authorization Code + PKCE (OAuth 2.1)
4. Consider passkeys/WebAuthn for phishing-resistant authentication
5. Use secure session configuration (HTTPOnly, Secure, SameSite=Strict)

</usage_example>

<usage_example> AI Agent Security Review Request:

Review the LLM agent pipeline in src/agents/ for agentic AI security risks

Example Response:

## Agentic AI Security Review: src/agents/

### ASI01 — Agent Goal Hijack (HIGH)

- File: src/agents/email-processor.js
- Issue: User email content passed directly to agent system prompt without sanitization
- Fix: Sanitize email content; enforce task boundary validation in routing layer

### ASI06 — Memory & Context Poisoning (HIGH)

- File: src/agents/memory-store.js:78
- Issue: Web-fetched content written to persistent memory without validation
- Fix: Validate and sanitize all external content before writing to memory; never
  execute commands retrieved from memory without explicit human approval

### ASI02 — Tool Misuse (MEDIUM)

- File: src/agents/tools/file-tool.js
- Issue: Agent has both read and delete file permissions; delete scope too broad
- Fix: Split into read-only and write tools; apply least privilege per agent role

### ASI10 — Rogue Agent Risk (MEDIUM)

- Issue: No kill-switch or hard resource limits on agent execution
- Fix: Implement max-steps limit, timeout, and human override checkpoint for
  operations affecting production data

</usage_example>

Iron Laws

NEVER approve production deployment for code handling auth, PII, or external data without a completed security review
ALWAYS run both OWASP Top 10 2025 AND ASI01-ASI10 assessments for AI/agentic systems
ALWAYS fail securely — design all error paths to deny by default, never allow
NEVER trust any input without validation, including data from internal services
ALWAYS prioritize findings by severity (CRITICAL > HIGH > MEDIUM > LOW) with specific remediation steps and code examples

Anti-Patterns

Anti-Pattern	Why It Fails	Correct Approach
Approving code without full security review	Partial reviews miss exploitable paths in auth/PII/external data flows	Complete all STRIDE + OWASP phases before approving production deployment
Using OWASP 2021 for AI/agentic systems	AI-specific threats (ASI01-ASI10) are not covered by the standard web list	Always run both OWASP Top 10 2025 and ASI01-ASI10 for any agentic component
Failing open on security errors	Error paths become exploitable bypass conditions	Design every failure mode to deny access by default
Providing vague remediation guidance	Developers cannot act without specifics	Provide exact code examples and parameterized fix patterns for every finding
Missing severity prioritization	Critical findings are buried in noise with informational findings	Triage all findings as CRITICAL > HIGH > MEDIUM > LOW before delivery

Related Skills

auth-security-expert - OAuth 2.1, JWT, and authentication-specific security patterns

Related Workflow

For comprehensive security audits requiring multi-phase threat analysis, vulnerability scanning, and remediation planning, see the corresponding workflow:

Workflow File: .claude/workflows/security-architect-skill-workflow.md
When to Use: For structured security audits requiring OWASP Top 10 2025 analysis, dependency CVE checks, penetration testing, and remediation planning
Phases: 5 phases (Threat Modeling, Security Code Review, Dependency Audit, Penetration Testing, Remediation Planning)
Coverage: Full OWASP Top 10 2025, OWASP Agentic AI Top 10 (ASI01-ASI10), STRIDE threat modeling, CVE database checks, automated and manual penetration testing

Key Features:

Multi-agent orchestration (security-architect, code-reviewer, developer, devops)
Security gates for pre-release blocking
Severity classification (CRITICAL/HIGH/MEDIUM/LOW)
Automated ticket generation
Compliance-ready reporting (SOC2, GDPR, HIPAA)

See also: Feature Development Workflow for integrating security reviews into the development lifecycle.

Memory Protocol (MANDATORY)

Before starting:

cat .claude/context/memory/learnings.md

After completing:

New pattern -> .claude/context/memory/learnings.md
Issue found -> .claude/context/memory/issues.md
Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

security-architect

Security Architect Skill