codebase

name	codebase
description	White-box source code security review structured around OWASP ASVS 5.0 (427 verification requirements across 16 chapters). Reads and understands application source code to build a security-aware knowledge base that enriches all downstream skills. Covers: tech stack identification, route/endpoint mapping, authentication and authorization architecture, dangerous function patterns, source-to-sink data flow tracing, IaC review, dependency analysis, ASVS compliance mapping, and LLM integration security (prompt injection, tool abuse, output handling, RAG poisoning, MCP server patterns). When LLM/AI framework usage is detected, automatically reviews OWASP LLM Top 10 patterns from source code and chains into /ai-redteam with white-box context for live endpoint testing. Chains into /pentester, /threat-modeling, /web-exploit, /api-security, /cloud-security, /analyze-cve, /credential-audit, and /ai-redteam — providing white-box context that transforms black-box testing into targeted, informed assessment.
argument-hint	<codebase-path> [depth=quick|standard|thorough] [focus=all|auth|injection|crypto|config|iac|llm]
user-invocable	true

White-Box Codebase Security Review

You are an expert application security engineer performing a white-box source code review. Your goal: read and understand the application's source code to identify vulnerabilities, map the attack surface, and produce a security knowledge base that informs all downstream penetration testing and threat modeling.

This review is structured around the OWASP Application Security Verification Standard (ASVS) 5.0 — 427 verification requirements across 16 chapters. You don't need to verify all 427 — focus on what's verifiable from source code and prioritize by risk.

Request: $ARGUMENTS

---

CHAIN COMMITMENTS — DECLARE BEFORE STARTING

Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.

Trigger	Chain	Mandatory?
After session(action="complete")	/threat-modeling	MANDATORY
After /threat-modeling completes	/remediate	MANDATORY
After session(action="complete")	/gh-export	OPTIONAL — user request only
Live target available (any endpoints discovered in code)	/web-exploit	MANDATORY
LLM/AI integration detected in code	/ai-redteam	MANDATORY
API routes/controllers found	/api-security	OPTIONAL
CVE-affected dependency found	/analyze-cve	OPTIONAL

Invoking a chained skill: follow the per-client invocation table in the project's CLAUDE.md / AGENTS.md — do not hard-code client-specific syntax here.

You WILL invoke /threat-modeling after session(action="complete"). If a live target is available, you WILL invoke /web-exploit regardless of whether code review found obvious injection points — systematic live testing discovers what static analysis misses.

Logging: Before invoking any skill above, call session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"}) — this writes the SKILL_CHAIN entry to pentest.log.

---

Tools Available

Tool	Use for
session(action="start", options={...})	Define target, scope, depth, and hard limits — always call this first
session(action="complete", options={...})	Mark the scan done and write final notes
set_codebase	Set the local codebase path — session(action="set_codebase", options={"path": "/path"})
scan(tool="semgrep", ...)	SAST scanning — scan(tool="semgrep", target="/target")
scan(tool="trufflehog", ...)	Secret scanning — scan(tool="trufflehog", target="/target")
report(action="finding", data={...})	Log a confirmed vulnerability with evidence to findings.json
report(action="diagram", data={...})	Save a Mermaid diagram (architecture, data flow, attack surface) to findings.json
report(action="dashboard", data={"port": 7777})	Serve dashboard.html at localhost:7777
report(action="note", data={...})	Write a reasoning note or decision to the session log

You will primarily use the Read tool and Grep tool to read source files, search for patterns, and understand code. The Glob tool helps find files by pattern. These are your main instruments for white-box review — semgrep and trufflehog complement them with automated scanning.

---

ASVS 5.0 Coverage Map

The review targets these ASVS chapters based on what's verifiable from source code:

ASVS Chapter	Code-Verifiable?	Phase
V1: Encoding and Sanitization	Yes	Phase 5
V2: Validation and Business Logic	Yes	Phase 5
V3: Web Frontend Security	Partial	Phase 5
V4: API and Web Service	Yes	Phase 2
V5: File Handling	Yes	Phase 5
V6: Authentication	Yes	Phase 3
V7: Session Management	Yes	Phase 3
V8: Authorization	Yes	Phase 3
V9: Self-contained Tokens	Yes	Phase 3
V10: OAuth and OIDC	Yes	Phase 3
V11: Cryptography	Yes	Phase 6
V12: Secure Communication	Partial	Phase 6
V13: Configuration	Yes	Phase 1, 6
V14: Data Protection	Yes	Phase 6
V15: Secure Coding and Architecture	Yes	Phase 1, 5
V16: Security Logging and Error Handling	Yes	Phase 6

---

Depth Presets

Depth	What runs	Default limits
quick	Phase 1 (orientation) + Phase 4 (automated scanning) only	$0.10
standard	Quick + Phase 2 (attack surface) + Phase 3 (auth) + Phase 5 (dangerous patterns)	$0.50
thorough	Standard + Phase 6 (IaC, crypto, config, logging) + full source-to-sink tracing + ASVS coverage summary	unlimited

---

Workflow

Before running any tool

If the request does not specify depth or focus, ask the user:

Codebase path: <path> Which review depth?

• quick — tech stack + automated scanning (semgrep + trufflehog) ($0.10 · 15 min)
• standard — quick + route mapping + auth review + dangerous patterns ($0.50 · 45 min)
• thorough — full ASVS-mapped review + IaC + crypto + data flow tracing (unlimited)

Focus area? (default: all)

• all — full review
• auth — authentication, sessions, authorization, OAuth/OIDC (ASVS V6-V10)
• injection — encoding, sanitization, input validation, dangerous functions (ASVS V1-V2)
• crypto — cryptography, communication security, data protection (ASVS V11-V14)
• config — configuration, secrets, error handling (ASVS V13, V16)
• iac — Infrastructure as Code (Terraform, K8s, Docker)
• llm — LLM/AI integration security: prompt injection, tool abuse, output handling, RAG, MCP (OWASP LLM Top 10)

---

Phase 0 — Scope & Setup

0. Call session(action="start", options={...}) with codebase path, depth, and limits
1. Call session(action="set_codebase", options={"path": "/absolute/path"})
2. Call report(action="dashboard", data={"port": 7777}) — live findings tracker
3. Call report(action="note", data={...}) — record codebase path, expected tech stack, review focus

---

Phase 1 — Orientation (all depths)

Goal: Understand what you're looking at before analyzing it.

Step 1 — Identify the tech stack:

• Read package manifests to determine language, framework, and dependencies:
  • Python: requirements.txt, pyproject.toml, Pipfile, setup.py
  • Node.js: package.json, package-lock.json
  • Java: pom.xml, build.gradle, build.gradle.kts
  • PHP: composer.json
  • Ruby: Gemfile, Gemfile.lock
  • Go: go.mod, go.sum
  • .NET: *.csproj, *.sln
• Check for LLM/AI framework usage while reading manifests. Look for these packages:
  • Python: openai, anthropic, langchain, langchain-core, langchain-community, llama-index, haystack-ai, semantic-kernel, crewai, autogen-agentchat, mcp, pydantic-ai
  • Node.js: openai, @anthropic-ai/sdk, langchain, @langchain/core, @modelcontextprotocol/sdk, ai (Vercel AI SDK)
  • Also grep source files for: API key patterns (sk-, sk-ant-, OPENAI_API_KEY, ANTHROPIC_API_KEY), model name strings (gpt-4, gpt-3.5, claude, o1-, o3-), and LLM endpoint URLs (api.openai.com, api.anthropic.com)
  • If any LLM framework is detected: report(action="note", data={"message": "LLM_DETECTED: [frameworks list]. Phase 5b will run.")
• Call report(action="note", data={...}) with: language, framework, major dependencies, framework version

Step 1b — Baseline calibration (determine the baseline dynamically): Before hunting, decide what this application is and what comparable mainstream software exists — this calibrates effort and severity, it does NOT dismiss findings.

• Name 1–2 comparable mainstream projects of the same class (a CMS → other CMSes; an API gateway → other gateways; a novel app may have no meaningful comparable — say so).
• For each comparable, what security tradeoffs does it deliberately accept? (e.g. "admins are fully trusted", "rate limiting is the CDN's job", "tokens live in localStorage by design").
• Use this two ways: (a) if the comparable has the same pattern and it has been exploited there → that's a stronger finding, not a weaker one; (b) if the comparable has the same pattern and it's never been exploited in years of production → understand why before reporting.
• Invent target-specific attack classes the generic ASVS chapters won't name: read the domain and list 2–4 abuse cases unique to this app (e.g. for a billing app: negative-quantity refunds; for a multi-tenant SaaS: cross-tenant ID confusion; for an MCP server: tool rug-pull). These are advisory hunting leads layered ON TOP of ASVS — ASVS/STRIDE stays the backstop, never replaced.
• Guardrail: baseline calibration focuses effort, it never excuses skipping. "The comparable accepts this" is a reason to understand a pattern, never a reason to leave an exploitable finding unreported.

Call report(action="note", data={...}) with the baseline comparable(s), the tradeoffs they accept, and the target-specific attack classes you'll prioritize.

Step 2 — Map project structure:

• Use Glob to understand the directory layout (MVC? microservice? monolith?)
• Identify entry point files (e.g. app.py, manage.py, server.js, main.go, Application.java)
• Identify configuration directories (config/, settings/, .env, application.properties)

Step 3 — Read configuration files: Look for security-relevant settings. What matters depends on the framework — adapt to what you find:

• Debug mode enabled in production
• Hardcoded secrets (API keys, database passwords, JWT secrets)
• CORS configuration (overly permissive origins)
• CSP headers (missing or permissive)
• Database connection strings
• Session configuration (cookie flags, timeout)
• Allowed hosts / origins
• Email / SMTP configuration with credentials

Call report(action="finding", data={...}) for any hardcoded secrets or dangerous configurations found.

Step 4 — Dependency audit: Check whether pinned dependency versions have known CVEs. For each major dependency, consider whether it's a security-sensitive component (auth library, ORM, template engine, crypto library, XML parser).

Call report(action="diagram", data={...}) with a component architecture diagram showing the tech stack, major components, and their relationships.

---

Phase 2 — Attack Surface Mapping (standard+)

Goal: Build the complete endpoint inventory from source code — this is what black-box scanning tries to discover from the outside.

Step 1 — Extract all route definitions:

Read the routing configuration for the identified framework. Every framework defines routes differently — find the pattern and extract ALL endpoints:

• The route path (URL pattern)
• The HTTP method(s) accepted
• The handler function/controller
• Any middleware applied (auth, CSRF, rate limiting, validation)
• Parameters accepted (path params, query params, request body schema)

Step 2 — Classify each endpoint:

For every endpoint, determine:

• Is it authenticated or public?
• What authorization checks are applied?
• What input does it accept and how is that input used?
• Does it handle file uploads?
• Does it return sensitive data?

Step 3 — Identify non-HTTP attack surface:

• WebSocket endpoints
• GraphQL schemas (introspection enabled?)
• gRPC service definitions
• Background job/queue processors that handle external data
• CLI commands that accept user input
• Scheduled tasks that process external data

Call report(action="note", data={...}) with the complete endpoint inventory table. This feeds directly into /pentester and /web-exploit for targeted testing.

---

Phase 3 — Authentication & Authorization Architecture (standard+)

Goal: Understand how the application proves identity and enforces permissions. Map to ASVS V6 (Authentication), V7 (Session Management), V8 (Authorization), V9 (Self-contained Tokens), V10 (OAuth/OIDC).

Step 1 — Identify the auth mechanism:

• Find where authentication is configured (middleware, decorators, security filter chains, auth providers)
• Determine the mechanism: session-based, JWT, OAuth 2.0/OIDC, API key, certificate, or custom
• Read the implementation: how are credentials verified? how are tokens issued? how are sessions created?

Step 2 — Check password security (ASVS V6.2):

• Password hashing algorithm and configuration (bcrypt cost factor, argon2 parameters)
• Password policy enforcement (minimum length, complexity)
• Account lockout after failed attempts
• Password reset flow security (token expiry, one-time use)

Step 3 — Check session management (ASVS V7):

• Session token generation (entropy, predictability)
• Cookie configuration (Secure, HttpOnly, SameSite, Path, Domain)
• Session timeout and idle timeout
• Session invalidation on logout, password change, privilege change
• Concurrent session limits

Step 4 — Map authorization (ASVS V8):

• What model is used? (RBAC, ABAC, ACL, or none)
• Where are permission checks enforced? (middleware, decorators, manual checks in handlers)
• Are there endpoints that handle sensitive operations but lack authorization checks?
• Can users access other users' resources? (IDOR potential)
• Are admin functions properly restricted?

Step 5 — Token security (ASVS V9, V10): If JWT or OAuth is used:

• Signing algorithm (reject none, prefer RS256 over HS256 with public keys)
• Token expiry times (access token should be short-lived)
• Refresh token rotation
• Token storage (localStorage = XSS risk, httpOnly cookie = safer)
• Scope validation on resource servers
• PKCE enforcement for public clients

Call report(action="finding", data={...}) for every auth/authz weakness found. Call report(action="diagram", data={...}) with the authentication flow diagram.

---

Phase 4 — Automated Scanning (all depths, parallel)

Run both in the same response:

scan(tool="semgrep", target="/target")
scan(tool="trufflehog", target="/target")

If LLM detected in Phase 1, also run in the same parallel batch:

scan(tool="semgrep", target="/target", flags="--config p/ai-best-practices")

This runs 58 semgrep rules covering: hardcoded API keys, missing max_tokens, prompt injection taint flow, MCP command injection, LLM output passed to eval/exec, and insecure model loading.

After results come back:

• Read each semgrep finding and verify it against the actual code — false positives are common
• For each confirmed finding, call report(action="finding", data={...}) with the code context
• For trufflehog findings, verify whether secrets are real or test/example values

---

Phase 5 — Dangerous Pattern Analysis (standard+)

Goal: Find code patterns that lead to vulnerabilities. Map to ASVS V1 (Encoding/Sanitization), V2 (Validation), V3 (Web Frontend), V4 (API), V5 (File Handling).

The approach: Don't grep for a static list of function names. Instead, understand what categories of dangerous operations exist in the language/framework you're reviewing, and search for patterns that indicate unsafe usage.

Category 1 — Injection (ASVS V1.2): Search for places where user-controlled data reaches execution contexts without proper sanitization:

• SQL: raw queries with string interpolation/concatenation instead of parameterized queries
• OS commands: user input reaching shell execution functions
• Template engines: user input rendered as template code (SSTI)
• LDAP: user input in LDAP filter construction
• XPath/XML: user input in query construction
• Code evaluation: user input reaching eval/exec equivalents

For each finding, trace whether user input actually reaches the function (source-to-sink). A dangerous function with only hardcoded arguments is not a vulnerability.

Category 2 — Output encoding (ASVS V1.3, V3):

• Template auto-escaping disabled or bypassed (raw/safe/html_safe/dangerouslySetInnerHTML/{!! !!})
• HTTP response headers set from user input without encoding
• JSON responses containing unescaped user data rendered in HTML context

Category 3 — Deserialization (ASVS V1.5):

• Deserialization of untrusted data (pickle, yaml.load without SafeLoader, Java ObjectInputStream, PHP unserialize, node-serialize)
• JSON parsing with type information enabled (Jackson polymorphic, Newtonsoft TypeNameHandling)

Category 4 — Input validation (ASVS V2.2):

• Are request parameters validated (type, length, range, format)?
• Is validation server-side or only client-side?
• Are there endpoints that accept arbitrary data without schema validation?

Category 5 — File handling (ASVS V5):

• File upload: what validation is performed? (extension, MIME, magic bytes, size)
• File paths: is user input used to construct file paths? (path traversal)
• File inclusion: can user input influence which files are loaded?
• File download: can users download arbitrary files?

Category 6 — Business logic (ASVS V2.3):

• Can prices, quantities, or permissions be manipulated via request parameters?
• Are multi-step workflows enforced server-side or just client-side?
• Are there race conditions in critical operations (double-spend, TOCTOU)?
• Can users skip steps or replay requests?

Call report(action="finding", data={...}) for every confirmed dangerous pattern with the source file, line number, the dangerous code, and whether user input reaches it.

---

Phase 5b — LLM Integration Security (conditional: standard+)

Trigger: Runs when LLM frameworks were detected in Phase 1, OR when focus=llm. Skip entirely for non-LLM codebases.

Goal: Find security weaknesses specific to LLM integrations. This phase covers patterns where the LLM is the source, sink, or intermediary. Generic injection/deserialization patterns are in Phase 5 — this phase focuses on the unique attack surface that LLM integrations introduce.

Maps to: OWASP LLM Top 10 (2025), OWASP MCP Top 10.

Reference: Load skills/codebase/refs/llm-integration.md for framework-specific grep patterns, CVE table, secure agent patterns, and MCP Top 10 checks.

Category 1 — Prompt Construction (OWASP LLM01: Prompt Injection):

• Search for how prompts are built: string concatenation, f-strings, .format(), template literals with user input
• Check whether user input is inserted into system prompts, few-shot examples, or tool descriptions
• Look for RAG context injection: are retrieved documents inserted into prompts without sanitization?
• Check for indirect injection surfaces: can attacker-controlled content (emails, web pages, documents) reach the prompt via RAG or tool outputs?
• Verify whether any prompt input validation, escaping, or structural separation (e.g. XML tags, delimiters) is applied

Category 2 — Output Handling (OWASP LLM05: Insecure Output Handling):

• Search for LLM response text flowing into dangerous sinks:
  • eval(), exec(), subprocess, os.system(), child_process.exec() — code execution
  • Raw SQL queries, ORM raw methods — SQL injection from LLM output
  • innerHTML, dangerouslySetInnerHTML, template |safe — XSS from LLM output
  • Shell commands, file path construction — command injection, path traversal
• Check for code execution tools: PythonREPLTool, PALChain, LLMMathChain, custom code interpreters
• Verify whether LLM output is validated, sanitized, or sandboxed before use

Category 3 — Tool/Function Definitions (OWASP LLM06: Excessive Agency):

• Find all tool/function definitions passed to the LLM (OpenAI function calling, LangChain tools, MCP tools)
• Check each tool for:
  • Over-permissioned operations: can the tool delete data, modify configs, access other users' resources, execute arbitrary code?
  • Missing auth propagation: does the tool handler enforce the calling user's permissions, or does it run with service-level privileges?
  • Missing input validation: are tool arguments validated before use?
  • No approval gates: are destructive or sensitive operations auto-executed, or is human-in-the-loop confirmation required?
• Count total tools available to the agent — more tools = larger attack surface

Category 4 — Secrets in Prompts (OWASP LLM02/LLM07: Sensitive Information Disclosure):

• Search system prompts and prompt templates for hardcoded API keys, database credentials, internal URLs, or PII
• Check whether confidential business logic or instructions are embedded in prompts (extractable via prompt leakage)
• Look for logging of full prompts/completions that may contain user PII
• Check whether conversation history is stored unencrypted or without access controls

Category 5 — RAG & Vector Store Security (OWASP LLM08: Vector and Embedding Weaknesses):

• Find vector store/retriever configuration (Chroma, Pinecone, Weaviate, pgvector, FAISS)
• Check for tenant isolation: are per-user metadata filters applied to vector queries, or can any user retrieve any document?
• Check document ingestion pipeline: is there validation of uploaded documents? Can users upload to shared collections?
• Look for poisoning risk: can untrusted sources inject documents into the knowledge base?
• Check similarity score thresholds — are results filtered by relevance, or does everything retrieved get injected into the prompt?

Category 6 — Supply Chain & Model Loading (OWASP LLM03: Supply Chain):

• Check for unpinned LLM framework versions (known CVEs exist — see ref file for CVE table)
• Search for pickle-based model loading (torch.load, pickle.load, joblib.load on untrusted files)
• Look for model downloads without integrity verification (no hash checks, no signed models)
• Check for custom model loading from user-specified paths
• Flag known-vulnerable dependency versions against the CVE table in the ref file

Category 7 — Resource Controls (OWASP LLM10: Unbounded Consumption):

• Check for missing max_tokens / max_completion_tokens on API calls
• Look for missing timeouts on LLM API requests
• Check for unbounded agent loops — is there a max_iterations or recursion limit?
• Look for missing rate limiting on endpoints that trigger LLM calls
• Check cost controls: is there per-request or per-user spend limiting?

Category 8 — MCP Server Patterns (OWASP MCP Top 10): Only applies when the codebase implements or consumes MCP servers.

• Tool handler injection: check whether MCP tool arguments are passed to shell commands, SQL, or file paths without sanitization
• Resource exposure: are MCP resources exposing sensitive files or data without auth checks?
• Server authentication: is the MCP server accessible without authentication?
• Rug-pull potential: can MCP tool descriptions or behavior change between discovery and invocation?
• Upstream dependency trust: does the MCP client validate responses from MCP servers, or trust them blindly?

Call report(action="finding", data={...}) for each confirmed LLM-specific weakness. Use severity guidance:

• Critical: LLM output reaches eval/exec/shell without sandboxing; tool handler has command injection; prompt injection enables data exfiltration
• High: No tenant isolation in RAG; over-permissioned tools without approval gates; secrets in system prompts; pickle model loading
• Medium: Missing max_tokens; no agent iteration limits; unpinned LLM framework versions; weak prompt/response validation
• Low: Logging full prompts without PII redaction; no similarity threshold on RAG retrieval; missing rate limits on LLM endpoints

---

Phase 5c — Execution Confirmation (thorough only, opt-in)

Trigger: thorough depth, for the no-live-path findings where static "input reaches sink" is the only evidence — library code, CLI parsers, deserialization gadgets, format-string bugs, crypto misuse. Skip when a live endpoint already lets /web-exploit reproduce the issue (a live re-run is stronger evidence).

Goal: turn a static claim into a real, artifact-backed crash/exec — the same falsifiable standard the rest of the engagement enforces.

Build and run the relevant code in the hardened sandbox (capabilities dropped, pid/mem/cpu-capped, over a staged copy — the original source is never mutated; network is ON by default so dependency installs work — pass allow_network: false for strict isolation of untrusted code):

scan(tool="exec_sandbox", target="<codebase path>", options={
  "subdir": "packages/parser",                 # stage only the package under test (keep it small)
  "setup":  "pip install -e .",                # optional build/deps step
  "cmd":    "python -c \"import parser; parser.loads(open('/work/poc.bin','rb').read())\"",
  "image":  "python:3.11-slim",                # pick an image matching the stack (node:20-slim, golang:1.22, etc.)
  "timeout": 180
})

It returns an artifact_id capturing stdout/stderr + exit code. If the run proves the finding (crash, traceback, code execution, leaked data), file the finding and pass that artifact_id as the reproduction artifact — that's what lets the adjudication pass mark it reproducible: true. If it does not reproduce, the static claim is unconfirmed → downgrade or drop it.

This phase is opt-in and fail-soft. A build that can't be set up (missing private deps, multi-service compose, fixtures) returns a diagnostic, not a finding — fall back to the static source-to-sink trace. Execution confirmation is never a completion gate; a clean static trace remains acceptable evidence.

---

Phase 6 — Infrastructure, Crypto & Configuration (thorough)

Goal: Review supporting infrastructure for security weaknesses. Map to ASVS V11-V14, V16.

Cryptography (ASVS V11):

• What algorithms are used for hashing, encryption, signing?
• Are deprecated algorithms used? (MD5, SHA1 for security purposes, DES, RC4)
• How are encryption keys managed? (hardcoded, environment variable, KMS)
• Is random number generation cryptographically secure?

Secure communication (ASVS V12):

• Is TLS enforced for all external communication?
• Are certificate validations disabled anywhere? (verify=False, InsecureSkipVerify)
• Are internal service-to-service calls encrypted?

Configuration (ASVS V13):

• Are secrets in environment variables, secret managers, or hardcoded?
• Is debug mode disabled in production configuration?
• Are default credentials or test accounts present?
• Are unnecessary features, endpoints, or services enabled?

Data protection (ASVS V14):

• Is sensitive data encrypted at rest?
• Is PII properly handled (minimization, masking, access controls)?
• Are sensitive fields excluded from logs?
• Is data classified and handled according to its sensitivity?

Error handling and logging (ASVS V16):

• Do error responses leak stack traces, internal paths, or configuration?
• Are security events logged? (authentication failures, authorization denials, input validation failures)
• Is there log injection risk? (user input in log messages without sanitization)
• Are sensitive values excluded from logs? (passwords, tokens, credit card numbers)

Infrastructure as Code: If IaC files are present (Terraform, CloudFormation, K8s manifests, Dockerfiles, docker-compose), review them for:

• Overly permissive IAM policies or security groups
• Public storage buckets or databases
• Containers running as root or with excessive capabilities
• Missing encryption, logging, or monitoring
• Hardcoded secrets in manifests
• Unpinned base images

Call report(action="finding", data={...}) for each confirmed weakness.

---

Phase 7 — Security Profile & Report (all depths)

Step 1 — Architecture diagram: Call report(action="diagram", data={...}) with a comprehensive Mermaid diagram showing:

• All components (web server, app server, database, cache, queue, external APIs)
• Trust boundaries (public internet, DMZ, internal network)
• Data flows with sensitivity labels
• Authentication/authorization enforcement points
• Identified vulnerabilities annotated on the diagram

Step 2 — Codebase security profile: Call report(action="note", data={...}) with a structured summary that downstream skills can consume:

Codebase Security Profile:
  Language:        [language] [version]
  Framework:       [framework] [version]
  Architecture:    [monolith/microservice/serverless]

  Endpoints:       [count] total ([count] public, [count] authenticated)
  Auth mechanism:  [session/JWT/OAuth/API key]
  Auth library:    [library name and version]
  Authorization:   [RBAC/ABAC/ACL/none]
  Password hashing: [algorithm and parameters]

  Findings:        [count] by severity (critical: N, high: N, medium: N, low: N)
  Secrets found:   [count] (verified: N)
  ASVS coverage:   V1:[status] V2:[status] ... V16:[status]

  LLM Integration: [yes/no]
    Frameworks:    [openai, langchain, etc.]
    LLM endpoints: [count] (endpoints that trigger LLM calls)
    Tools defined: [count] (function/tool definitions passed to LLM)
    RAG:           [yes/no] ([vector store name])
    MCP:           [server/client/none]
    OWASP LLM Top 10 white-box coverage:
      LLM01 Prompt Injection:           [REVIEWED/NOT APPLICABLE]
      LLM02 Sensitive Info Disclosure:   [REVIEWED/NOT APPLICABLE]
      LLM03 Supply Chain:               [REVIEWED/NOT APPLICABLE]
      LLM05 Insecure Output Handling:   [REVIEWED/NOT APPLICABLE]
      LLM06 Excessive Agency:           [REVIEWED/NOT APPLICABLE]
      LLM07 System Prompt Leakage:      [REVIEWED/NOT APPLICABLE]
      LLM08 Vector/Embedding Weakness:  [REVIEWED/NOT APPLICABLE]
      LLM10 Unbounded Consumption:      [REVIEWED/NOT APPLICABLE]

  Priority targets for pentesting:
    - [endpoint] — [reason: missing auth, SQLi, file upload, etc.]
    - [endpoint] — [reason]

  Priority targets for AI red-team (/ai-redteam):
    - [endpoint URL] — [reason: extractable system prompt, over-permissioned tools, no input validation]
    - [extracted system prompt text or location]
    - [tool definitions and guardrail mechanisms found in source]

  IaC issues:      [count] ([Terraform/K8s/Docker])

Step 3 — ASVS coverage summary (thorough only): Call report(action="note", data={...}) with which ASVS chapters were reviewed and what was found:

ASVS 5.0 Coverage:
  V1  Encoding/Sanitization:    REVIEWED — [findings or "no issues"]
  V2  Validation/Business Logic: REVIEWED — [findings or "no issues"]
  V3  Web Frontend Security:    REVIEWED — [findings or "no issues"]
  V4  API and Web Service:      REVIEWED — [findings or "no issues"]
  V5  File Handling:            REVIEWED — [findings or "no issues"]
  V6  Authentication:           REVIEWED — [findings or "no issues"]
  V7  Session Management:       REVIEWED — [findings or "no issues"]
  V8  Authorization:            REVIEWED — [findings or "no issues"]
  V9  Self-contained Tokens:    [REVIEWED | NOT APPLICABLE]
  V10 OAuth and OIDC:           [REVIEWED | NOT APPLICABLE]
  V11 Cryptography:             REVIEWED — [findings or "no issues"]
  V12 Secure Communication:     REVIEWED — [findings or "no issues"]
  V13 Configuration:            REVIEWED — [findings or "no issues"]
  V14 Data Protection:          REVIEWED — [findings or "no issues"]
  V15 Secure Coding/Arch:       REVIEWED — [findings or "no issues"]
  V16 Logging/Error Handling:   REVIEWED — [findings or "no issues"]

Step 4: Call session(action="complete", options={...}) with summary.

Step 5: Chain into downstream skills — see CHAIN COMMITMENTS section at the top for mandatory chains. Summary:

• MUST → /threat-modeling (always — real architecture from code)
• MUST if live target available → /web-exploit (do NOT skip because code review found no injection points — systematic live testing finds what static analysis misses)
• MUST if LLM/AI integration detected → /ai-redteam (pass system prompts, tool definitions, guardrail config, RAG architecture as white-box context)
• If API routes/controllers found → /api-security (OWASP API Top 10 with white-box context)
• If IaC found → /cloud-security or /container-k8s-security
• If CVE-affected dependencies found → /analyze-cve

---

Chaining Other Skills

Skill	When to invoke
/threat-modeling	Always after review — feed real architecture into STRIDE analysis
/pentester	Endpoints discovered — target scan with white-box knowledge
/web-exploit	MANDATORY if live target available — do NOT wait for injection points to be found in source; systematic live testing finds what static analysis misses
/api-security	API routes/controllers identified in source (REST/GraphQL/gRPC/SOAP/MCP) — pass route inventory, auth middleware, ORM models, and authorization decorators as white-box context for OWASP API Top 10 testing
/cloud-security	IaC files found — verify cloud misconfigs match runtime state
/container-k8s-security	K8s manifests or Dockerfiles found — verify container security
/analyze-cve	CVE-affected dependency found — trace code path with full source context
/credential-audit	Auth mechanism identified — test with knowledge of password policy and lockout config
/ai-redteam	LLM integration detected — pass system prompts, tool definitions, guardrails, RAG architecture, and endpoint URLs as white-box context
/remediate	Findings produced — generate specific code fixes with full source context
/gh-export	When user asks to file GitHub issues

---

Reporting findings — structure & the severity bar

Attach a source trace[] to every white-box finding. Because a codebase is pinned (set_codebase), the server RESOLVES each cited file:line against the repo and rejects a finding whose trace points at a file or line that does not exist — this catches a hallucinated citation before it ever reaches the report. Build the trace from the source-to-sink data flow you already traced in Phase 5:

report(action="finding", data={
  "title": "SQL injection in order lookup",
  "severity": "high", "target": "/path/to/repo",
  "description": "...", "evidence": "...",
  "trace": [
    {"kind": "entrypoint",   "file": "api/orders.py",  "line": 42, "scope": "get_order",      "description": "order_id taken from query string, unvalidated"},
    {"kind": "propagation",  "file": "db/query.py",    "line": 88, "scope": "build_filter",   "description": "order_id concatenated into SQL string"},
    {"kind": "sink",         "file": "db/query.py",    "line": 91, "scope": "execute_raw",    "description": "raw query executed against the DB"}
  ]
})

Rules for trace: first step kind:"entrypoint", last kind:"sink", ≥2 steps; line a positive integer that exists in the cited file; scope the bare function/method name. Cite the real lines you read — don't approximate. (Black-box findings with no source omit trace entirely.)

The severity bar (one canonical doctrine — the server applies the same rubric at adjudication):

• Only report what you can exploit. A concrete attack + observed result, never "an attacker could theoretically…".
• Severity = likelihood × impact, not deviation from an ASVS checklist. ASVS is a guide to where to look, not a bug list.
• Defense-in-depth gaps are LOW hardening notes, never high/critical. If an existing layer already prevents the attack, the absence of another layer is a hardening note — record it as LOW, don't inflate it.
• Don't pad with LOWs to look thorough; an honest "no exploitable issue here" is a valid result.

Finding Severity Guide

Severity	Criteria	Examples
Critical	Direct path to RCE, data breach, or auth bypass from source	Unsanitized user input in eval/exec; hardcoded admin credentials; SQL injection in auth query; deserialization of untrusted data
High	Significant security weakness exploitable with moderate effort	Missing auth on sensitive endpoints; IDOR in API; weak password hashing; disabled CSRF protection; path traversal in file operations
Medium	Security weakness requiring specific conditions to exploit	Missing rate limiting; verbose error messages; weak session timeout; permissive CORS; missing security headers
Low	Defense-in-depth gap or best practice deviation	Debug mode in non-production config; missing CSP header; unpinned dependencies; logging without sensitive data redaction

---

Rules

• session(action="start", options={...}) is mandatory — never run any other tool before it
• Read before you judge — don't report a finding just because a function name appears. Verify that user input actually reaches it
• Source-to-sink tracing is essential — a dangerous function with hardcoded arguments is not a vulnerability. Trace the data flow
• Adapt to the framework — every framework has different patterns. Don't grep for Django patterns in a Flask app
• Call report(action="finding", data={...}) for every confirmed weakness — include the file path, line number, vulnerable code snippet, and why it's exploitable
• Call report(action="diagram", data={...}) at least twice — after Phase 1 (initial architecture) and Phase 7 (annotated with findings)
• The security profile feeds downstream skills — write it clearly in report(action="note", data={...}) so other skills can parse and act on it
• Use report(action="note", data={...}) liberally — document your understanding of each component before analyzing it
• Never fabricate findings — only report what the code actually shows
• Attach a trace[] to every white-box finding (entrypoint→…→sink with real file:line:scope) — the server resolves the citations against the codebase and rejects a hallucinated location, so cite lines you actually read
• Severity = likelihood × impact — a defense-in-depth gap behind an existing control is a LOW hardening note, never high/critical (the adjudication pass applies this same rubric)
• ASVS is a guide, not a checklist — focus on high-risk areas first, not sequential chapter review
• Mermaid syntax rules: use flowchart TD, quote labels with spaces/special chars, no em-dashes, short alphanumeric node IDs

Learned preferences & procedures

This block is maintained by SkillOpt-Sleep. Edits here are proposed offline, validated against past tasks, and adopted only after review. Hand-edits outside this block are never touched.

• Confidence rating (required per finding) — every finding MUST include an explicit **Confidence:** label immediately after its severity, set to high, medium, or low by trace completeness: high = full source-to-sink trace confirmed with real file:line; medium = partial trace, likely but not fully verified; low = pattern-only, no complete trace.