yiming-Falcon YM PM Safety
让项目在需求、设计、开发、上线和重大变更阶段都经过与风险相称的安全闸门。默认安全、最小权限、最少数据，但避免把所有项目机械套进同一张重型清单。
工作原则
- 先识别资产、数据流、信任边界和最坏后果，再检查具体控制。
- 区分
已验证、基于材料推断、尚未提供证据，不得把配置声明当作实际生效。 - 优先修复可被利用且影响大的问题，不用大量低价值建议淹没阻断项。
- 代码、配置和架构默认采用安全选项；不得以“先跑通”为由关闭认证、HTTPS、CSRF、输入验证或权限控制。
- 法律与标准可能更新。涉及真实上线、跨境、敏感个人信息、金融、医疗、未成年人或重大合同责任时，核验当前官方规则，并建议由合格法务或安全负责人最终确认。
1. 确定审查阶段
选择最贴近当前任务的闸门：
- 前期筛查：判断项目是否涉及个人信息、敏感数据、外部系统、付费接口和高风险自动化。
- 设计审查：检查数据流、信任边界、权限模型、威胁模型、数据存储和第三方依赖。
- 开发审查：审查代码、配置、依赖、密钥、日志、认证、输入输出和测试证据。
- 上线审查：检查生产配置、域名与 TLS、权限、备份恢复、监控告警、应急预案和回滚。
- 重大变更审查：新增数据用途、模型、连接器、外部接收方、权限、自动执行能力或公开范围时重新评估。
如果只是概念讨论且没有代码或系统方案，只做前期筛查，不输出虚假的“已实现”。
2. 做风险分级
按最高命中项定级：
| 等级 | 典型场景 | 最低审查深度 |
|---|---|---|
| L0 | 本地实验、虚构数据、不联网、不共享 | 快速红线检查 |
| L1 | 内部低敏资料、只读辅助、结果由人复核 | 前期筛查 + 核心控制 |
| L2 | 真实个人信息、外部用户、第三方 API、付费调用、可写业务系统 | 设计 + 开发 + 上线审查 |
| L3 | 敏感个人信息、未成年人、金融/医疗、跨境、高权限 Agent、支付或不可逆自动化 | 完整威胁建模、专项合规评估、独立复核和明确授权 |
风险不明时向上取一级，并把缺失证据列为待确认项。
3. 收集最小证据
优先读取或询问：
- 系统边界、用户角色和关键业务动作。
- 数据类型、来源、用途、保存位置、保存期限、接收方和删除方式。
- 架构图或数据流、API、认证和授权设计。
- 代码仓库、依赖清单、部署配置、环境变量样例和
.gitignore。 - 日志、监控、备份、恢复、应急和回滚方案。
- SAST、依赖扫描、密钥扫描、DAST 或渗透测试结果。
没有证据时标记 ⚠️ 未验证，不要标记 ✅ 已实现。
4. 执行审查
根据系统表面选择性读取 references/security-review-checklist.md：
- 涉及个人信息、出境或数据共享：读取数据合规部分，并核验 references/compliance-baseline.md。
- 涉及 Web/API：执行认证授权、注入、XSS/CSRF、响应头、限流和错误处理检查。
- 涉及 AI/Agent：执行提示注入、工具权限、RAG 数据边界、模型输出和自动执行检查。
- 涉及代码和部署：执行密钥、依赖、供应链、日志、生产配置和恢复检查。
适用时优先采用当前稳定的 OWASP Top 10、OWASP API Security Top 10、OWASP ASVS 和 AI/LLM 专项标准。引用具体要求时写明版本。
5. 应用阻断规则
发现以下任一情形，结论至少为 🔴 阻断，在修复或取得合格负责人明确风险接受前不得建议上线：
- 真实密钥、Token、Cookie、密码、数据库凭证出现在前端、仓库、日志或交付物中。
- 关键对象或管理功能缺少服务端身份认证与对象/功能级授权。
- 敏感操作可由未受信输入、模型输出或提示文本直接触发，且没有权限约束与人工确认。
- 敏感个人信息处理缺少明确目的、合法基础、必要性或适用的单独同意/影响评估。
- 个人信息出境事实不清或适用机制尚未评估，却准备向境外服务发送真实数据。
- 登录、验证码、支付、AI/付费 API 或资源密集型接口没有合理的限流、配额或滥用防护。
- 生产环境关闭 HTTPS/证书校验、暴露调试信息、使用默认口令或允许公开访问管理接口。
- 存在可直接利用的高危注入、任意文件访问、SSRF、远程代码执行或严重供应链风险。
6. 输出审查报告
仅在 Skill 被用于安全审查、代码生成或系统设计时使用以下结构。普通项目讨论不强制展开 13 项表格。
# 安全审查结论
结论：通过 / 有条件通过 / 阻断 / 证据不足
风险等级：L0 / L1 / L2 / L3
审查范围：...
## 【安全自检表】
| 检查项 | 状态 | 证据 | 问题与动作 |
|---|---|---|---|
| 数据最小化与合法基础 | ✅/⚠️/❌/N/A | ... | ... |
## 【阻断项】
## 【整改或代码实现】
## 【风险提示】
## 【合规说明】
## 【验证记录】
在报告末尾按 references/pm-handoff-contract.md 输出或更新 pm_handoff。存在阻断项或证据不足时，将 next_gate 保持为 ym-pmsafety；通过后根据项目状态转向 ym-pmclean 或 none。
状态含义：
✅：有代码、配置、测试或运行结果支持。⚠️：需要配置、补证、人工授权或进一步核验。❌：未满足且构成缺陷。N/A：确实不适用，并说明理由。
代码实现要带有解释“为什么需要该控制”的简短安全注释。没有代码任务时，将该节改为“整改方案”，不要为了满足格式虚构代码。
7. 验证与收口
- 能运行时执行最小验证：测试、lint、SAST、依赖审计、密钥扫描、配置检查或 HTTP 响应头检查。
- 不能运行时说明缺少的环境、权限或样本，以及尚未验证的结论。
- 整改后重新检查阻断项，不以“代码已修改”代替验证。
- 最终记录剩余风险、风险接受人、复查时间和触发重新审查的条件。
与相邻 Skill 的边界
ym-pmintake：前期业务需求澄清，只做轻量安全筛查并发现是否需要专项审查。ym-pmsafety：设计、代码、部署、数据与自动化权限的专项安全审查。ym-pmclean：项目文件、文档和交接一致性，不负责证明系统安全。ym-workspace：工作空间结构与治理，不替代单个产品的安全评估。