Security Pass 是一个用于对现有软件项目执行完整安全审查的技能。它的核心特点是上下文感知：不把同一套固定清单盲目套用到所有项目，而是每次执行时先建立系统的真实模型，再在模型内部寻找风险。
【用途】 用于对一个已有项目进行安全审查，适应项目实际的领域、技术栈、架构以及它所拥有的文档。它只分析、检测、解释并提议，在一次 Security Pass 中绝不修改代码、规格、配置或架构。产品决策、架构变更与风险接受由人类保留，技能的工作止于一份可据以行动的报告。
【流程】 每次实现的流程为：PROJECT → DISCOVER → UNDERSTAND → ANALYZE → CORRELATE → DEDUPLICATE → TRIAGE → REPORT。
【可复用性——不要预设项目】 不预设语言、框架、数据库、架构风格、云服务商、认证模型或应用类型。这些都在发现阶段确定，而不是依据技能自身的先验猜测。只有源码、没有任何文档的项目也是有效目标——把审查范围限定在实际存在的内容，并明确说明因缺少材料而跳过了哪些层次。
【必需输入】 没有单独强制要求的输入。技能会自行发现项目实际拥有什么：产品文档（PRD、需求）、架构/技术设计/ADR、规格与任务（如项目采用 SDD 工作流）、源代码、测试、配置与环境文件、依赖清单、CI/CD 流水线、CLAUDE.md 及其他代理上下文文件、其他相关文档。若某类不存在，则跳过并在报告中说明，不凭空编造内容来填补空白。
【工作流】
-
发现项目：在分析安全之前先建立系统的心理模型。先用 glob/grep，不假设文件布局。据此弄清：系统做什么、谁使用；有哪些组件、组件之间如何通信；处理哪些数据、其中哪些是敏感的；保护哪些资源；输入与输出；存在哪些角色，包括哪些角色可能具有恶意；信任边界实际位于何处；有哪些外部集成；哪些操作特别敏感（涉及金钱、认证、PII、管理操作、破坏性操作）。这个模型是下一步的分析对象。跳过这一步直接看代码，是让该技能退化为通用 linter 的最大原因。
-
逐层分析——仅分析实际存在的层次。对项目中实际存在的每一层，提出其引导性问题并寻找有证据支撑的真实问题。使用 assets/finding-categories.md 作为识别问题的词汇表，而不是机械对照的勾选清单。在本项目中不存在问题的类别不产生发现，也不需要报告为“已检查”。
- 产品/需求——引导问题：“攻击者能利用该系统提供的哪些能力做什么？”寻找未被考虑到的恶意角色、敏感数据、关键操作、缺失的安全需求、危险假设、含糊需求、隐私/完整性/可用性缺口。
- 架构/设计——攻击面、信任边界、认证/授权、权限边界、数据暴露、密钥处理、密码学、组件间隔离、失败模式。对每个问题说明：存在什么决策、引入什么风险、在什么具体场景下可利用、有哪些现有或缺失的缓解措施。不要仅因存在替代方案就判定某决策不安全——要结合此具体系统给出理由。
- 规格/任务——引导问题：“这份规格是否允许安全地实现该行为？”寻找缺失的授权/认证、缺失的校验、缺失的限制、未处理的错误状态、未受保护的敏感数据、缺失的负面/滥用用例、所有权与权限缺口、无效状态处理、缺失的安全验收标准。为发现的缺口提出具体验收标准，但不编辑规格。
- 代码——适应眼前的真实技术栈。典型类别包括：认证绕过、访问控制失效、权限提升、不安全的直接对象/资源访问、注入、不安全的输入处理、路径穿越、命令执行、敏感数据暴露、代码中的密钥、弱密码学、不安全的会话/令牌处理、业务逻辑滥用、有实际意义的竞态条件、重放攻击、资源耗尽、不安全的错误处理、不安全的默认值、依赖/供应链风险、不安全文件处理、错误配置、日志中的敏感数据、该类系统所需的控制缺失。每个发现都需要项目中的具体证据——“理论上可以改进”不算发现。
- 测试——已经验证了哪些安全属性、覆盖了哪些负面/滥用场景、哪些重要控制完全没有测试、哪些安全不变量值得测试。在有帮助处提出具体测试。
-
关联与去重：若同一根问题出现在多层（如规格与代码中都可见的授权检查缺失），合并为一条命名所有受影响层次的发现，不要报告三次。
-
按精确结构书写发现：ID、标题、严重级别（CRITICAL | HIGH | MEDIUM | LOW | INFO）、置信度（HIGH | MEDIUM | LOW）、类别、受影响工件、位置、描述、证据、攻击场景、潜在影响、现有缓解、建议修复、建议验证、所需变更类型。纪律：没有结合本项目实际背景的论证，就不提高严重级别；没有项目证据的纯假设发现不写；若信息不足以确认真实漏洞，设置 Confidence: LOW 并明确说明缺少什么信息，既不夸大置信度显得彻底，也不丢弃该发现。
-
分诊——分配所需变更类型，每条发现恰好一个：CODE FIX、TEST FIX、SPEC CHANGE、DESIGN / ADR CHANGE、PRODUCT / REQUIREMENT CHANGE、PROCESS / HARNESS CHANGE、ACCEPT RISK。该技能无权更改产品范围、架构、ADR、业务决策，也无权代表用户接受风险。任何标记为 DESIGN / ADR CHANGE、PRODUCT / REQUIREMENT CHANGE 或 ACCEPT RISK 的发现，都必须明确列入报告的治理/需决策章节，需要人类决定，绝不静默解决。
-
避免误报——质量优于数量。不报告：伪装成漏洞的风格偏好、无项目证据的纯理论问题、重复项、项目其他地方已缓解的问题、与此具体系统无关的控制。一份简短的真实发现报告胜过被噪音填充的长报告——填充会让团队不再阅读安全报告。
-
撰写报告：在项目根目录按 assets/report-template.md 写 SECURITY-REPORT.md，包含执行摘要、安全优势、发现、优先级、治理/需决策事项。
【输出】 SECURITY-REPORT.md——项目中不改变其他任何内容。该技能只写这一个报告文件，绝不触碰代码、规格、配置或文档。
【质量门】 返回前静默检查：发现阶段确实先行发生，第 2 步的分析基于第 1 步建立的模型，而非对代码的通用审查；项目中真实存在的每一层都已审查，因缺少材料而跳过的层被明确说明而非静默省略；每条发现都追溯到具体证据（文件、行、规格、需求），没有“因为理论上可能发生”而编造的内容；没有无正当理由的 CRITICAL/HIGH 严重级别；需要人类决策的发现已在治理/需决策中明确标记，没有一条被当作本技能有权处理而解决；项目本身未被改动——这是一次仅报告的操作。
【当前刻意不做的事】 它按需运行、直接调用。其各部分（发现、逐层分析、发现结构、分诊）设计为日后可接入代码审查、PR 检查、CI/CD 或新规格工作流，但该接线不属于本技能。不要投机性地构建它；当确有自动运行而非按需运行的真实需求时再添加。