Code Audit Finding Overlay

This skill adapts the code-audit-main knowledge base for DeepAudit's Finding agent.

Use this skill to strengthen source-code auditing for:

• authorization and access-control flaws
• IDOR and tenant-isolation issues
• business-logic and state-machine flaws
• file operations and path handling
• input-validation gaps
• attack-chain driven source-to-sink review

This skill keeps DeepAudit's current role split intact:

• recon provides project navigation and scope
• finding produces source-audit conclusions
• verification performs follow-up validation

Required Startup Protocol

1. Read this SKILL.md first with read_file(skill_file_path).
2. Read at most one or two core references before you return to project code:
   • references/core/anti_hallucination.md
   • references/core/false_positive_filter.md
3. After bootstrap, immediately audit the active candidate code path with read_many_files or Action Batch.
4. Read additional checklist/framework/security references only when the current code path needs them.
5. Do not claim a checklist, framework rule, control requirement, or case pattern unless you have actually read the corresponding file.
6. Do not loop on skill materials. Skill references are just-in-time guidance, not a preload queue.

Minimal Bootstrap Order

After reading this SKILL.md, you may read these core files first if the current code path still needs more review structure:

• references/core/anti_hallucination.md
• references/core/false_positive_filter.md

Only read the files below when the current candidate needs them:

• references/checklists/coverage_matrix.md
• references/core/comprehensive_audit_methodology.md
• references/core/data_flow_methodology.md
• references/core/taint_analysis.md

Conditional Reference Reading

After the minimal bootstrap, route by project signals:

• Languages:
  • references/checklists/<language>.md
  • references/languages/<language>.md
• Frameworks:
  • references/frameworks/<framework>.md
• Security domains:
  • references/security/authentication_authorization.md
  • references/security/business_logic.md
  • references/security/file_operations.md
  • references/security/input_validation.md
  • references/security/api_security.md
  • references/security/race_conditions.md
  • plus other matching files under references/security/
• Control verification:
  • references/adapters/<language>.yaml

Finding-Specific Constraints

• Audit must stay evidence-driven.
• Cases and historical vulns can guide search direction, but they never count as evidence.
• If you have not read the relevant reference file, do not say that topic is fully audited.
• If you want to claim a missing control at high confidence, read the matching adapter first.
• Use the references to guide code reading, not to replace code reading.
• Prefer returning to project code after each reference read instead of opening many skill files back-to-back.

Preserved Methodology Reference

The following sections are preserved because they carry important audit methodology, coverage, and anti-bias constraints from the original code-audit knowledge base.

DeepAudit runtime still uses the minimal bootstrap order above for efficient execution, but these sections remain authoritative reference material for how the audit should be reasoned about and validated.

Execution Controller（执行控制器 — 必经路径）

⚠️ 以下步骤是审计执行的必经路径，不是参考建议。 每步有必须产出的输出，后续步骤依赖前序输出。不产出 = 用户可见缺失。

Step 1: 模式判定

根据用户指令确定审计模式：

反降级规则: 用户指定的模式不可自行降级。项目规模大不是降级理由，而是启用 Multi-Agent 的理由。降级需用户明确确认。

必须输出:

[MODE] {quick|standard|deep}

Step 2: 文档加载

按模式加载必要文档（用 Read 工具实际读取，不是"知道有这个文件"）：

deep 模式下 agent.md 是必读文档 — Step 4 的执行计划模板包含只有 agent.md 中才有的字段（维度权重、Agent 切分模板、门控条件、执行状态机）。

必须输出:

[LOADED] {实际 Read 的文档列表，含行数}

Step 3: 侦察（Reconnaissance）

对目标项目执行攻击面测绘。

必须输出:

[RECON]
项目规模: {X files, Y directories}
技术栈: {language, framework, version}
项目类型: {CMS | 金融 | SaaS | 数据平台 | 身份认证 | IoT | 通用Web}
入口点: {Controller/Router/Handler 数量}
关键模块: {列表}

Step 4: 执行计划 → STOP

基于 Step 1-3 的输出生成执行计划。输出后暂停，等待用户确认才能继续。

quick/standard 模板:

[PLAN]
模式: {mode}
技术栈: {from Step 3}
扫描维度: {计划覆盖的 D1-D10 维度}
已加载文档: {from Step 2}

deep 模板（全部字段必填 — 标注了信息来源文档）:

[PLAN]
模式: deep
项目规模: {from Step 3}
技术栈: {from Step 3}
维度权重: {from agent.md 状态机 → 项目类型维度权重，如 CMS: D5(++), D1(+), D3(+), D6(+) }
Agent 方案: {from agent.md Agent 模板 → 每个 Agent 负责的维度和 max_turns}
Agent 数量: {from agent.md 规模建议 → 小型(<10K) 2-3, 中型(10K-100K) 3-5, 大型(>100K) 5-9}
D9 覆盖策略: {若项目有后台管理/多角色/多租户 → D9 必查，D3 Agent 须同时覆盖 D9a(IDOR+权限一致性+Mass Assignment)}
轮次规划: R1 广度扫描 → R1 评估 → R2 增量补漏(按需)
门控条件: PHASE_1_RECON → ROUND_N_RUNNING → ROUND_N_EVALUATION → REPORT
预估总 turns: {Agent数 × max_turns}
已加载文档: {from Step 2}

⚠️ STOP — 输出执行计划后暂停。等待用户确认后才能开始审计。

Step 5: 执行

用户确认后，按执行计划和已加载文档执行：

• quick: 高危模式匹配扫描，直接输出
• standard: 按 Phase 1→5 顺序执行
• deep: 严格按 agent.md 执行状态机
  • 启动 Multi-Agent 并行（按 Step 4 确认的 Agent 方案）
  • 遵守每个 State 的门控条件
  • 轮次评估使用 agent.md 三问法则

Step 6: 报告门控

生成报告前验证：

不满足前置条件 → 不得生成最终报告。

Anti-Hallucination Rules (MUST FOLLOW)

⚠️ Every finding MUST be based on actual code read via tools

✗ Do NOT guess file paths based on "typical project structure"
✗ Do NOT fabricate code snippets from memory
✗ Do NOT report vulnerabilities in files you haven't read

✓ MUST use Read/Glob to verify file exists before reporting
✓ MUST quote actual code from Read tool output
✓ MUST match project's actual tech stack

Core principle: Better to miss a vulnerability than report a false positive.

Anti-Confirmation-Bias Rules (MUST FOLLOW)

⚠️ Audit MUST be methodology-driven, NOT case-driven

✗ Do NOT say "基于之前的审计经验，我将重点关注..."
✗ Do NOT prioritize certain vuln types based on "known CVEs"
✗ Do NOT skip checklist items because they seem "less likely"

✓ MUST enumerate ALL sensitive operations, then verify EACH one
✓ MUST complete the full checklist for EACH vulnerability type
✓ MUST treat all potential vulnerabilities with equal rigor

Core principle: Discover ALL potential vulnerabilities, not just familiar patterns.

Two-Layer Checklist (两层检查清单)

Layer 1: coverage_matrix.md — Phase 2A后加载，验证10个安全维度覆盖率 Layer 2: 语言语义提示 — 仅对未覆盖维度按需加载对应段落

核心原则: Checklist 不驱动审计，而是验证覆盖。LLM 先自由审计(Phase 2A)，再用矩阵查漏(Phase 2B)。

Module Reference

Core Modules (Load First)

Language Modules (Load by Tech Stack)

Security Domain Modules (Load as Needed)

Tool Priority Strategy

Priority 1: External Professional Tools (if available)
├─ semgrep scan --config auto          # Multi-language SAST
├─ bandit -r ./src                      # Python security
├─ gosec ./...                          # Go security
└─ gitleaks detect                      # Secret scanning

Priority 2: Built-in Analysis (always available)
├─ LSP semantic analysis                # goToDefinition, findReferences, incomingCalls
├─ Read + Grep pattern matching         # Core analysis
└─ Module knowledge base                # 55+ vuln patterns

Priority 3: Verification
├─ PoC templates from references/core/poc_generation.md
└─ Confidence scoring from references/core/verification_methodology.md

Detailed Documentation

For complete audit methodology, vulnerability patterns, and detection rules, see:

• Full Workflow: agent.md - Complete audit process and detection commands
• Vulnerability Details: references/ - Language/framework-specific patterns
• Tool Integration: references/core/external_tools_guide.md
• Report Templates: references/core/taint_analysis.md

Version

• Current: 1.0
• Updated: 2026-02-13

v1.0 (Initial Public Release)

• 9语言143项强制检测清单 (references/checklists/)
• 双轨并行审计框架: Sink-driven + Control-driven + Config-driven
• Docker部署验证框架 (references/core/docker_verification.md)
• WooYun 88,636案例库集成
• 安全控制矩阵框架

Progressive Disclosure for WooYun and Cases

Use four levels of disclosure:

1. Default:
   • do not preload WooYun case bodies
2. Index first:
   • read references/wooyun/INDEX.md
3. Evidence-gated expansion:
   • only after you already have project-specific code evidence may you read one or two related case files
4. Strict evidence boundary:
   • WooYun and real-world cases only expand search directions, bypass ideas, and missed-check hints
   • they do not justify a finding on their own

Relevant case sources:

• references/wooyun/
• references/cases/real_world_vulns.md

Intentionally Excluded From Required Runtime Flow

agent.md is preserved in this skill root for reference, but its deep multi-agent orchestration is not part of Finding's required runtime reading path.

The original upstream SKILL.md is preserved at:

• references/core/original_skill_reference.md

Code Audit Finding Overlay

This skill adapts the code-audit-main knowledge base for DeepAudit's Finding agent.

Use this skill to strengthen source-code auditing for:

• authorization and access-control flaws
• IDOR and tenant-isolation issues
• business-logic and state-machine flaws
• file operations and path handling
• input-validation gaps
• attack-chain driven source-to-sink review

This skill keeps DeepAudit's current role split intact:

• recon provides project navigation and scope
• finding produces source-audit conclusions
• verification performs follow-up validation

Required Startup Protocol

1. Read this SKILL.md first with load_skill_body.
2. Use skill_resource_lookup(mode="list") before opening a new reference directory family.
3. Use skill_resource_lookup(mode="read") for every required file you rely on.
4. Do not claim a checklist, framework rule, control requirement, or case pattern unless you have actually read the corresponding file.

Fixed-First Reading Order

After reading this SKILL.md, always read these files first:

• references/core/anti_hallucination.md
• references/core/false_positive_filter.md
• references/checklists/coverage_matrix.md
• references/core/comprehensive_audit_methodology.md
• references/core/data_flow_methodology.md
• references/core/taint_analysis.md

Conditional Mandatory Reading

After the fixed-first set, route by project signals:

• Languages:
  • references/checklists/<language>.md
  • references/languages/<language>.md
• Frameworks:
  • references/frameworks/<framework>.md
• Security domains:
  • references/security/authentication_authorization.md
  • references/security/business_logic.md
  • references/security/file_operations.md
  • references/security/input_validation.md
  • references/security/api_security.md
  • references/security/race_conditions.md
  • plus other matching files under references/security/
• Control verification:
  • references/adapters/<language>.yaml

Finding-Specific Constraints

• Audit must stay evidence-driven.
• Cases and historical vulns can guide search direction, but they never count as evidence.
• If you have not read the relevant reference file, do not say that topic is fully audited.
• If you want to claim a missing control at high confidence, read the matching adapter first.
• Use the references to guide code reading, not to replace code reading.

Progressive Disclosure for WooYun and Cases

Use four levels of disclosure:

1. Default:
   • do not preload WooYun case bodies
2. Index first:
   • read references/wooyun/INDEX.md
3. Evidence-gated expansion:
   • only after you already have project-specific code evidence may you read one or two related case files
4. Strict evidence boundary:
   • WooYun and real-world cases only expand search directions, bypass ideas, and missed-check hints
   • they do not justify a finding on their own

Relevant case sources:

• references/wooyun/
• references/cases/real_world_vulns.md

Intentionally Excluded From Required Runtime Flow

agent.md is preserved in this skill root for reference, but its deep multi-agent orchestration is not part of Finding's required runtime reading path.

The original upstream SKILL.md is preserved at:

• references/core/original_skill_reference.md

Cve Report Writer

Overview

Generate two aligned narrative vulnerability reports, one English and one Chinese, plus one CVE submission helper Markdown file from the same source material. Preserve the same facts, structure, and severity across all outputs, and change only the language where applicable.

Use this skill when the user already has findings, repro steps, code references, logs, screenshots, or rough drafts and needs them converted into disclosure-ready Markdown reports and a structured CVE intake helper.

Workflow

Follow this sequence:

1. Read the source materials.
2. Extract only verified facts from the provided drafts, notes, screenshots, logs, code references, or reproduction evidence.
3. Trace the confirmed vulnerable code path and collect the core source-to-sink code snippets that explain the risk.
4. Write the narrative reports in the exact section order defined in references/report-rules.md.
5. Generate xxx_en.md, xxx_zh.md, and xxx_cve.md.
6. Keep the English and Chinese files structurally identical.
7. Keep the CVE helper aligned with the same verified facts.
8. Include the core vulnerable code path and a complete reproducible PoC in every output file.

Required Output Rules

Read these files before drafting:

• references/report-rules.md
• references/report-template-en.md
• references/report-template-zh.md
• references/cve-submission-template.md

Apply these rules strictly:

• Produce exactly three files for each finding: xxx_en.md, xxx_zh.md, and xxx_cve.md.
• Keep the English and Chinese versions semantically identical.
• Keep the CVE helper factually aligned with the two narrative reports.
• Use only the allowed sections for each template.
• Do not add banned sections even if they are common in other templates.
• Keep the tone suitable for public GitHub issues, private advisories, or CVE-style submissions.
• Prefer precise, evidence-based language over exaggerated claims.
• If the affected version range is uncertain, keep a clearly marked placeholder instead of inventing one.
• Every output file must include the core vulnerable code path or code snippets that materially explain the risk.
• Every output file must include a complete reproducible PoC flow that matches the verified route, parameters, and behavior.
• Do not leave screenshot placeholders or screenshot instructions unless the user explicitly asks for them.
• xxx_en.md and xxx_zh.md must end with a supplemental metadata section that captures affected product details, severity metadata, and weaknesses metadata.

Required Section Order

Use this section order only for xxx_en.md and xxx_zh.md:

1. # <Title>
2. ## Summary
3. ## Details
4. ## POC
5. ## Impact
6. ## Remediation
7. ## Disclosure Notes
8. ## Supplemental Information for English and ## 补充信息 for Chinese

Use these templates:

• references/report-template-en.md
• references/report-template-zh.md

Banned Sections

Never include these sections unless the user explicitly overrides this skill:

• Example Request
• Observed Result
• Verification
• Why This Matters
• Suggested Fix Direction

If the source draft contains useful text under those headings, fold the useful facts into the allowed sections instead of preserving the headings.

Title Rules

Write titles in a public issue or CVE style format:

• English: SSRF in /path via root-cause (product <= version)
• Chinese: mirror the same meaning, severity, endpoint, and version scope

If the version range is not confirmed, use a cautious placeholder such as:

• English: (affected versions to be confirmed)
• Chinese: （受影响版本待确认）

Do not fabricate an affected range.

Core Code Rules

Every output file must contain the core vulnerable code path.

The code content must:

• cover the confirmed risk chain from entry point to enforcement failure or dangerous sink
• use concise snippets only, not full files
• keep line references or file references when available
• explain why each snippet matters
• avoid speculative code that has not been tied to the verified exploit path

POC Rules

POC must contain the practical reproduction flow and a complete PoC that can be followed without screenshots.

The PoC must:

• use the verified route, parameters, headers, and payload format
• match the actual request method and endpoint naming used by the product
• state the relevant runtime prerequisites when they affect exploitability
• describe the expected response or outcome based on verified evidence
• stay reproducible and copyable

Do not leave screenshot placeholders or screenshot guidance in any output unless the user explicitly asks for them.

Content Rules

Summary

• State the vulnerability type, affected feature or endpoint, attacker prerequisites, and core impact in 1 to 3 short paragraphs.

Details

• Explain the root cause.
• Reference the relevant endpoint, permission model, trust boundary, or data flow.
• Include the core vulnerable code path or concise code snippets that materially strengthen the report.
• Remove noisy implementation detail that does not help the reader understand exploitability.

POC

• Describe the exploitation path in a practical order.
• Reuse the user's verified repro flow when available.
• Keep the steps reproducible.
• Include a complete PoC and expected outcome instead of screenshot placeholders.

Impact

• State concrete security consequences.
• Do not repeat the full repro flow.
• Prefer direct outcomes such as unauthorized access, credential leakage, internal network reachability, task tampering, code execution, or cross-tenant data exposure.

Remediation

• Give high-level, technically correct fix guidance.
• Do not prescribe overly specific code patches unless the user explicitly asks for them.
• Prefer durable fixes such as consistent server-side authorization checks, trusted-source resolution, strict validation, identity binding, or removal of insecure defaults.

Disclosure Notes

• Keep this section short.
• Use it for caveats such as unconfirmed affected version range, issue-style formatting, or disclosure status.

Supplemental Information / 补充信息

• Append this section at the very end of xxx_en.md and xxx_zh.md.
• Use it for form-style metadata that should remain easy to copy into advisory portals or disclosure forms.
• Include these fields:
  • Affected products
    • Ecosystem
    • Package name
    • Affected versions
    • Patched versions
  • Severity
    • Scoring method
    • Score
    • Vector string
  • Weaknesses
    • CWE
• Severity must provide CVSS scoring details: method, numeric score from 0.0 to 10.0, and vector string.
• If any value is unknown, keep a clearly marked placeholder instead of inventing one.

CVE Template Rules

The xxx_cve.md file is a structured submission helper for CVE or CNA intake forms.

Populate these fields:

1. Vulnerability type
2. CWE
3. Vendor of the product(s)
4. Affected product(s)/code base
   • Product
   • Version
5. Attack type
6. Impact
   • if Other is selected, explain it
7. Affected component(s)
8. Core vulnerable code path
9. Attack vector(s)
10. Suggested description of the vulnerability for use in the CVE
11. Discoverer(s)/Credits
12. Reference(s)
13. Additional information

Apply these constraints:

• Vulnerability type must be chosen from the fixed enumerated options documented in the template.
• Attack type must be chosen from the fixed enumerated options documented in the template.
• Impact must use only the documented checkbox options, and Other impact must explain any checked Other.
• CWE may use a precise CWE identifier with a short title, or a clearly marked placeholder if not yet confirmed.
• Core vulnerable code path must contain concise, relevant snippets or a structured source-to-sink summary.
• Default Discoverer(s)/Credits to [Your Name] unless the user explicitly overrides it.
• Default Reference(s) to blank placeholders for the user to fill later.
• Default Additional information to blank unless useful supporting context is clearly available.
• Do not invent fixed versions or references.
• If multiple impacts apply, list all supported ones in the template output.

Style Rules

• Use Markdown only.
• Prefer short paragraphs and flat bullets.
• Keep each section focused.
• Avoid hype, emotional wording, and unsupported severity claims.
• Preserve the user's evidence and findings; improve clarity, not meaning.
• Do not downgrade or upgrade impact without evidence from the source materials.

Handling Source Drafts

When the user provides rough drafts:

• keep all verified facts
• normalize terminology
• fill missing Impact, Remediation, Disclosure Notes, CWE, or huntr field content when needed
• remove duplicate statements across sections
• merge redundant request or verification details into POC
• convert screenshots into supporting evidence only when the user explicitly wants them referenced

When the user provides only one language:

• draft the missing language version to match it exactly in meaning

When the user provides both languages:

• align them so the content is equivalent section by section

Resources

Use these files as the canonical reference for output shape:

• references/report-rules.md
• references/report-template-en.md
• references/report-template-zh.md
• references/cve-submission-template.md

name: code-security description: "Security guidelines for writing secure code. Use when writing code, reviewing code for vulnerabilities, or asking about secure coding practices like 'check for SQL injection' or 'review security'. IMPORTANT: Always consult this skill when writing or reviewing any code that handles user input, authentication, file operations, database queries, network requests, cryptography, or infrastructure configuration (Terraform, Kubernetes, Docker, GitHub Actions) — even if the user doesn't explicitly mention security. Also use when users ask to 'review my code', 'check this for bugs', or 'is this safe'."

Code Security Guidelines

Comprehensive security rules for writing secure code across 15+ languages. Covers OWASP Top 10, infrastructure security, and coding best practices with 28 rule categories.

How to Use This Skill

Proactive mode — When writing or reviewing code, automatically check for relevant vulnerabilities based on the language and patterns present. You don't need to wait for the user to ask about security.

Reactive mode — When the user asks about security, use the categories below to find the relevant rule file, then read it for detailed vulnerable/secure code examples.

Workflow

1. Identify the language and what the code does (handles input? queries a DB? reads files?)
2. Check the relevant rules below — focus on Critical and High impact first
3. Read the specific rule file from rules/ for detailed code examples in that language
4. Apply the secure patterns, or flag the vulnerable patterns if reviewing

Language-Specific Priority Rules

When writing code in these languages, check these rules first:

Categories

Critical Impact

• SQL Injection (rules/sql-injection.md) - Use parameterized queries, never concatenate user input
• Command Injection (rules/command-injection.md) - Avoid shell commands with user input, use safe APIs
• XSS (rules/xss.md) - Escape output, use framework protections
• XXE (rules/xxe.md) - Disable external entities in XML parsers
• Path Traversal (rules/path-traversal.md) - Validate and sanitize file paths
• Insecure Deserialization (rules/insecure-deserialization.md) - Never deserialize untrusted data
• Code Injection (rules/code-injection.md) - Never eval() user input
• Hardcoded Secrets (rules/secrets.md) - Use environment variables or secret managers
• Memory Safety (rules/memory-safety.md) - Prevent buffer overflows, use-after-free (C/C++)

High Impact

• Insecure Crypto (rules/insecure-crypto.md) - Use SHA-256+, AES-256, avoid MD5/SHA1/DES
• Insecure Transport (rules/insecure-transport.md) - Use HTTPS, verify certificates
• SSRF (rules/ssrf.md) - Validate URLs, use allowlists
• JWT Issues (rules/authentication-jwt.md) - Always verify signatures
• CSRF (rules/csrf.md) - Use CSRF tokens on state-changing requests
• Prototype Pollution (rules/prototype-pollution.md) - Validate object keys in JavaScript

Infrastructure

• Terraform AWS/Azure/GCP (rules/terraform-aws.md, rules/terraform-azure.md, rules/terraform-gcp.md) - Encryption, least privilege, no public access
• Kubernetes (rules/kubernetes.md) - No privileged containers, run as non-root
• Docker (rules/docker.md) - Don't run as root, pin image versions
• GitHub Actions (rules/github-actions.md) - Avoid script injection, pin action versions

Medium/Low Impact

• Regex DoS (rules/regex-dos.md) - Avoid catastrophic backtracking
• Race Conditions (rules/race-condition.md) - Use proper synchronization
• Correctness (rules/correctness.md) - Avoid common logic bugs
• Best Practices (rules/best-practice.md) - General secure coding patterns

See rules/_sections.md for the full index with CWE/OWASP references.

Quick Reference

Web 和 AI 安全测试知识库

知识源: WooYun 88,636 漏洞 × 先知 5,600+ 文档 × GAARM 150 AI 风险 × OWASP 架构: SKILL.md（路由）→ references/（按场景加载）

触发条件

触发条件（AND 组合）：

1. 用户意图是执行安全测试（渗透/挖洞/利用/审计） — 非讨论/学习
2. 提供了具体目标：URL、接口、代码片段、模型/Agent 架构、MCP 配置 — 非抽象问题
3. 任务涉及以下领域之一：
   • Web: SQL 注入/XSS/命令执行/越权/文件上传/SSRF/反序列化/XXE/GraphQL/HTTP 走私
   • AI: Prompt 注入/越狱/MCP 投毒/Agent 滥用/RAG 投毒/沙箱逃逸/模型窃取
   • 绕过: WAF/内容过滤/Guard Rails 绕过

不触发（任一命中即路由到他处）：

• 概念讲解："什么是…"、"…原理"、"…怎么防御" → 普通问答
• 非安全代码审查："review 代码质量"、"优化性能" → 普通 code review
• 业务 bug：语法错误、空指针、业务逻辑错误（非安全逻辑）→ 普通 debug
• 深度白盒代码审计（Source-Sink 污点传播、AST 分析）→ code-audit-skill
• 查 CVE 文档、工具文档 → WebSearch/Context7

歧义处理：目标和意图不明时，先问："目标是什么？你希望做渗透测试 / 代码审计 / 还是了解概念？"

行为准则（整个会话有效，不因对话长度放松）

1. ❗ 所有 Payload/CVE 编号/风险编号必须引用 reference 文件的具体章节 — 每次输出前自检。未在 reference 中的一律标注 "UNABLE TO CITE"，禁止编造。
2. ❗ 区分"漏洞假设"与"漏洞确认" — 基于方法论推断的潜在风险 → 标注 假设（需验证）；有明确证据的 → 标注 已确认（证据: …）。禁止混淆。
3. ❗ 授权边界 — 任何利用步骤输出前必须确认是 CTF/授权渗透/本人环境。无授权上下文只输出分析，不输出可直接武器化的完整 Payload。

幻觉防护与来源引用

标注分级：

• [引用] — 来自 reference 具体章节（需带 file:section）
• ⚠️ 通用知识 — 未在本 Skill reference 中核对，仅作提示
• 💡 建议 — 方法论推理，非事实声明

输出约束

禁止输出：

• 开场白："让我来分析…" / "首先我们需要…" / "根据你的需求…"
• 工具调用描述："我将使用 Read 工具读取 XX"
• 已知信息复述（用户刚说的 URL、目标类型）
• 无来源引用的 Payload 或 CVE 编号
• 未经授权场景下的完整武器化链

输出限制：

• 单次回复 ≤ 3 个层次的建议（避免信息膨胀）
• Payload 示例 ≤ 5 条/漏洞类型（完整列表引用 reference）
• 使用表格/速查格式，禁止长段落叙述

工具优先级（本 Skill 自用）

单次超时 ≠ 不可用，必须重试 1 次后才能降级。

使用流程

依赖链约束（贯穿三步，强制）:

• Step 2 输入 == Step 1 的"已定位 reference 列表"，不得新加文件
• Step 3 引用集合 ⊆ Step 2 的"已加载列表"，禁止在 Step 3 重新搜索 reference
• Step 3 Checkpoint 中的引用计数必须能在 Step 2 Checkpoint 中找到对应来源

Step 1: 目标分类 + reference 定位

• 判断：Web / AI / Web+AI 混合 / 容器沙箱
• 定位：按"场景导航索引"找到对应 reference 文件，记为列表 L1

失败降级:

• 目标信息不足无法分类 → 触发歧义澄清问题，不猜测；不允许默认归类为 "Web+AI 混合"
• 场景导航索引未覆盖该场景 → 标注 "UNABLE TO CITE: 场景 {X} 不在索引内"，列表 L1 为空，进入 Step 3 时只能输出方法论级建议

✅ Checkpoint: Step 1 完成: 目标类型={X}, |L1| == 场景导航索引匹配数 = {N}

Step 2: 按需加载 Step 1 定位的 reference（懒加载）

• 输入: Step 1 产出的列表 L1；记本步加载集合为 L2，必须满足 L2 ⊆ L1
• 每次加载 1 个文件，单次 ≤ 1000 tokens；超出预算的 reference（如 ai-identity-app.md 906 行、ai-data-app.md 903 行）必须用 Read offset/limit 或 Grep 定位后再读
• 禁止在本步加载未在 L1 中的文件

失败降级:

• Read 失败 → 重试 1 次 → 仍失败用 Bash cat → 都失败 → 标注 "UNABLE TO ASSESS: 文件不可读"，从 L2 移除该项，不允许跳过到 Step 3
• Grep 无命中 → 标注 "UNABLE TO CITE: {关键词} 未在 {文件} 中检出"
• reference 文件不存在 → 标注断链 + 列入待补 reference 清单，不编造内容

✅ Checkpoint: Step 2 完成: |L2| == |L1| - 不可读文件数 = {M}, 合计 {X} tokens

Step 3: 按方法论输出测试思路（L1→L4）

• 输入: Step 2 产出的加载集合 L2；本步所有引用必须 ⊆ L2
• L1 攻击面识别 → L2 假设构建 → L3 深度利用 → L4 防御反推
• 每条结论必须引用 L2 中某文件的具体 section/行号；无依据 → 标注 "UNABLE TO CITE" 并停止该假设线
• 禁止重新搜索：本步发现需要新 reference → 回到 Step 1 重新定位，而不是直接 Read/Grep

✅ Checkpoint: Step 3 完成: 输出 N 条假设, 其中 已引用 M 条 + UNABLE TO CITE K 条 == N (等式验收)

全流程交叉验证:

• Step 3 引用的所有文件 ∈ Step 2 的 L2（grep 验证）
• 已引用条数 + UNABLE TO CITE 条数 == 总假设条数

场景导航索引

每行指向对应 reference。详细 Payload/案例/方法论全部在 reference 中，本 SKILL.md 不再展开。

核心方法论

Web 安全（按漏洞类型）

AI/LLM 安全（按 GAARM 阶段）

AI 应用 - 应用阶段按风险大类:

AI 模型 - 应用阶段按风险大类:

专项 reference:

• AI Agent / MCP / Skills 2025-2026 前沿风险 → references/ai-app-frontier.md
• 容器与沙箱逃逸实战方法论 → references/ai-baseline-escape.md

Payload 速查（按场景在主 reference 中查找）

零结果处理

与其他 Skill 的路由

v2.0 | 知识源: WooYun 88,636 × 先知 5,600+ × GAARM 150 × OWASP LLM/ASI/WSTG