sdd-full 1.0.0 → 1.2.0

package/skills/security-audit/SKILL.md

@@ -0,0 +1,384 @@
+---
+name: "security-audit"
+description: "安全审计技能，分析安全需求、设计安全架构、执行安全检查。Invoke when you need to do security audit and hardening."
+---
+
+# security-audit - 安全审计技能
+
+## 概述
+
+本技能专注于系统安全审计和加固，包含安全需求分析、安全架构设计、安全检查清单、渗透测试方案、漏洞修复流程、安全培训等。
+
+---
+
+## 与其他技能的衔接
+
+### 前置技能
+- **sdd**（安全需求分析）
+- **quality-gate**（安全检查）
+
+### 后置技能
+- 安全持续改进
+
+---
+
+## 核心功能
+
+### 1. 安全需求分析
+- 数据安全需求（加密、脱敏、备份）
+- 认证授权需求（登录、权限、会话）
+- 接口安全需求（鉴权、限流、防攻击）
+- 合规性需求（等保、GDPR等）
+- 安全分级（按资产重要程度）
+
+### 2. 安全架构设计
+- 安全架构设计（分层防御、纵深防御）
+- 认证方案设计（密码、OAuth、SAML、生物认证）
+- 权限模型设计（RBAC、ABAC等）
+- 数据加密方案（传输加密、存储加密）
+- 安全监控设计（日志、告警、审计）
+
+### 3. 安全检查清单
+- OWASP Top 10检查清单
+- 代码安全检查清单
+- 配置安全检查清单
+- 依赖安全检查清单
+- 运维安全检查清单
+
+### 4. 渗透测试方案
+- 渗透测试计划
+- 测试范围定义
+- 测试方法选择
+- 测试用例设计
+- 风险分级
+
+### 5. 漏洞修复流程
+- 漏洞分级（Critical/High/Medium/Low）
+- 修复时限要求
+- 修复方案设计
+- 修复验证方法
+- 应急响应流程
+
+### 6. 安全培训材料
+- 开发安全培训
+- 运维安全培训
+- 员工安全意识培训
+- 常见攻击识别和防范
+- 应急响应培训
+
+---
+
+## 产出文件结构
+
+### 安全审计目录
+```
+docs/
+  └── security/
+      ├── requirements.md          # 安全需求
+      ├── architecture.md          # 安全架构
+      ├── checklist.md            # 检查清单
+      ├── pentest-plan.md          # 渗透测试方案
+      ├── vulnerability-fix.md     # 漏洞修复流程
+      └── training.md            # 安全培训
+```
+
+---
+
+## 安全审计模板
+
+### 安全需求分析模板
+```markdown
+# 安全需求分析
+
+## 1. 资产清单
+| 资产名称 | 重要程度 | 风险等级 | 说明 |
+|---------|---------|---------|------|
+| 用户数据 | Critical | 高 | 包含手机号、邮箱、密码等 |
+| 订单数据 | High | 中高 | 包含交易记录 |
+| 系统配置 | Medium | 中 | 包含敏感配置 |
+
+## 2. 安全需求
+
+### 数据安全
+- [ ] 敏感数据加密存储
+- [ ] 敏感数据传输加密（TLS）
+- [ ] 敏感数据脱敏显示
+- [ ] 数据备份加密
+- [ ] 数据访问审计日志
+
+### 认证授权
+- [ ] 强密码策略
+- [ ] 多因素认证（可选）
+- [ ] 会话超时控制
+- [ ] 权限最小化原则
+- [ ] 权限变更审计
+
+### 接口安全
+- [ ] 接口鉴权
+- [ ] 接口限流
+- [ ] 防SQL注入
+- [ ] 防XSS攻击
+- [ ] 防CSRF攻击
+
+### 合规性
+- [ ] 符合等保要求
+- [ ] 符合GDPR（如需要）
+- [ ] 符合其他行业标准
+
+## 3. 风险评估
+| 风险 | 等级 | 可能性 | 影响 | 应对措施 |
+|-----|------|-------|------|---------|
+| 数据泄露 | Critical | 低 | 极高 | 加密、访问控制、监控 |
+| 未授权访问 | High | 中 | 高 | 强认证、权限控制 |
+```
+
+---
+
+### 安全检查清单模板
+```markdown
+# 安全检查清单
+
+## OWASP Top 10检查
+
+### A01:2021 - Broken Access Control
+- [ ] 权限验证正确实现
+- [ ] 垂直权限隔离正确
+- [ ] 水平权限隔离正确
+- [ ] 敏感接口有权限控制
+
+### A02:2021 - Cryptographic Failures
+- [ ] 敏感数据加密存储
+- [ ] 使用强加密算法
+- [ ] 密钥管理安全
+- [ ] TLS正确配置
+
+### A03:2021 - Injection
+- [ ] 所有查询参数化
+- [ ] 防止SQL注入
+- [ ] 防止XSS注入
+- [ ] 防止其他注入
+
+### A04:2021 - Insecure Design
+- [ ] 有安全威胁建模
+- [ ] 安全需求明确
+- [ ] 有安全架构设计
+
+### A05:2021 - Security Misconfiguration
+- [ ] 安全配置正确
+- [ ] 不必要的功能禁用
+- [ ] 默认密码已修改
+- [ ] 错误信息不泄露细节
+
+### A06:2021 - Vulnerable and Outdated Components
+- [ ] 依赖定期扫描
+- [ ] 高危依赖已修复
+- [ ] 不再使用的依赖已移除
+- [ ] 依赖更新策略
+
+### A07:2021 - Identification and Authentication Failures
+- [ ] 认证实现正确
+- [ ] 会话管理安全
+- [ ] 凭据存储安全
+- [ ] 有防止暴力破解措施
+
+### A08:2021 - Software and Data Integrity Failures
+- [ ] 数据完整性校验
+- [ ] 第三方来源可信
+- [ ] 有完整性验证机制
+
+### A09:2021 - Security Logging and Monitoring Failures
+- [ ] 关键操作有日志
+- [ ] 安全事件有告警
+- [ ] 日志内容完整
+- [ ] 日志存储安全
+
+### A10:2021 - Server-Side Request Forgery
+- [ ] 防止SSRF攻击
+- [ ] 外网请求有控制
+- [ ] URL验证正确
+
+## 代码安全检查
+- [ ] 无硬编码密钥
+- [ ] 无SQL注入风险
+- [ ] 无XSS风险
+- [ ] 输入验证完整
+- [ ] 输出编码正确
+
+## 配置安全检查
+- [ ] 生产环境配置安全
+- [ ] 不必要的端口已关闭
+- [ ] 服务以最小权限运行
+- [ ] 防火墙规则正确
+
+## 依赖安全检查
+- [ ] 依赖漏洞已扫描
+- [ ] 高危漏洞已修复
+- [ ] 依赖定期更新
+```
+
+---
+
+### 渗透测试方案模板
+```markdown
+# 渗透测试方案
+
+## 1. 测试概述
+- 测试目标
+- 测试范围
+- 测试时间
+- 测试人员
+
+## 2. 测试方法
+- 黑盒测试/白盒测试
+- 测试工具选择
+- 测试策略
+
+## 3. 测试范围
+
+### 测试范围
+- 测试的系统/应用
+- 测试的接口
+- 测试的功能模块
+
+### 不测试范围
+- 生产环境直接攻击（用测试环境）
+- 可能导致服务不可用的测试（提前沟通）
+
+## 4. 测试用例
+| 用例ID | 测试项 | 测试方法 | 预期结果 |
+|-------|--------|---------|---------|
+| TC-001 | SQL注入 | 尝试注入 | 无注入漏洞 |
+| TC-002 | XSS | 尝试注入脚本 | 无XSS漏洞 |
+| ... | ... | ... | ... |
+
+## 5. 风险分级
+| 等级 | 说明 | 处理时限 |
+|-----|------|---------|
+| Critical | 严重漏洞，可导致数据泄露或系统控制 | 24小时内修复 |
+| High | 高危漏洞 | 3天内修复 |
+| Medium | 中危漏洞 | 1周内修复 |
+| Low | 低危漏洞 | 1个月内修复 |
+
+## 6. 测试计划
+| 阶段 | 时间 | 内容 |
+|-----|------|------|
+| 阶段1 | ... | 信息收集 |
+| 阶段2 | ... | 漏洞扫描 |
+| 阶段3 | ... | 手动测试 |
+| 阶段4 | ... | 报告编写 |
+```
+
+---
+
+### 漏洞修复流程模板
+```markdown
+# 漏洞修复流程
+
+## 1. 漏洞上报
+- 漏洞描述
+- 漏洞等级
+- 影响范围
+- 上报时间
+- 上报人
+
+## 2. 漏洞确认
+- 验证漏洞真实性
+- 确认漏洞影响
+- 评估风险等级
+- 确认修复优先级
+
+## 3. 修复方案设计
+- 修复方案选择
+- 修复方案评估
+- 回滚方案准备
+- 修复时间计划
+
+## 4. 修复实施
+- 代码修复
+- 配置修复
+- 测试验证
+- 代码评审
+
+## 5. 发布上线
+- 修复上线计划
+- 灰度发布
+- 监控观察
+- 完整验证
+
+## 6. 复盘总结
+- 漏洞根因分析
+- 预防措施
+- 流程改进
+- 经验教训
+```
+
+---
+
+## 使用步骤
+
+### 步骤1：安全需求分析
+- 识别系统资产
+- 分析安全需求
+- 评估安全风险
+- 确定安全目标
+
+### 步骤2：安全架构设计
+- 设计安全架构
+- 选择安全方案
+- 制定安全规范
+- 设计安全监控
+
+### 步骤3：安全检查
+- 执行安全检查清单
+- 代码安全扫描
+- 依赖安全扫描
+- 配置安全检查
+
+### 步骤4：渗透测试（可选）
+- 制定渗透测试方案
+- 执行渗透测试
+- 生成测试报告
+- 制定修复计划
+
+### 步骤5：漏洞修复
+- 按优先级修复漏洞
+- 验证修复效果
+- 复盘总结
+- 持续改进
+
+---
+
+## 与其他技能的集成
+
+### 与quality-gate集成
+```
+security-audit → 安全检查清单 → quality-gate → 安全检查
+```
+
+### 与sdd-test集成
+```
+security-audit → 安全测试SDD → sdd-test → 安全测试
+```
+
+---
+
+## 最佳实践
+
+1. **安全左移：** 开发阶段就考虑安全，不要等上线后再补
+2. **纵深防御：** 不要只依赖单一安全措施，多层防护
+3. **最小权限：** 只给必要的权限，权限最小化原则
+4. **定期审计：** 定期执行安全检查，不要一次就完
+5. **全员重视：** 安全不只是安全团队的事，全员要有安全意识
+
+---
+
+## 常见问题
+
+### Q：需要做渗透测试吗？
+A：核心业务、敏感数据系统建议定期做；一般系统可以先用自动化工具扫描。
+
+### Q：发现高危漏洞怎么办？
+A：按应急响应流程，快速评估影响，先做临时防护，再彻底修复，修复后验证，最后复盘。
+
+### Q：如何平衡安全和用户体验？
+A：在保证安全的前提下尽量不影响体验，选择对用户影响小的安全方案，做好用户引导。

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: systematic-debugging
+description: 在遇到任何错误、测试失败或意外行为时使用，在提出修复方案之前
+---
+
+# 系统性调试
+
+## 概述
+
+随机修复浪费时间并创建新错误。快速补丁掩盖潜在问题。
+
+**核心原则：** 在尝试修复之前始终找到根本原因。症状修复是失败。
+
+**违反此流程的字面意思就是违反调试的精神。**
+
+## 铁律
+
+```
+没有根本原因调查，就没有修复
+```
+
+如果你还没有完成第 1 阶段，你不能提出修复方案。
+
+## 何时使用
+
+用于任何技术问题：
+- 测试失败
+- 生产中的错误
+- 意外行为
+- 性能问题
+- 构建失败
+- 集成问题
+
+**特别使用当：**
+- 在时间压力下（紧急情况使猜测变得诱人）
+- "只需一个快速修复"看起来很明显
+- 你已经尝试了多个修复
+- 之前的修复不起作用
+- 你不完全理解问题
+
+**不要跳过当：**
+- 问题看起来简单（简单错误也有根本原因）
+- 你很匆忙（匆忙保证返工）
+- 经理希望立即修复（系统性比混乱更快）
+
+## 四个阶段
+
+你必须完成每个阶段才能进入下一个阶段。
+
+### 阶段 1：根本原因调查
+
+**在尝试任何修复之前：**
+
+1. **仔细阅读错误消息**
+   - 不要跳过错误或警告
+   - 它们通常包含确切的解决方案
+   - 完全阅读堆栈跟踪
+   - 注意行号、文件路径、错误代码
+
+2. **一致地重现**
+   - 你能可靠地触发它吗？
+   - 确切的步骤是什么？
+   - 它每次都会发生吗？
+   - 如果不可重现 → 收集更多数据，不要猜测
+
+3. **检查最近的更改**
+   - 什么更改可能导致此问题？
+   - Git diff，最近的提交
+   - 新依赖项，配置更改
+   - 环境差异
+
+4. **在多组件系统中收集证据**
+
+   **当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：**
+
+   **在提出修复之前，添加诊断工具：**
+   ```
+   对于每个组件边界：
+     - 记录什么数据进入组件
+     - 记录什么数据离开组件
+     - 验证环境/配置传播
+     - 检查每层的状态
+
+   运行一次以收集显示它在哪里中断的证据
+   然后分析证据以识别失败的组件
+   然后调查该特定组件
+   ```
+
+   **示例（多层系统）：**
+   ```bash
+   # 第 1 层：工作流
+   echo "=== 工作流中可用的密钥：==="
+   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
+
+   # 第 2 层：构建脚本
+   echo "=== 构建脚本中的环境变量：==="
+   env | grep IDENTITY || echo "IDENTITY 不在环境中"
+
+   # 第 3 层：签名脚本
+   echo "=== 钥匙串状态：==="
+   security list-keychains
+   security find-identity -v
+
+   # 第 4 层：实际签名
+   codesign --sign "$IDENTITY" --verbose=4 "$APP"
+   ```
+
+   **这揭示：** 哪一层失败（密钥 → 工作流 ✓，工作流 → 构建 ✗）
+
+5. **跟踪数据流**
+
+   **当错误在调用堆栈深处时：**
+
+   请参阅此目录中的 `root-cause-tracing.md` 了解完整的向后跟踪技术。
+
+   **快速版本：**
+   - 坏值源自哪里？
+   - 什么用坏值调用了这个？
+   - 继续向上跟踪直到找到源
+   - 在源处修复，而不是在症状处
+
+### 阶段 2：模式分析
+
+**在修复前找到模式：**
+
+1. **找到工作示例**
+   - 在同一代码库中定位类似的工作代码
+   - 什么与损坏的代码类似但能工作？
+
+2. **与参考进行比较**
+   - 如果实现模式，完全阅读参考实现
+   - 不要浏览 - 阅读每一行
+   - 在应用前完全理解模式
+
+3. **识别差异**
+   - 工作的和损坏的之间有什么不同？
+   - 列出每个差异，无论多小
+   - 不要假设"那不重要"
+
+4. **理解依赖关系**
+   - 这需要其他哪些组件？
+   - 需要什么设置、配置、环境？
+   - 它做了什么假设？
+
+### 阶段 3：假设和测试
+
+**科学方法：**
+
+1. **形成单一假设**
+   - 明确说明："我认为 X 是根本原因，因为 Y"
+   - 写下来
+   - 具体，不要模糊
+
+2. **最小测试**
+   - 做最小可能的更改来测试假设
+   - 一次一个变量
+   - 不要一次修复多个问题
+
+3. **继续前验证**
+   - 它工作了吗？是 → 阶段 4
+   - 没工作？形成新假设
+   - 不要在上面添加更多修复
+
+4. **当你不知道时**
+   - 说"我不理解 X"
+   - 不要假装知道
+   - 寻求帮助
+   - 研究更多
+
+### 阶段 4：实施
+
+**修复根本原因，不是症状：**
+
+1. **创建失败测试用例**
+   - 最简单的可能复现
+   - 尽可能自动测试
+   - 如果没有框架，使用一次性测试脚本
+   - 修复前必须有
+   - 使用 `superpowers:test-driven-development` 技能编写适当的失败测试
+
+2. **实施单一修复**
+   - 解决已识别的根本原因
+   - 一次一个更改
+   - 没有"顺便"改进
+   - 没有捆绑重构
+
+3. **验证修复**
+   - 测试现在通过了吗？
+   - 没有其他测试损坏？
+   - 问题实际解决了？
+
+4. **如果修复不起作用**
+   - 停止
+   - 计数：你尝试了多少个修复？
+   - 如果 < 3：返回阶段 1，用新信息重新分析
+   - **如果 ≥ 3：停止并质疑架构（见下面的步骤 5）**
+   - 不要在没有架构讨论的情况下尝试修复 #4
+
+5. **如果 3+ 修复失败：质疑架构**
+
+   **表明架构问题的模式：**
+   - 每个修复都揭示不同地方的新共享状态/耦合/问题
+   - 修复需要"大规模重构"来实现
+   - 每个修复都在其他地方创建新症状
+
+   **停止并质疑基础：**
+   - 这个模式从根本上是否健全？
+   - 我们是否"仅仅因为惯性而坚持它"？
+   - 我们应该重构架构还是继续修复症状？
+
+   **在尝试更多修复之前与你的人类伙伴讨论**
+
+   这不是失败的假设 - 这是错误的架构。
+
+## 红旗 - 停止并遵循流程
+
+如果你发现自己在想：
+- "现在快速修复，以后调查"
+- "只需尝试更改 X 看看是否有效"
+- "添加多个更改，运行测试"
+- "跳过测试，我会手动验证"
+- "可能是 X，让我修复它"
+- "我不完全理解，但这可能有效"
+- "模式说 X 但我会以不同方式适应它"
+- "这里是主要问题：[列出没有调查的修复]"
+- 在跟踪数据流之前提出解决方案
+- **"再尝试一次修复"（已经尝试了 2+）**
+- **每个修复都揭示不同地方的新问题**
+
+**所有这些都意味着：停止。返回阶段 1。**
+
+**如果 3+ 修复失败：** 质疑架构（见阶段 4.5）
+
+## 你的人类伙伴的信号你做错了
+
+**注意这些重定向：**
+- "那不是发生了吗？" - 你未经验证就假设
+- "它会告诉我们...？" - 你应该添加证据收集
+- "停止猜测" - 你在不理解的情况下提出修复
+- "超级思考这个" - 质疑基础，而不仅仅是症状
+- "我们卡住了？"（沮丧）- 你的方法不起作用
+
+**当你看到这些：** 停止。返回阶段 1。
+
+## 常见的合理化
+
+| 借口 | 现实 |
+|------|------|
+| "问题简单，不需要流程" | 简单问题也有根本原因。流程对简单错误很快。 |
+| "紧急情况，没时间流程" | 系统性调试比猜测和检查的混乱更快。 |
+| "先试试这个，然后调查" | 第一个修复设定模式。从一开始就做对。 |
+| "我会在确认修复有效后写测试" | 未经测试的修复不会持久。先测试证明它。 |
+| "一次多个修复节省时间" | 无法隔离什么有效。导致新错误。 |
+| "参考太长，我会适应模式" | 部分理解保证错误。完全阅读它。 |
+| "我看到问题了，让我修复它" | 看到症状 ≠ 理解根本原因。 |
+| "再尝试一次修复"（2+ 失败后） | 3+ 失败 = 架构问题。质疑模式，不要再修复。 |
+
+## 快速参考
+
+| 阶段 | 关键活动 | 成功标准 |
+|------|----------|----------|
+| **1. 根本原因** | 阅读错误，重现，检查更改，收集证据 | 理解 WHAT 和 WHY |
+| **2. 模式** | 找到工作示例，比较 | 识别差异 |
+| **3. 假设** | 形成理论，最小测试 | 确认或新假设 |
+| **4. 实施** | 创建测试，修复，验证 | 错误解决，测试通过 |
+
+## 当流程揭示"无根本原因"时
+
+如果系统性调查揭示问题确实是环境性、时间依赖性或外部的：
+
+1. 你已经完成了流程
+2. 记录你调查了什么
+3. 实施适当的处理（重试，超时，错误消息）
+4. 添加监控/日志以便将来调查
+
+**但：** 95% 的"无根本原因"案例是调查不完整。
+
+## 支持技术
+
+这些技术是系统性调试的一部分，在此目录中可用：
+
+- **`root-cause-tracing.md`** - 通过调用堆栈向后跟踪错误以找到原始触发器
+- **`defense-in-depth.md`** - 在找到根本原因后在多个层添加验证
+- **`condition-based-waiting.md`** - 用条件轮询替换任意超时
+
+**相关技能：**
+- **superpowers:test-driven-development** - 用于创建失败测试用例（阶段 4，步骤 1）
+- **superpowers:verification-before-completion** - 在声称成功之前验证修复有效
+
+## 现实影响
+
+来自调试会话：
+- 系统方法：15-30 分钟修复
+- 随机修复方法：2-3 小时混乱
+- 首次修复率：95% 对 40%
+- 引入的新错误：几乎为零对常见