用AI做代码安全审计：claude-code-security-skills 项目解析

项目地址：https://github.com/ez-lbz/claude-code-security-skills

我对 Anthropic 官方的 anthropics/claude-code-security-review 二次开发得到了这个项目。原项目是一个 GitHub Action，专门在 Pull Request 上运行 Claude Code 做安全审计。我把其中的核心 prompt、过滤规则和方法论提取出来，重新组织成一个独立的 skill 包，可以直接在 GitHub Copilot、Claude Code 或任何支持自定义 skill 的 AI 辅助审计工作流中使用，不再依赖特定的 CI/CD 环境或 PR 触发机制。

项目结构如下：

claude-code-security-skills/
├── SKILL.md                          # Skill 入口，定义三阶段执行契约
└── resources/
    ├── audit-prompt.md               # 安全审计主提示词
    ├── filtering-rules.md            # 误报过滤规则（19 条排除 + 17 条先例）
    ├── hard-exclusion-patterns.md    # 正则快速过滤模式
    └── customization-guide.md        # 扩展扫描和过滤规则的指南

一、代码审计流程

整个审计流程分为严格顺序执行的三个阶段，AI 必须依次完成所有阶段才能输出最终结果，禁止在第三阶段完成之前上报任何发现。

Phase 1: 安全审计        →   Phase 2: 过滤发现        →   Phase 3: 报告输出
（生产原始发现列表）          （排除误报和低置信发现）        （仅输出通过过滤的发现）

Phase 1 — 安全审计

AI 在这一阶段扮演高级安全工程师的角色，按照三步方法论对代码库展开分析：

这一阶段产出内部原始发现列表，格式固定包含标题、文件位置、类别、严重程度、描述和攻击路径，不直接展示给用户。

Phase 2 — 过滤发现

对第一阶段的每一条发现都执行过滤，分两步进行：

Phase 3 — 报告输出

报告结构固定：先展示完整的过滤决策表，再输出被保留发现的详细报告，最后附上被排除发现的汇总清单。读者可以清楚看到每条发现的最终去向和理由，审计过程完全可解释。

二、所有 prompt 详解

项目的 prompt 分散在五个文件中，各司其职。下面逐一引用并拆解每个文件的核心内容。

SKILL.md — 流程总控文件

1. 强制执行契约

> ** MANDATORY EXECUTION CONTRACT**
>
> This skill defines a **strictly ordered, three-phase process**.
> You MUST complete **all three phases in sequence** before producing final output.
> **You are FORBIDDEN from reporting any findings until Phase 3 (Filter) is complete.**
> Skipping or abbreviating any phase is a critical failure.

这是整个 skill 的灵魂。之所以用 FORBIDDEN 和大写措辞，是因为模型在没有显式约束时，天然倾向于立刻给出结论、跳过过滤步骤，导致误报率极高。这段契约把"先过滤再上报"强制写入了执行条件。

2. 读取资源文件的顺序声明

| Resource                    | Path                                  | Read Requirement              |
|-----------------------------|---------------------------------------|-------------------------------|
| Audit Prompt                | resources/audit-prompt.md             | MUST read before Phase 1      |
| Hard Exclusion Patterns     | resources/hard-exclusion-patterns.md  | MUST read before Phase 2      |
| False Positive Filtering    | resources/filtering-rules.md          | MUST read before Phase 2      |
| Customization Guide         | resources/customization-guide.md      | Read if project-specific rules|

每个资源文件在哪个阶段必须读取、是否必须读取，都在这里显式声明。AI 在进入每个阶段前会先完成对应文件的读取，确保审计和过滤的标准是一致的。

3. Phase 1 的任务定义

###  PHASE 1: Security Audit

**Goal:** Produce a raw list of candidate findings. At this stage, do NOT filter — cast a wide net.

**You MUST:**

1. Read `resources/audit-prompt.md` fully before starting analysis.
2. Execute the three-phase analysis defined in that document:
   - **Phase 1a — Codebase Context Research**: Security frameworks, auth patterns, threat model.
   - **Phase 1b — Comparative Analysis**: Compare code against secure patterns, flag deviations.
   - **Phase 1c — Vulnerability Assessment**: Trace data flows, injection points, privilege boundaries.
3. Produce a **raw findings list** in the following internal format (not shown to user yet):

"cast a wide net"这个表述很关键，第一阶段不过滤，宽进严出，避免在生产阶段就错误地丢掉真实漏洞。

4. 原始发现的内部格式

RAW FINDING #N
- Title: <short title>
- File: <path:line>
- Category: <e.g. path_traversal, sql_injection, rce>
- Severity: HIGH / MEDIUM / LOW
- Description: <what the bug is>
- Attack Path: <how an attacker exploits it step by step>

格式要求包含攻击路径这个字段，这是后续过滤时判断"是否有具体可利用路径"的基础。如果 AI 在第一阶段就没有写出攻击路径，第二阶段的置信度评分就会因为信息不足而偏低，被误判排除。

5. Phase 2 的过滤表格格式

| # | Title | Hard Excl? | Precedent Hit? | Concrete Attack Path? | Confidence (1-10) | Decision | Reason |
|---|-------|-----------|----------------|-----------------------|-------------------|----------|--------|
| 1 | ... | No | No | Yes | 9 |  KEEP | Directly exploitable, specific code path |
| 2 | ... | No | UUID unguessable (Precedent #2) | Conditional | 5 |  EXCLUDE | UUID ID guessing required |

这张表是过滤决策的完整记录，每一条原始发现都必须有对应的一行，不能跳过。Precedent Hit 列引用 filtering-rules.md 中的先例编号，让过滤逻辑完全可追溯。

6. 置信度评分规则

| Score | Meaning | Action |
|-------|---------|--------|
| 1-3 | Low confidence, likely false positive | **EXCLUDE** |
| 4-6 | Medium confidence, needs investigation | **EXCLUDE** (unless very concrete) |
| 7-10 | High confidence, likely true vulnerability | **KEEP** |

**Rule: Any finding with Confidence < 7 MUST be excluded.**

7 分是硬性门槛，中等置信度在绝大多数情况下也被排除，这是为了把误报率控制在一个人工审查可以承受的范围内。

7. Phase 3 的报告结构

###  PHASE 3: Report (Only KEPT findings)

**You MUST output the filter table first** (Phase 2 output), then the detailed findings.

#### Filter Summary Table (always show this)
Show the Phase 2 table so the reader can see the filtering decisions.

#### Detailed Finding Report (only KEPT items)

For each KEPT finding, output:

## Vuln N: <Category>: `<file:line>`

* Severity: HIGH / MEDIUM / LOW
* Confidence: <1-10 score> / 10
* Description: <what the vulnerability is>
* Exploit Scenario: <concrete step-by-step attack>
* Recommendation: <specific fix>

报告必须先展示过滤表，再展示详细发现，这个顺序是强制的。让读者在看到结论之前先看到推理过程，是有意为之的设计。

8. 反模式清单

-  Do NOT report findings before completing Phase 2 filtering
-  Do NOT use 0.0-1.0 confidence scores — the 1-10 scale is required
-  Do NOT skip the filter table in the output
-  Do NOT report a finding with Confidence < 7
-  Do NOT combine Phase 1 and Phase 3 (jumping directly from audit to report)
-  Do NOT mentally filter without showing the filter table

第二条的存在有历史原因：audit-prompt.md 原始使用的是 0.0-1.0 浮点数刻度，SKILL.md 统一要求改为 1-10 整数刻度，这里显式禁止旧刻度，防止两套标准混用。

resources/audit-prompt.md — 安全审计主提示词

1. 角色与目标

## Role

You are a senior security engineer performing a focused security audit on the given source code.

## Objective

Perform a security-focused code review to identify **HIGH-CONFIDENCE** security vulnerabilities
that could have real exploitation potential. This is NOT a general code review — focus ONLY
on concrete security issues.

"NOT a general code review"这句话把审计范围限定死了。没有这句话，AI 很容易在输出里混入架构建议、代码质量问题，稀释真正有价值的安全发现。

2. 核心约束

## Critical Instructions

1. **MINIMIZE FALSE POSITIVES**: Only flag issues where you're >80% confident of actual exploitability
2. **AVOID NOISE**: Skip theoretical issues, style concerns, or low-impact findings
3. **FOCUS ON IMPACT**: Prioritize vulnerabilities that could lead to unauthorized access,
   data breaches, or system compromise
4. **EXCLUSIONS**: Do NOT report the following issue types:
   - Denial of Service (DOS) vulnerabilities, even if they allow service disruption
   - Secrets or sensitive data stored on disk (these are handled by other processes)
   - Rate limiting or resource exhaustion issues

80% 置信度的门槛在这里以文字形式出现，对应 SKILL.md 中置信度不低于 7 分的量化标准，两处表述相互呼应、互为补充。

3. 审计覆盖的漏洞类别

### Input Validation Vulnerabilities
- SQL injection via unsanitized user input
- Command injection in system calls or subprocesses
- XXE injection in XML parsing
- Template injection in templating engines (SSTI)
- NoSQL injection in database queries
- Path traversal in file operations

### Authentication & Authorization Issues
- Authentication bypass logic
- Privilege escalation paths
- Session management flaws
- JWT token vulnerabilities
- Authorization logic bypasses

### Crypto & Secrets Management
- Hardcoded API keys, passwords, or tokens
- Weak cryptographic algorithms or implementations
- Improper key storage or management
- Cryptographic randomness issues
- Certificate validation bypasses

### Injection & Code Execution
- Remote code execution via deserialization
- Pickle injection in Python
- YAML deserialization vulnerabilities
- Eval injection in dynamic code execution
- XSS vulnerabilities in web applications (reflected, stored, DOM-based)

### Data Exposure
- Sensitive data logging or storage
- PII handling violations
- API endpoint data leakage
- Debug information exposure

### Additional Notes
- Even if something is only exploitable from the local network, it can still be a HIGH severity issue

最后那句附注很重要：内网可利用的漏洞同样可以是 HIGH，这防止 AI 因为"需要内网访问"就自动降级处理。

4. 分析方法论

## Analysis Methodology

### Phase 1 — Codebase Context Research
- Identify existing security frameworks and libraries in use
- Look for established secure coding patterns in the codebase
- Examine existing sanitization and validation patterns
- Understand the project's security model and threat model

### Phase 2 — Comparative Analysis
- Compare target code against established security patterns
- Identify deviations from established secure practices
- Look for inconsistent security implementations
- Flag code that introduces new attack surfaces

### Phase 3 — Vulnerability Assessment
- Examine each file for security implications
- Trace data flow from user inputs to sensitive operations
- Look for privilege boundaries being crossed unsafely
- Identify injection points and unsafe deserialization

三步法的设计逻辑是：先理解项目的安全基线，再找出偏离，最后确认具体漏洞。如果跳过第一步直接找漏洞，很容易把项目已有的安全机制当成缺失来上报。

5. 输出格式

## Output Format

# Vuln 1: XSS: `foo.py:42`

* Severity: High
* Description: User input from `username` parameter is directly interpolated
  into HTML without escaping
* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script>
  to execute JavaScript
* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled

格式要求文件名带行号、描述具体到参数名、利用场景要具体到 payload、修复建议要具体到库或方法名。每一项都是可操作的，不接受模糊表述。

6. 严重程度与置信度

## Severity Guidelines

| Severity | Criteria |
|----------|----------|
| **HIGH** | Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass |
| **MEDIUM** | Vulnerabilities requiring specific conditions but with significant impact |
| **LOW** | Defense-in-depth issues or lower-impact vulnerabilities |

## Confidence Scoring

| Score | Meaning |
|-------|---------| 
| 0.9-1.0 | Certain exploit path identified, tested if possible |
| 0.8-0.9 | Clear vulnerability pattern with known exploitation methods |
| 0.7-0.8 | Suspicious pattern requiring specific conditions to exploit |
| Below 0.7 | **Don't report** (too speculative) |

这里的 0.0-1.0 刻度是 audit-prompt.md 的原始表述，SKILL.md 将其统一为 1-10 整数，实际使用时以 SKILL.md 为准。

7. 明确排除项

## Important Exclusions — Do NOT Report

- Denial of Service (DOS) vulnerabilities or resource exhaustion attacks
- Secrets/credentials stored on disk (managed separately)
- Rate limiting concerns or service overload scenarios
- Memory consumption or CPU exhaustion issues
- Lack of input validation on non-security-critical fields without proven impact

这些排除项在 filtering-rules.md 的硬性排除列表中也有覆盖，两处重复声明是故意为之，确保 AI 在审计和过滤两个阶段都记住这些规则。

resources/filtering-rules.md — 误报过滤规则

1. 过滤者的角色定义

## Filtering Role

When filtering findings, act as a security expert reviewing results from a code audit.
Your task is to filter out false positives and low-signal findings to reduce alert fatigue.
You must maintain high recall (don't miss real vulnerabilities) while improving precision.

"reduce alert fatigue"是过滤阶段的核心目标。如果每次审计产出几十条发现，人工审查就会疲劳失效，这个过滤层的存在就是为了把发现数量控制在真正值得关注的范围内。

2. 硬性排除列表（全）

## Hard Exclusions

Automatically exclude findings matching these patterns:

1. **Denial of Service (DOS)** vulnerabilities or resource exhaustion attacks.
2. **Secrets/credentials stored on disk** — these are managed separately.
3. **Rate limiting concerns** or service overload scenarios. Services do not need to implement rate limiting.
4. **Memory consumption or CPU exhaustion** issues.
5. **Lack of input validation** on non-security-critical fields without proven security impact.
6. **Input sanitization concerns for CI/CD workflows** unless they are clearly triggerable via untrusted input.
7. **Lack of hardening measures.** Code is not expected to implement all security best practices, just avoid obvious vulnerabilities.
8. **Race conditions or timing attacks** that are theoretical rather than practical. Only report if extremely problematic.
9. **Outdated third-party libraries.** These are managed separately and should not be reported here.
10. **Memory safety issues in memory-safe languages.** Buffer overflows, use-after-free etc. are impossible in Rust, Go, Java, Python, etc. Do not report memory safety issues in these languages.
11. **Test files.** Files that are only unit tests or only used as part of running tests.
12. **Log spoofing.** Outputting un-sanitized user input to logs is not a vulnerability.
13. **SSRF controlling only the path.** SSRF is only a concern if it can control the host or protocol.
14. **AI prompt injection.** Including user-controlled content in AI system prompts is not a vulnerability.
15. **Regex injection.** Injecting untrusted content into a regex is not a vulnerability. Regex DOS is also excluded.
16. **Insecure documentation.** Do not report findings in documentation files such as markdown files.
17. **Missing audit logs.** A lack of audit logs is not a vulnerability.
18. **Unavailable internal dependencies.** Depending on internal libraries that are not publicly available is not a vulnerability.
19. **Non-vulnerability crashes.** Code that crashes (e.g., undefined or null variable) but is not actually a vulnerability.

19 条规则涵盖了代码审计工具最常见的噪音类型。第 10 条特别值得注意：在 Java、Python、Go、Rust 等内存安全语言中，AI 不应上报缓冲区溢出或 use-after-free 这类在语言层面根本不会发生的问题。第 14 条则明确了 AI prompt 注入不在审计范围内，这是写 AI 应用的开发者经常问到的问题。

3. 先例列表（全）

## Precedents

Specific guidance for common security patterns:

1. **Logging secrets**: Logging high-value secrets in plaintext is a vulnerability. Logging URLs is
   assumed to be safe. Logging request headers is assumed to be dangerous since they likely contain
   credentials.
2. **UUIDs**: Can be assumed to be unguessable and do not need to be validated. If a vulnerability
   requires guessing a UUID, it is not valid.
3. **Audit logs**: Are not a critical security feature and should not be reported as a vulnerability
   if missing or modified.
4. **Environment variables and CLI flags**: Are trusted values. Attackers are not able to modify
   them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
5. **Resource management**: Issues such as memory or file descriptor leaks are not valid vulnerabilities.
6. **Low-impact web vulnerabilities**: Tabnabbing, XS-Leaks, prototype pollution, and open redirects
   should not be reported unless extremely high confidence.
7. **Outdated libraries**: Managed separately; do not report.
8. **React/Angular XSS**: These frameworks are generally secure against XSS. Do not report XSS unless
   using `dangerouslySetInnerHTML`, `bypassSecurityTrustHtml`, or similar unsafe methods.
9. **CI/CD workflows**: Most vulnerabilities in CI/CD workflow files are not exploitable in practice.
   Before validating, ensure it is concrete with a very specific attack path.
10. **Client-side JS/TS permission checks**: A lack of permission checking or authentication in
    client-side code is not a vulnerability. Client-side code is not trusted. Backend is responsible
    for validation. Same applies for path-traversal and SSRF in client-side JS.
11. **MEDIUM findings**: Only include if they are obvious and concrete issues.
12. **Jupyter notebooks (*.ipynb)**: Most vulnerabilities are not exploitable in practice. Ensure
    concrete attack path with untrusted input.
13. **Logging non-PII data**: Not a vulnerability even if data may be sensitive. Only report if
    exposing secrets, passwords, or PII.
14. **Command injection in shell scripts**: Generally not exploitable since shell scripts generally
    do not run with untrusted user input. Only report if concrete attack path for untrusted input exists.
15. **SSRF in client-side JS/TS**: Not valid since client-side code cannot make server-side requests
    that bypass firewalls. Only report SSRF in server-side code.
16. **Path traversal in HTTP requests**: Using `../` is generally not a problem when triggering HTTP
    requests. Only relevant when reading files where `../` may allow accessing unintended files.
17. **Log query injection**: Generally not an issue. Only report if the injection will definitely lead
    to exposing sensitive data to external users.

先例 8 解决了 React/Angular 项目中最常见的 XSS 误报问题。先例 10 解决了前后端分离项目中前端代码缺少鉴权的误报。先例 16 澄清了路径遍历在 HTTP 请求场景下的适用范围。这 17 条先例都来自实际审计中反复出现的误判场景。

4. 信号质量标准

## Signal Quality Criteria

For remaining findings, assess:

1. Is there a **concrete, exploitable vulnerability** with a clear attack path?
2. Does this represent a **real security risk** vs theoretical best practice?
3. Are there **specific code locations** and reproduction steps?
4. Would this finding be **actionable** for a security team?

四个问题实际上是在问同一件事：这个发现是否具体到可以立刻行动。"actionable"是过滤的核心标准，理论上存在的风险不满足这个标准。

5. 置信度评分定义

## Confidence Scoring (1-10 scale)

| Score | Meaning | Action |
|-------|---------|--------|
| 1-3 | Low confidence, likely false positive or noise | **Exclude** |
| 4-6 | Medium confidence, needs investigation | **Exclude** (unless very concrete) |
| 7-10 | High confidence, likely true vulnerability | **Keep** |

> **Threshold**: Only keep findings with confidence score ≥ 7.

中等置信度在绝大多数情况下也被排除，这是一个有意为之的高门槛设计，目标是只让真正值得人工审查的发现通过。

resources/hard-exclusion-patterns.md — 正则排除模式

1. 工作原理

## How It Works

For each security finding, the **title** and **description** are concatenated and checked against
these patterns. If any pattern matches, the finding is automatically excluded.

Additionally, **file-level rules** apply:
- Findings in **Markdown files** (`.md`) are unconditionally excluded.
- **Memory safety** findings are excluded unless the file is C/C++ (`.c`, `.cc`, `.cpp`, `.h`).
- **SSRF** findings are excluded if the file is an HTML file (`.html`).

正则过滤发生在 AI 分析之前，用于快速处理明显的低价值发现，减少 AI 推理的消耗。文件级别的规则是对正则模式的补充，处理一些标题和描述无法表达的情况。

2. DoS 和资源耗尽模式

### 1. DOS / Resource Exhaustion

**Exclusion Reason**: `Generic DOS/resource exhaustion finding (low signal)`

```regex
\b(denial of service|dos attack|resource exhaustion)\b                    [IGNORECASE]
\b(exhaust|overwhelm|overload).*?(resource|memory|cpu)\b                  [IGNORECASE]
\b(infinite|unbounded).*?(loop|recursion)\b                               [IGNORECASE]

**3. 限流模式**

2. Rate Limiting

Exclusion Reason: Generic rate limiting recommendation

\b(missing|lack of|no)\s+rate\s+limit                                    [IGNORECASE]
\brate\s+limiting\s+(missing|required|not implemented)                    [IGNORECASE]
\b(implement|add)\s+rate\s+limit                                         [IGNORECASE]
\bunlimited\s+(requests|calls|api)                                       [IGNORECASE]

**4. 资源管理、开放重定向、内存安全、正则注入、SSRF 模式**

3. Resource Management

\b(resource|memory|file)\s+leak\s+potential                              [IGNORECASE]
\bunclosed\s+(resource|file|connection)                                   [IGNORECASE]
\b(close|cleanup|release)\s+(resource|file|connection)                    [IGNORECASE]
\bpotential\s+memory\s+leak                                              [IGNORECASE]
\b(database|thread|socket|connection)\s+leak                              [IGNORECASE]

4. Open Redirect

\b(open redirect|unvalidated redirect)\b                                 [IGNORECASE]
\b(redirect.(attack|exploit|vulnerability))\b                            [IGNORECASE]
\b(malicious.redirect)\b                                                 [IGNORECASE]

5. Memory Safety (non-C/C++ only)

Only applied when file extension is NOT in {.c, .cc, .cpp, .h}

\b(buffer overflow|stack overflow|heap overflow)\b                        [IGNORECASE]
\b(oob)\s+(read|write|access)\b                                          [IGNORECASE]
\b(out.?of.?bounds?)\b                                                   [IGNORECASE]
\b(memory safety|memory corruption)\b                                    [IGNORECASE]
\b(use.?after.?free|double.?free|null.?pointer.?dereference)\b           [IGNORECASE]
\b(segmentation fault|segfault|memory violation)\b                       [IGNORECASE]
\b(bounds check|boundary check|array bounds)\b                           [IGNORECASE]
\b(integer overflow|integer underflow|integer conversion)\b              [IGNORECASE]
\barbitrary.?(memory read|pointer dereference|memory address|memory pointer)\b [IGNORECASE]

6. Regex Injection / ReDoS

\b(regex|regular expression)\s+injection\b                               [IGNORECASE]
\b(regex|regular expression)\s+denial of service\b                       [IGNORECASE]
\b(regex|regular expression)\s+flooding\b                                [IGNORECASE]

7. SSRF (HTML files only)

Only applied when file extension is .html

\b(ssrf|server\s+.?side\s+.?request\s+.?forgery)\b                      [IGNORECASE]

内存安全模式组有 9 条之多，这是因为 AI 非常容易在 Java、Python 等项目里上报"潜在的内存泄漏"或"整数溢出"，而这些问题在内存安全语言中根本不可能以传统意义上的方式被利用，全部需要过滤。

**5. Python 实现参考**

```python
import re
from typing import List, Pattern

_DOS_PATTERNS: List[Pattern] = [
    re.compile(r'\b(denial of service|dos attack|resource exhaustion)\b', re.IGNORECASE),
    re.compile(r'\b(exhaust|overwhelm|overload).*?(resource|memory|cpu)\b', re.IGNORECASE),
    re.compile(r'\b(infinite|unbounded).*?(loop|recursion)\b', re.IGNORECASE),
]

# Check a finding:
def should_exclude(title: str, description: str) -> bool:
    combined = f"{title} {description}".lower()
    for pattern in _DOS_PATTERNS:
        if pattern.search(combined):
            return True
    return False

这段代码来自原始 GitHub Action 的生产实现，说明这套正则规则是在实际运行中反复验证过的，不是随意编写的。

resources/customization-guide.md — 定制化指南

这个文件提供了两个扩展点，解决通用审计规则无法覆盖项目特殊性的问题。

1. 自定义扫描指令的格式

## 1. Custom Scan Instructions

Use the same format as the default categories — a bold header followed by bullet points:

**Category Name:**
- Specific vulnerability or pattern to check
- Another specific issue to look for
- Detailed description of what constitutes this vulnerability

2. 典型场景示例

**Compliance-Specific Checks:**
- GDPR Article 17 "Right to Erasure" implementation gaps
- HIPAA PHI encryption at rest violations
- PCI DSS credit card data retention beyond allowed periods
- SOC2 audit trail tampering or deletion capabilities
- CCPA data portability API vulnerabilities

**Financial Services Security:**
- Transaction replay attacks in payment processing
- Double-spending vulnerabilities in ledger systems
- Interest calculation manipulation through timing attacks
- Regulatory reporting data tampering
- Know Your Customer (KYC) bypass mechanisms

**E-commerce Specific:**
- Shopping cart manipulation for price changes
- Inventory race conditions allowing overselling
- Coupon/discount stacking exploits
- Affiliate tracking manipulation
- Review system authentication bypass

**GraphQL Security:**
- Query depth attacks allowing unbounded recursion
- Field-level authorization bypass
- Introspection data leakage in production

自定义扫描指令追加在默认类别之后，不替换任何原有内容。以电商项目为例，购物车价格篡改和库存超卖这类业务逻辑漏洞是通用审计模板覆盖不到的，需要在这里显式加入。

3. 自定义过滤指令的格式

## 2. Custom Filtering Instructions

When custom filtering instructions are provided, they **completely replace** the default
filtering rules in `filtering-rules.md`. The hard exclusion patterns (regex-based) in
`hard-exclusion-patterns.md` are always applied regardless.

这一点需要特别注意：自定义过滤指令是完全替换，不是追加。如果你提供了自定义规则，就要把所有必要的排除规则重新声明。

HARD EXCLUSIONS - Automatically exclude findings matching these patterns:
1. All DOS/resource exhaustion - we have k8s resource limits and autoscaling
2. Missing rate limiting - handled by our API gateway
3. Tabnabbing vulnerabilities - acceptable risk per our threat model
4. Test files (ending in _test.go, _test.js, or in __tests__ directories)

SIGNAL QUALITY CRITERIA - For remaining findings, assess:
1. Can an unauthenticated external attacker exploit this?
2. Is there actual data exfiltration or system compromise potential?
3. Is this exploitable in our production Kubernetes environment?
4. Does this bypass our API gateway security controls?

PRECEDENTS -
1. We use AWS Cognito for all authentication - auth bypass must defeat Cognito
2. All APIs require valid JWT tokens validated at the gateway level
3. SQL injection is only valid if using raw queries (we use Prisma ORM everywhere)
4. All internal services communicate over mTLS within the k8s cluster
5. Secrets are in AWS Secrets Manager or k8s secrets, never in code

先例部分最能体现定制化的价值：如果整个项目都用了 Prisma ORM，AI 上报 SQL 注入就必须要证明有原生查询的地方，否则直接排除。如果用了 AWS Cognito 做统一认证，认证绕过必须能绕过 Cognito，而不只是绕过某个接口的本地检查。这些业务上的"已知安全"信息只有项目团队自己知道，需要通过这里告诉 AI。

两个扩展点的关键区别汇总：

实战测试

网上随便找一个项目进行测试：https://github.com/newbee-ltd/newbee-mall

在gemini的对话框输入：请使用claude-code-security-skills规则来审计这个项目，最终生成的报告如下：

从这里开始是报告

Newbee-Mall Security Audit Report

Generated using the AI-Driven Code Security Review Methodology.

🛡️ Phase 2: Filter Summary Table

🚨 Phase 3: Detailed Finding Report

Vuln 1: Authentication & Authorization Issues: OrderController.java:147

• Severity: HIGH
• Confidence: 10 / 10
• Description: The /paySuccess endpoint is severely misconfigured and lacks both authentication and ownership checks. In NeeBeeMallWebMvcConfigurer.java, /paySuccess is omitted from the newBeeMallLoginInterceptor's addPathPatterns, making it accessible to completely unauthenticated users. Furthermore, NewBeeMallOrderServiceImpl.paySuccess() blindly accepts any orderNo and payType, instantly updating the order status to ORDER_PAID (PayStatusEnum.PAY_SUCCESS) without verifying if the payment originated from a trusted payment gateway callback or if the user actually paid.
• Exploit Scenario:

1. An attacker registers and adds items to their shopping cart.
2. The attacker checks out, creating an order. The system assigns an orderNo and places the order in the ORDER_PRE_PAY state.
3. Instead of paying through Alipay/WeChat, the attacker directly sends a GET /paySuccess?orderNo=<their_order_no>&payType=1 request to the application.
4. The application processes the request, marks the order as fully paid, and prepares it for shipping, resulting in financial loss for the mall.

• Recommendation:

• Restrict the /paySuccess endpoint. It should not be a publicly accessible GET request that blindly accepts payment success.
• Implement cryptographic signature verification (e.g., Alipay/WeChat Pay callback validation) to ensure that the request actually came from the payment provider.
• Require the user to be authenticated and verify that user.getUserId().equals(newBeeMallOrder.getUserId()) if this is meant to be a user-facing status check rather than a webhook.

Vuln 2: Input Validation / File Upload: UploadController.java:51

• Severity: MEDIUM
• Confidence: 8 / 10
• Description: The backend file upload functionality for administrators (/admin/upload/file and /admin/upload/files) is vulnerable to an arbitrary file extension weakness. The code correctly attempts to validate that the uploaded file is an image using ImageIO.read(file.getInputStream()). However, it blindly extracts the file extension from the original filename provided by the user (String suffixName = fileName.substring(fileName.lastIndexOf("."));) and appends it to the newly generated filename without validation or sanitization.
• Exploit Scenario:

1. A compromised or malicious administrator wishes to achieve persistent XSS to attack higher-privileged users or site visitors (if the image is served on the main site).
2. The attacker crafts a polyglot payload: a perfectly valid JPEG image file with malicious HTML/JavaScript appended to the end of the file.
3. The attacker names the file payload.html and uploads it.
4. The server sees the .html extension, sets suffixName = ".html", successfully parses the valid JPEG headers via ImageIO.read(), and saves the file as 20241030_1234.html in the public upload directory.
5. The attacker shares the link http://example.com/upload/20241030_1234.html. When a victim visits this URL, the browser interprets the file as HTML and executes the embedded JavaScript payload.

• Recommendation:

• Do not trust the file extension provided by the user.
• Derive the file extension securely based on the MIME type or the actual content of the file (e.g., reading the magic bytes of the image). If ImageIO parses it as a JPEG, enforce the .jpg extension.
• Maintain a strict whitelist of allowed extensions (e.g., .jpg, .jpeg, .png, .gif).

🚫 Excluded Findings (1 total)

从这里结束是报告**

可以看到非常精准的点出了项目中存在的两个漏洞。实际上项目中还存在CSRF配置问题，但是发现这俩已经很符合预期了。