摘要：分阶段方法
这种循序渐进的方法帮助您顺利推出安全工具，并保持构建运行。可以将其视为一系列小步骤，保护您的交付，确保开发过程更加可靠和安全。
| 扫描模式 | 开发人员影响 | 配置/设置 | 目的与结果 |
|---|---|---|---|
| 爬行开放失败（审计模式，无警报） | 无干扰；对开发人员不可见 | 每次推送/提交时扫描，记录发现 | 收集数据，调整规则，抑制误报；构建始终通过 |
| 行走开放失败（通知模式，警报） | 开发人员在PR/IDE中看到警告 | 启用PR装饰/IDE插件 | 开发人员收到可操作的反馈，建立信任，自愿修复问题 |
| 运行关闭失败（阻止模式） | 构建因高/关键问题被阻止 | 激活质量门，阻止构建新关键发现 | 防止新漏洞进入生产；开发人员尊重失败 |
介绍：为什么“大爆炸”推出失败
一个DevSecOps项目可能会因“大爆炸”推出而迅速偏离轨道。这通常发生在团队获得新的SAST或容器扫描工具并立即开启“阻止模式”时。例如，XYZ公司的一支软件开发团队曾在第一天启用他们的新扫描工具的“阻止模式”。
一夜之间，该工具标记了数百个需要紧急关注的小型安全问题，实际上停止了他们整个开发过程。
随着开发人员争先恐后地解决这些问题，关键项目截止日期被错过，导致对工具的失望和信任的丧失。这个场景突显了风险，并说明了为什么需要更渐进的方法。
结果通常会导致问题：
- 构建失败：开发人员无法部署关键修复。
- 警报疲劳：大量误报使团队不堪重负。
- 影子IT：沮丧的团队绕过安全检查以保持工作进度。
为了避免这些问题，采取渐进的方法，而不是试图一次性改变一切。这就是爬行、行走、奔跑框架的意义所在。
最近的研究表明，实施分阶段推出的组织在部署频率和更快的故障恢复方面有显著改善，从而提高了其DevSecOps实践的可靠性。
通过将此框架与经过验证的性能结果联系起来，例如减少停机时间和增加构建成功率，我们可以确保工程领导者认识到其价值。
阶段1：爬行（可见性和基线）
目标： 在不干扰开发人员工作流程的情况下，全面了解现有技术债务。力争在前两周内实现90%的仓库覆盖率，以确保可衡量的成功和明确的进度基准。
- 在初始阶段，通过将安全工具以非侵入方式集成到您的CI/CD管道中，专注于数据收集。
- 配置：将工具设置为开放失败模式，使用审计模式记录所有发现，而不通知开发人员或阻止构建。
- 操作：在每次代码推送或提交时触发扫描。
- 结果：扫描器将所有发现记录到仪表板，同时允许所有构建成功通过，即使检测到关键漏洞。
💡 专业提示：利用这个阶段仔细调整您的扫描器。如果某个特定规则（例如“代码中的魔法数字”）触发过多噪音（例如在仓库中触发500次），考虑调整或暂时禁用它，以便在继续前专注于可操作的问题。
为什么这很重要： 建立这个“安全基线”可以让您的安全团队了解现有技术债务的数量和性质，并在不影响部署的情况下优化规则配置。
阶段2：走（反馈与教育）
目标： 为开发人员提供可操作的、及时的安全反馈，集成到他们的日常工作流程中，而不阻碍开发进度。
- 一旦噪声减少，就将发现结果展示给开发人员。保持工具处于开放失败模式，但通过启用警报切换到通知模式。
- 配置：将反馈集成到开发工具中，如拉取请求装饰（评论）或IDE插件。
- 结果：开发人员在代码审查过程中实时接收安全反馈，例如，“⚠️ 高严重性：在第42行引入了硬编码秘密。”
开发人员可以选择立即修复问题或记录误报以便稍后解决。
**为什么这很重要：**这个阶段建立了安全与开发人员之间的信任。安全被视为合作的指导者，而不是守门人。开发人员习惯于工具的存在，并开始自愿修复问题，因为反馈循环是直接且可操作的。
为了加强这些积极行为，鼓励团队庆祝早期的胜利。分享快速成功故事，例如“第一个PR合并时没有高严重性发现”，可以建立势头并推动更多开发人员自愿修复问题。
阶段3：运行（门控与执行）
**目标：**通过执行安全门控，防止新的高风险漏洞进入生产环境。
- 在调整和教育开发人员之后，激活构建中断器或质量门，通过阻止具有关键问题的构建来执行策略。
- 配置：将工具设置为关闭失败模式，以阻止具有高和关键严重性漏洞的构建。中等和低严重性问题仍作为警告，以避免过度干扰。
- 重要细节：考虑仅阻止当前更改引入的新漏洞（例如，在当前 PR 中），同时将现有问题作为待处理项目进行跟踪，以便随着时间的推移进行修复。
- 结果：如果开发人员引入了例如一个关键的SQL 注入漏洞，构建将失败，无法合并，直到修复或获得批准的文档豁免。
为什么这很重要：因为工具和团队经过良好的调整和教育，误报率很低。开发人员尊重构建失败作为真正的安全信号，而不是与之抗争。
接下来
现在您有了一个分阶段的策略来决定何时阻止构建，下一步是决定在哪里集成这些工具以最大化开发人员的生产力。
在下一篇文章中，我们将探讨无摩擦安全，一种将安全工具无缝嵌入开发人员 IDE 和 PR 工作流的方法，减少上下文切换并提高采用率。
常见问题解答 (FAQ)
什么是“爬行、行走、奔跑”框架？
这是一种简单的分步方法，可以开始使用新的安全工具而不会引起问题。首先，您悄悄地收集信息（爬行）。接下来，您向开发人员展示问题，以便他们可以学习并解决这些问题（行走）。最后，您阻止不良代码以确保软件安全（运行）。这有助于团队顺利采用安全工具，并在过程中获得信任。
为什么不应该立即阻止构建？
如果从第一天开始阻止构建，工具可能会一次标记太多问题，阻止开发人员进行工作。这可能会导致挫败感并减慢项目进度。慢慢开始意味着您首先找到并解决噪声警报，因此只有当工具准确且值得信赖时才会发生阻止。
每个步骤应该持续多长时间？
通常，爬行阶段持续几周，以便收集足够的数据。行走阶段需要更多时间，因为开发人员习惯于看到警报并解决问题。只有当工具调试良好且团队在代码合并之前能够舒适地解决问题时，才移动到运行阶段。
什么是“开放失败”，我们何时使用它？
“开放失败”意味着工具发现问题但不会阻止代码合并。在爬行和行走阶段使用此方法，以避免在收集数据和教导开发人员问题时打扰他们。
