使用 Ostorlab 以发布速度进行持续的移动安全测试
Bumble 在每次 iOS 和 Android 发布中都会使用包括 Ostorlab 在内的多种工具组合来验证安全性，这些工具直接嵌入其发布流程中。扫描通过 CI 触发的工作流持续运行，并辅以计划扫描，确保 Bumble 在应用随时间推移发生变更时进行安全评估，而不仅仅是在重大里程碑节点。
移动产品团队发布频繁。Bumble 需要一种在平衡安全风险和产品节奏的同时，验证每次发布安全性的方法。该方法必须支持以下要求：
- 在多个应用和产品团队中保持一致的扩展能力
- 规范扫描内容、运行时间以及哪些问题会阻止发布的期望标准
- 避免因低风险发现而阻止发布，同时仍确保这些问题得到修复
- 减少分类过程中的可变性和模糊性，使工程师能够快速推进
发布工作流中的持续安全测试
Bumble 一贯在 iOS 和 Android 发布流程中运行安全扫描。这主要通过 CI 触发的扫描 完成，并辅以 计划扫描 来维持持续覆盖。
这种模式有助于确保团队持续评估应用不断演变的攻击面，而不是仅仅依赖于最后一刻的手动审查。
基于严重程度的发布门禁
Bumble 使用明确的防护措施来保护用户，同时不会减缓产品交付速度。
- 高危或严重级别发现： 发布将被阻止，直到修复完成并确认问题已解决
- 中危、低危或信息级别发现： 发布不会自动被阻止；补救工作将通过修复流水线创建并优先处理
这种方法避免了因低严重程度发现而导致的停线情况，同时确保问题仍能被跟踪和处理。
Bumble 在其产品组合中遵循相同的总体安全测试流程。标准化来源于：
- 在所有应用中运行相同的 CI 触发扫描和计划扫描
- 应用集中的严重程度阈值，以便各团队的发布决策保持一致
- 使结果可预测，从而让团队知道将运行什么扫描、什么构成阻止项，以及非阻止项的发现将如何处理
这减少了不同应用和团队之间的可变性，并有助于在无需为每个产品重新设计流程的情况下扩展安全实践。
通过使用一致的扫描方法和集中的严重程度阈值，我们减少了应用之间和团队之间在解释和处理发现结果时的可变性。
— Bumble
对于 Bumble 而言，自动化需要在不增加人员编制的情况下缩短周期时间。这要求不仅仅是运行静态检查。它需要具备相关性、可重复性并专为快速分类而设计的测试。
要求 1：执行应用的测试
Bumble 强调，自动化的持续安全测试必须智能地执行应用并以可控的方式进行模糊测试，而不是仅仅依赖于静态分析。
要求 2：与真实端点的相关性
一个关键要求是能够针对 Bumble 自身的端点进行测试，以确保结果对于工程团队而言具有相关性和可操作性。
要求 3：从摘要到原始证据的追溯能力
Bumble 还强调了在两个层面的溯源性：
- 高层次概览： 运行了什么、测试了哪些端点以及尝试了哪些技术
- 完整的原始证据： 详细日志显示了确切的请求、Payload、响应和采取的步骤，以便工程师可以快速重现和验证
这通过减少分类过程中的猜测和反复沟通，支持更快的修复。
通过安全测试左移并 持续使用 Ostorlab，Bumble 增强了信心，即在发布时，其公开提供的移动应用的攻击面不包含明显、易于利用的缺陷。
在运营方面，将持续扫描嵌入流程中同时支持速度和安全目标：
- 在执行明确防护措施的同时保持发布节奏
- 仅针对高危和严重级别的发现阻止发布
- 在整个应用组合中保持对风险的一致可见性
将持续扫描嵌入到我们的流程中，同时支持速度和安全目标。
— Bumble
代码变更通过正常的移动端发布流程推进
CI 触发的安全扫描持续运行，并辅以计划扫描
使用集中的严重程度阈值评估发现结果
高危或严重级别的发现将阻止发布，直到修复并验证完毕
中危、低危和信息级别的发现将被路由到修复流水线
工程师使用扫描摘要及原始证据高效地进行重现和修复
Bumble 的案例展示了如何将移动安全测试作为持续实践进行运营。通过明确的发布防护措施、跨团队的标准扫描以及证据丰富的追溯能力，安全成为产品交付的内置能力，而不是最后一刻的检查点。