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