security-gate

安全门

两个小任务：（1）在用户仍在选择功能时应用 threat-model-lite，这样后续阶段就不会猜测安全决策；（2）对每个切片应用 deep-pass trigger 列表，然后根据这些决策验证深度审查切片。此技能不会执行审查——由 full-review 负责。

以下两个术语是你工作时使用的名称：threat-model-lite 问题是你现在要向用户提出的问题；deep-pass trigger 是会在之后触发更深入审查的变更属性。

Threat-model-lite — 规格阶段检查清单（交互式）

在需求访谈期间运行此流程。根据证据确认仓库事实，只将尚未解决的安全决策加入访谈待处理列表。这些问题共用五个问题的限制；不要发送第二批问题。使用 shared/references/answer-evidence.md 记录答案，以确定可移植的来源权威性。to-prd 会将它们带入 PRD 的 Security Decisions 部分。

通过稳定 ID 和来源索引引用复用已记录的决策。每个切片仍需单独评估自己的深度审查触发条件；共享决策不代表共享风险分类。对于非实质性细节，仅使用安全且范围明确的默认值。只有当答案会改变访问权限、数据处理方式、范围、成本、允许的影响，或尚未解决的安全决策时才提问。沉默不代表批准。

1. 参与者与身份验证：谁可以调用此功能？哪些角色／权限控制每项操作？未经身份验证或角色不符的访问会发生什么？
2. 不可信输入：哪些数据来自用户或外部系统？在哪里进行验证，哪些内容会被拒绝？
3. 数据敏感性：是否涉及个人身份信息（PII）、凭据、令牌或财务数据？这些数据存储、记录或发送到哪里？哪些内容绝不能出现在日志或错误消息中？
4. 密钥：是否有新的密钥、令牌或凭据？它们存放在哪里（环境变量、密钥管理器），由谁轮换？
5. 依赖项：是否有新的软件包或服务？为什么选择它？如果遭到入侵，影响范围有多大？
6. 租户与访问范围：一个用户的请求是否可能读取或写入另一用户的数据？由什么机制强制执行边界？
7. 滥用：恶意或粗心的用户会如何利用此功能？是否需要速率限制、配额或幂等性？
8. 故障暴露：出错或超时时，会泄露什么（堆栈跟踪、内部 ID、部分写入）？

Deep-pass triggers（确定性）

在任务规划时，如果切片涉及以下任一事项，则标记为 security: deep：

• 身份验证、授权、会话或权限逻辑
• 解析或反序列化不可信输入（请求正文、文件上传、webhook、用于查询的查询参数）
• 密钥、令牌、凭据或密码学
• PII 或受监管数据，或与其相关的日志内容
• 新的第三方依赖项或外部服务集成
• CORS、CSP、安全标头、Cookie、重定向
• SQL／NoSQL 查询构造、Shell 命令构造，或使用变量进行模板渲染
• 数据库迁移或数据回填
• 根据用户输入派生的文件系统路径

否则标记为 security: standard。

验证时，使用 full-review 审查每个 deep 切片，并设置 security_focus=true，同时传入已记录的安全决策。将这项聚焦审查纳入已批准的审查者计划。只要审查覆盖相同的最终代码和风险，这项审查可以在任务完成时进行，也可以在功能审查期间进行；若证据没有变化，不要重复审查。standard 切片使用常规的限定范围审查，无需额外评审小组。如果实现扩大了切片范围，请重新检查触发条件；标记可以升级，但不得降级。

对于阶段边界，请阅读 shared/references/workflow-stage-routing.md：访谈收集决策，PRD 保留这些决策，任务规划对切片进行分类，实现阶段验证结果。

输出约定

在规格阶段，将已回答的决策字段写入现有决策记录中的稳定决策 ID 下，并注明来源权威性、定位信息和内容修订版本。将这些引用作为 security_decisions 返回给 PRD。在规划阶段，按切片返回 security: deep|standard，并注明匹配的触发条件。在验证阶段，返回交给 full-review 的优先级指示。

注意事项

1. 不要例行询问清单中的全部八个问题，只询问该功能涉及的问题。
2. 不要在自主阶段降低 deep 标记；规划之后，标记只能升级。
3. 不要在此处重复审查内容；问题、漏洞利用和修复应归入 full-review。