为什么你需要一份 DevSecOps Playbook？
很多团队在推行 DevSecOps 时，最大的障碍不是工具，而是缺少一份可执行的“剧本”。Playbook 不是安全策略文档，而是一套可重复、可度量的操作流程，让开发、运维和安全团队在同一个节奏上工作。
如果你刚开始接触这个领域，建议先阅读我们的 DevSecOps & Secure Delivery 知识中心，了解核心理念。
Playbook 的核心模块
1. 安全左移：从需求阶段开始
- 威胁建模：每个用户故事或功能模块在进入开发前，由安全工程师与开发一起完成轻量级威胁建模（例如 STRIDE 或 OWASP 方式）。
- 安全验收标准：在 Definition of Done 中增加安全条目，例如“无已知高危漏洞”“敏感数据已脱敏”。
2. CI/CD 管道中的安全门
- SAST/DAST 自动化：每次代码提交触发静态扫描（SAST），构建后运行动态扫描（DAST）。阻断规则：高危漏洞直接失败构建。
- 依赖扫描：使用 OWASP Dependency-Check 或 Snyk 检查第三方库，每周更新漏洞库。
- 容器镜像签名：所有生产镜像必须经过签名和漏洞扫描，未签名镜像无法部署。
3. 持续验证与响应
- 运行时监控：部署后启用 RASP 或 WAF，记录异常行为并触发告警。
- 安全仪表盘：为每个团队提供可视化的安全指标（漏洞修复时长、扫描通过率等）。
可操作的验证清单
以下是我们为客户实施 DevSecOps 时使用的核心检查项，你可以直接复制到自己的 Sprint 回顾中使用：
- 每个新功能是否已完成威胁建模？
- 代码提交前是否运行了 SAST？结果中是否有 Critical/High 未处理？
- 构建产物是否经过依赖扫描？是否存在已知的 CVSS 7+ 漏洞？
- 容器镜像是否签名？基础镜像是否更新到最新补丁？
- 生产环境是否启用了运行时保护（RASP/WAF）？
- 安全告警是否在 4 小时内被确认？
这份清单来自我们的 Secure Delivery 服务 实战积累，你可以根据团队成熟度逐步增加项目。
常见问题
Q: 我们团队只有 5 个人，有必要搞 Playbook 吗？ A: 有必要。Playbook 的规模可以裁剪，哪怕只有威胁建模 + 依赖扫描两条规则，也比没有强。关键是形成习惯，而不是追求工具数量。
Q: Playbook 应该由谁来维护？ A: 建议由 DevSecOps 工程师或安全 champion 负责，但内容需要开发团队共同 review。每季度根据新威胁和工具更新一次。
Q: 如果 CI 管道因为安全扫描变慢怎么办？ A: 可以分层执行：提交阶段只跑快速 SAST（5 分钟内），夜间运行完整 DAST 和依赖扫描。同时优化扫描规则，排除非关键路径。