赶在攻击之前发现漏洞。

一个 SaaS 产品并不仅仅由可公开访问的端点组成。不同的角色、邀请机制、导出功能、后台任务和管理功能，共同构成了业务逻辑。因此，在测试之前，我们会先明确哪些流程尤其需要保护，以及应用程序应当强制执行哪些边界。这种视角是对传统技术检测的补充：一个功能即使在形式上响应正确，也仍可能允许执行一项并非为当前登录用户或其租户所设计的操作。

在此基础上，会形成一份协商一致的测试范围。黑盒、灰盒或白盒测试的具体组合，会根据目标和可获得的信息来选择。如果提供源代码或架构文档，就能更有针对性地解读观察结果。检测聚焦于获得授权的应用程序，并使用商定好的账户和数据。工具给出的检测发现，不会未经评估就直接被当作已确认的漏洞；其影响和前提条件必须让您的团队能够清楚理解。

对于 SaaS 和 PaaS 而言，责任边界至关重要。检测您的应用程序或配置，并不自动等同于获准攻击平台运营方的基础设施。我们会共同确定测试目标、允许采用的方法以及所需的审批。API 和集成接口会依据预定的数据和权限范围进行检测。我们尤其关注不同角色和租户，在实际应用路径中是否始终保持可靠隔离。

遗留软件通常需要采用不同的方法。文档可能并不完整，测试环境可能只能部分反映生产环境的实际状态，个别组件对负载也可能较为敏感。这些情况需要在开始前就纳入规划：我们会商定测试时间窗口、可随时联系的联系人以及中止标准。如果某项检测无法以稳妥的方式开展，这一局限会在结果中明确体现。这样一来，测试所能得出的结论，以及哪些方面还需要进一步调查，都能保持清晰。

一份报告应当能够支撑决策，并帮助开发团队完成修复。因此，一项已确认的检测发现，会描述受影响的版本、所需的前提条件、商定的验证方式以及可能造成的影响。管理层和技术团队所需的详细程度并不相同。优先级排序会结合应用场景，而不是简单地生成一长串权重相同的问题清单。验证材料会被限制在必要范围内，并通过商定的渠道，提供给具备相应权限的联系人。

修复方案会与您的团队共同讨论，约定的复测则会评估具体变更的效果。然而，一项检测发现被修复，并不意味着整个应用程序就此不存在任何漏洞：新的版本发布和配置变更都可能改变原有状况。如有需要，这也可以发展为针对重要变更的定期检测。对于合适且边界清晰的目标，还可以商定采用 Result as a Service 模式：报酬将取决于事先定义并经过验证的结果。