security-pass

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Security Pass

Goal

目标

Run a Security Pass: a full security review of an existing project that adapts to whatever that project actually is — its domain, stack, architecture, and the documents it happens to have. This is not a fixed checklist run blindly against every project. It is a capability (the Security Harness) that, each time it executes, first builds a real model of the system and only then hunts for risk inside that model.

The flow this skill implements, every time:

PROJECT → DISCOVER → UNDERSTAND → ANALYZE → CORRELATE → DEDUPLICATE → TRIAGE → REPORT

执行Security Pass：针对现有项目开展全面安全审查，审查流程会适配项目实际情况——包括其领域、技术栈、架构及已有的文档。这并非盲目适用于所有项目的固定检查清单，而是一种能力（即Security Harness），每次执行时都会先构建真实的系统模型，再基于该模型排查风险。

本技能每次执行的流程如下：

PROJECT → DISCOVER → UNDERSTAND → ANALYZE → CORRELATE → DEDUPLICATE → TRIAGE → REPORT

Non-negotiable rule

不可违背的规则

This skill only analyzes, detects, explains, and proposes. It never modifies code, specs, configuration, or architecture during a Security Pass. Product decisions, architecture changes, and risk acceptance stay with the human — this skill's job ends at a clear report they can act on.

本技能仅负责分析、检测、说明及提出建议。在Security Pass过程中，绝不会修改代码、规格、配置或架构。产品决策、架构变更及风险接受权归人类用户所有——本技能的职责仅止于生成一份可供用户采取行动的清晰报告。

Reusability — do not assume the project

可复用性——不要预设项目情况

Do not assume language, framework, database, architecture style, cloud provider, auth model, or type of application. All of that gets discovered in step 1, not guessed from the skill's own priors. A project with no documents beyond source code is a valid target — scope the pass to what exists and say explicitly what layers were skipped for lack of material.

不要预设项目的编程语言、框架、数据库、架构风格、云服务商、认证模型或应用类型。所有这些信息都要在第一步中发现，而非基于技能自身的先验知识猜测。即使项目除源代码外无其他文档，也可作为有效审查目标——需根据现有内容确定审查范围，并明确说明因缺少材料而跳过的层级。

Required Input

必要输入

None is mandatory in isolation. The skill discovers what the project actually has:

Product docs (PRD, requirements)
Architecture / technical design / ADRs
Specs and tasks (SDD artifacts, if the project uses that workflow)
Source code
Tests
Configuration and environment files
Dependency manifests
CI/CD pipelines
```
CLAUDE.md
```
and other agent-context files
Any other relevant documentation

If a category doesn't exist, skip it and say so in the report — do not invent content to fill a gap.

没有单独强制要求的输入项。技能会主动发现项目实际包含的内容：

产品文档（PRD、需求文档）
架构/技术设计/ADR文档
规格与任务（若项目采用该工作流，则包括SDD工件）
源代码
测试用例
配置与环境文件
依赖清单
CI/CD流水线
```
CLAUDE.md
```
及其他Agent上下文文件
其他相关文档

若某类内容不存在，则跳过该类并在报告中说明——切勿编造内容填补空白。

Workflow

工作流程

1. Discover the project

1. 发现项目全貌

Before analyzing security, build a mental model of the system. Read whatever exists from the list above (glob/grep first, don't assume file layout). From it, work out:

What the system does and who uses it
What components exist and how they talk to each other
What data it handles, and which of that data is sensitive
What resources it protects
Its inputs and outputs
What actors exist — including which of them could plausibly be malicious
Where the trust boundaries actually are
What external integrations exist
Which operations are especially sensitive (money, auth, PII, admin actions, destructive actions)

This model is what step 2 gets pointed at. Skipping this and jumping straight to code is the single biggest way this skill degrades into a generic linter.

在分析安全性之前，先构建系统的心智模型。读取上述列表中所有存在的内容（先通过全局搜索/匹配查找，不要预设文件布局），并从中梳理出：

系统功能及用户群体
系统包含的组件及组件间的交互方式
系统处理的数据，以及其中哪些属于敏感数据
系统保护的资源
系统的输入与输出
存在的角色——包括哪些角色可能具有恶意
实际的信任边界位置
存在的外部集成
哪些操作属于高敏感操作（涉及资金、认证、PII、管理员操作、破坏性操作）

该模型将作为第二步分析的基础。跳过此步骤直接分析代码，是导致本技能退化为通用代码检查工具的最主要原因。

2. Analyze layer by layer — only the layers that exist

2. 逐层分析——仅分析存在的层级

For each layer actually present in the project, ask its guiding question and hunt for real, evidence-backed problems. Use

assets/finding-categories.md

as vocabulary to recognize a problem when you see one — not as a box-ticking checklist to march through mechanically. A category with nothing wrong in this project produces no finding; it does not need to be reported as "checked."

Product / requirements — guiding question: "What could an attacker do with the capabilities this system offers?" Look for unconsidered malicious actors, sensitive data, critical operations, missing security requirements, dangerous assumptions, ambiguous requirements, privacy/integrity/availability gaps.
Architecture / design — attack surface, trust boundaries, authn/authz, privilege boundaries, data exposure, secrets handling, cryptography, isolation between components, failure modes. For every issue: state what decision exists, what risk it introduces, under what concrete scenario it's exploitable, and what mitigations exist or are missing. Do not flag a decision as insecure merely because an alternative exists — justify it against this specific system.
Specs / tasks — guiding question: "Does this spec allow the behavior to be implemented securely?" Look for missing authz/authn, missing validation, missing limits, unhandled error states, unprotected sensitive data, missing negative/abuse cases, ownership and permission gaps, invalid-state handling, absent security acceptance criteria. Propose concrete acceptance criteria for gaps found — do not edit the spec.
Code — adapt to the real stack in front of you. Typical categories: authentication bypass, broken access control, privilege escalation, insecure direct object/resource access, injection, unsafe input handling, path traversal, command execution, sensitive data exposure, secrets in code, weak cryptography, insecure session/token handling, business-logic abuse, meaningful race conditions, replay attacks, resource exhaustion, insecure error handling, insecure defaults, dependency/supply-chain risk, unsafe file handling, misconfiguration, sensitive data in logs, missing controls a system like this one needs. Every finding needs concrete evidence from the project — "this could theoretically be improved" is not a finding.
Tests — what security properties are already verified, what negative/abuse scenarios are covered, what important controls have no test at all, and which security invariants deserve a test. Propose concrete tests where useful.

针对项目中实际存在的每个层级，提出指导性问题并排查有证据支撑的真实问题。将

assets/finding-categories.md

作为识别问题的词汇参考——而非机械执行的勾选清单。若某类问题在本项目中不存在，则无需生成发现记录；也无需将其报告为“已检查”。

产品/需求层——指导性问题：“攻击者可利用该系统提供的能力做什么？” 排查未考虑到的恶意角色、敏感数据、关键操作、缺失的安全需求、危险假设、模糊的需求、隐私/完整性/可用性缺口。
架构/设计层——攻击面、信任边界、认证/授权、权限边界、数据暴露、密钥管理、加密机制、组件间隔离、故障模式。对于每个问题：说明现有决策、该决策引入的风险、可被利用的具体场景、已存在或缺失的缓解措施。切勿仅因存在替代方案就判定某决策不安全——需结合本系统的具体情况进行论证。
规格/任务层——指导性问题：“该规格是否允许安全地实现功能？” 排查缺失的授权/认证、缺失的校验、缺失的限制、未处理的错误状态、未受保护的敏感数据、缺失的负面/滥用场景、权限与职责缺口、无效状态处理、缺失的安全验收标准。针对发现的缺口提出具体的验收标准——切勿修改规格。
代码层——适配当前项目的真实技术栈。典型问题类别：认证绕过、访问控制失效、权限提升、不安全的直接对象/资源访问、注入攻击、不安全的输入处理、路径遍历、命令执行、敏感数据暴露、代码中嵌入密钥、弱加密、不安全的会话/令牌处理、业务逻辑滥用、有实际影响的竞态条件、重放攻击、资源耗尽、不安全的错误处理、不安全默认配置、依赖/供应链风险、不安全的文件处理、配置错误、日志中的敏感数据、该类系统所需但缺失的控制措施。每个发现都需要项目中的具体证据——“理论上可优化”不属于有效发现。
测试层——已验证的安全属性、已覆盖的负面/滥用场景、完全未测试的重要控制措施、值得测试的安全不变量。在有用的情况下提出具体的测试建议。

3. Correlate and deduplicate

3. 关联与去重

If the same root problem shows up in more than one layer (e.g. a missing authorization check visible in both the spec and the code), merge it into a single finding that names every affected layer — don't report it three times.

若同一根源问题出现在多个层级中（例如，规格和代码中均可见缺失的授权检查），则将其合并为一个发现记录，并列出所有受影响的层级——切勿重复报告多次。

4. Write findings using this exact structure

4. 严格按照以下结构撰写发现记录

ID
Title
Severity        (CRITICAL | HIGH | MEDIUM | LOW | INFO)
Confidence       (HIGH | MEDIUM | LOW)
Category
Affected artifact
Location
Description
Evidence
Attack scenario
Potential impact
Existing mitigation
Recommended remediation
Suggested verification
Required change type

Discipline:

Never raise severity without a stated justification tied to this project's actual context.
Never write a purely hypothetical finding with no evidence in the project.
If there isn't enough information to confirm a real vulnerability, set
```
Confidence: LOW
```
and state exactly what information is missing — don't inflate confidence to sound thorough, and don't drop the finding either.

ID
标题
严重程度        (CRITICAL | HIGH | MEDIUM | LOW | INFO)
置信度       (HIGH | MEDIUM | LOW)
类别
受影响工件
位置
描述
证据
攻击场景
潜在影响
现有缓解措施
建议修复方案
建议验证方式
所需变更类型

注意事项：

若未结合项目实际上下文说明理由，切勿提高严重程度。
切勿撰写无项目证据支撑的纯假设性发现。
若信息不足以确认真实漏洞，则设置
```
置信度: LOW
```
并明确说明缺失的信息——切勿为了显得全面而夸大置信度，也不要忽略该发现。

5. Triage — assign

Required change type

5. 分类处理——分配「所需变更类型」

Every finding gets exactly one:

```
CODE FIX
```
```
TEST FIX
```
```
SPEC CHANGE
```
```
DESIGN / ADR CHANGE
```
```
PRODUCT / REQUIREMENT CHANGE
```
```
PROCESS / HARNESS CHANGE
```
```
ACCEPT RISK
```

This skill has no authority to change product scope, architecture, ADRs, business decisions, or to accept a risk on the user's behalf. Any finding tagged

DESIGN / ADR CHANGE

PRODUCT / REQUIREMENT CHANGE

, or

ACCEPT RISK

must be explicitly called out in the report's Governance / Decision Required section as needing a human decision — never silently resolved.

每个发现记录需分配且仅分配一种类型：

```
CODE FIX
```
（代码修复）
```
TEST FIX
```
（测试修复）
```
SPEC CHANGE
```
（规格变更）
```
DESIGN / ADR CHANGE
```
（设计/ADR变更）
```
PRODUCT / REQUIREMENT CHANGE
```
（产品/需求变更）
```
PROCESS / HARNESS CHANGE
```
（流程/工具变更）
```
ACCEPT RISK
```
（接受风险）

本技能无权变更产品范围、架构、ADR、业务决策，也无权代表用户接受风险。任何标记为

DESIGN / ADR CHANGE

、

PRODUCT / REQUIREMENT CHANGE

或

ACCEPT RISK

的发现，必须在报告的治理/需决策事项部分明确标注为需人类用户决策——切勿自行处理。

6. Avoid false positives — quality over quantity

6. 避免误报——质量优先于数量

Do not report: style preferences dressed up as vulnerabilities, purely theoretical issues with no project evidence, duplicates, issues already mitigated elsewhere in the project, controls that are irrelevant to this specific system. A short report of real findings beats a long report padded with noise — padding is what makes teams stop reading security reports.

切勿报告以下内容：伪装成漏洞的风格偏好、无项目证据的纯理论问题、重复问题、项目中已通过其他方式缓解的问题、与本系统无关的控制措施。包含真实发现的简短报告优于充斥无用信息的冗长报告——无用信息会导致团队不再阅读安全报告。

7. Write the report

7. 撰写报告

Write

SECURITY-REPORT.md

at the project root, following

assets/report-template.md

Executive Summary
Security Strengths
Findings
Priority
Governance / Decision Required

在项目根目录下编写

SECURITY-REPORT.md

，遵循

assets/report-template.md

的结构：

执行摘要
安全优势
发现记录
优先级
治理/需决策事项

Output

输出

SECURITY-REPORT.md

— nothing else in the project changes. This skill never touches code, specs, config, or documentation other than writing this one report file.

仅生成

SECURITY-REPORT.md

——项目中的其他内容均不会变更。本技能绝不会修改代码、规格、配置或除该报告外的其他文档。

Quality Gate

质量校验

Before returning, silently check:

Discovery actually happened first — the analysis in step 2 is grounded in the model built in step 1, not a generic pass over the code.
Every layer that genuinely exists in the project was reviewed; any layer skipped for lack of material is stated explicitly, not silently omitted.
Every finding traces to concrete evidence (a file, a line, a spec, a requirement) — nothing invented "because it could theoretically happen."
No
```
CRITICAL
```
/
```
HIGH
```
severity without a stated justification.
Findings requiring a human decision are explicitly flagged in Governance / Decision Required — none were resolved as if this skill had that authority.
The project itself is untouched — this was a report-only pass.

返回结果前，需静默检查以下内容：

是否先完成了项目发现步骤——第二步的分析基于第一步构建的模型，而非对代码的通用检查。
是否审查了项目中真实存在的所有层级；因缺少材料而跳过的层级是否已明确说明，而非静默忽略。
每个发现是否都能追溯到具体证据（文件、代码行、规格、需求）——无任何“理论上可能发生”的编造内容。
所有
```
CRITICAL
```
/
```
HIGH
```
严重程度的发现是否都有明确的理由说明。
需人类用户决策的发现是否已在「治理/需决策事项」部分明确标注——无任何被本技能自行处理的情况。
项目本身未被修改——仅生成了报告。

What this skill deliberately does not do yet

本技能当前刻意不支持的功能

It runs on-demand, invoked directly. It's built so its pieces (discovery, per-layer analysis, finding structure, triage) could later plug into code review, PR checks, CI/CD, or new-spec workflows — but that wiring isn't part of this skill. Don't build it speculatively; add it when there's a real need to run this automatically instead of on demand.

本技能为按需调用型，需直接触发。其各个模块（发现、逐层分析、发现记录结构、分类处理）未来可接入代码审查、PR检查、CI/CD或新规格工作流——但当前未实现这些对接。请勿提前构建此类功能；当确实需要自动执行而非按需执行时，再添加相关对接。