谁会委托进行渗透测试
某个客户、保险公司或审计人员希望获得独立证据，证明确实有人尝试过侵入您的产品，而您需要能够据以行动的发现，而不是一份扫描器打印件。
- 面临企业客户安全审查的 SaaS 公司
- 希望先获得攻击者视角的支付或健康类产品发布团队
- 云端配置快速增长、却从未经过独立测试的公司
典型的范围与交战规则
以下是某个 Web 产品的示意性范围；您的范围会在测试开始前商定并签署。
范围之内
- 使用您提供的测试账户，针对 Web 应用及每个用户角色
- 公开 API 以及您移动应用所调用的后端
- 指定的云账户：存储、身份设置和对外暴露的服务
- 作为触及数据或工具途径的聊天机器人或智能代理功能
范围之外
- 可能扰乱真实用户的拒绝服务或负载
- 针对您员工的钓鱼或社会工程，除非另行商定
- 对办公室、设备或网络的物理访问
- 未经所有者许可、您并不拥有的第三方服务
交战规则
- 指明目标、测试账户和来源 IP 地址的已签署授权
- 为生产环境商定的测试时间窗口；在具有代表性之处使用预发布环境
- 双方各自指定的联系人，在测试进行期间可以联系到
- 严重发现立即上报，而不是留到最终报告
- 测试结束时移除测试账户和上传的测试数据
以攻击者的视角审视你的产品
扫描器发现已知模式；攻击者则把一个个小弱点串联起来。渗透测试，即经授权的道德黑客攻击，会展示你的 Web 应用、API、移动后端或云设置中哪些弱点真正可被利用，以及攻击者能够触及什么。它在产品发布、客户安全审查或审计之前都很有用。我们只在你批准的书面范围和交战规则内开展工作，默认使用非破坏性技术，并为每一项发现提供证据、复现步骤和修复指导。
AI 辅助侦察，人工主导利用
AI 如何协助
- 加快侦察：在约定范围内绘制路由、参数、技术栈和暴露的服务。
- 对扫描器输出进行分类，剔除重复项和可能的误报，使测试人员专注于真正的线索。
- 根据应用的角色、工作流和已知弱点模式，提出攻击路径和测试用例。
- 起草发现报告和修复指导，供测试人员核实和完善。
我们的专家负责什么
- 范围、交战规则和测试时间窗口会在任何测试开始之前以书面形式与你约定。
- 测试人员亲自执行每一个利用步骤。AI 工具不会在无人监督的情况下对你的系统采取行动。
- 测试人员串联各项发现，判断其在现实中的影响，并决定哪些值得报告。
- 严重程度反映的是攻击者在你的环境中能够触及什么，而非某个通用的评分。
您将获得什么
限定范围的测试、清晰的证据和重新测试
Web 应用测试
遵循 OWASP 测试指南，测试身份验证、访问控制、注入、跨站脚本、请求伪造和业务逻辑缺陷。
API 渗透测试
REST 和 GraphQL API 中的对象级和功能级授权失效、批量赋值、注入以及令牌弱点。
云与基础设施审查
你的云环境中暴露的服务、网络规则、存储权限、身份与访问设置以及泄露的机密。
AI 功能测试
聊天机器人、智能体及其他 LLM 功能中的提示注入、通过回答造成的数据泄露，以及过于宽泛的工具或数据权限。
基于证据的报告
一份执行摘要加上技术性发现，每一项都附有证据、复现步骤、严重程度、影响和修复指导。
对修复的重新测试
在你修复各项发现之后，我们会对每一项重新测试并更新报告，这样你就能展示哪些问题已经关闭。
一次渗透测试如何进行
- 01
范围与规则
约定目标、环境、测试账户、测试时间窗口和联系人。书面授权在测试开始前就位。
- 02
侦察
在范围内绘制攻击面，包括路由、API、角色、技术栈和暴露的服务，并辅以 AI 分析。
- 03
受控利用
测试人员尝试在不造成损害的前提下利用弱点，一旦有任何可能影响实时用户或数据的情况，就停下来与你联系。
- 04
报告与重新测试
交付基于证据的发现及修复指导，向你的团队逐一讲解，并在修复部署后进行重新测试。
典型的渗透测试请求
我们所界定范围的典型场景，而非客户案例研究。
为企业采购方提供的测试报告
一家 SaaS 公司的新客户在签约前要求提供近期的独立测试。我们界定该客户将使用的产品领域，对其进行测试，并提供一份其安全团队可以审阅的报告，并在复测后更新。
仓促搭建的云账户
一个小团队迁移到了云端，并按需授予权限。我们从外部以及从一个低权限账户进行测试，看看存储、密钥或管理控制台是否可被触及，以及入侵者能够横向移动到多远。
可能累积叠加的小弱点
某个 Web 应用存在无人优先处理的小问题：冗长的错误信息、薄弱的重置流程、可猜测的 ID。我们测试它们是否会串联成账户接管，并通过证据报告该串联链条，以及能够打断它的最简单修复方案。
渗透测试的局限性
- 测试人员会沿着测试时间窗口内开放的攻击路径进行；之后的发布版本以及范围之外的系统仍可能存在弱点。
- 跨角色、逐端点的授权测试属于 API Security；渗透测试把 API 视为一条进入路径。
- 某个 AI 功能是否回答得当，以及在模型或提示词更改后是否仍能保持如此，属于 AI Evaluation & Testing；我们把它作为一个入口点来测试。
- 逐行阅读源代码属于 Code Audit & Review；在这里测试人员攻击的是正在运行的系统。
安全测试如何与设计、QA 和运维相衔接
设计：保持可用的安全
涉及更改登录、账户恢复或权限的修复会与你的设计师共同设计，这样安全性就不会让产品变得更难使用。
QA：持久有效的修复
我们的工程师可以帮助修复发现，QA 则会添加回归测试，防止日后的某次更改重新引入同样的弱点。
运维：检测，而不仅仅是预防
各项发现会反馈到你云设置的日志记录、告警和加固中，这样你的团队就更有可能察觉正在进行的攻击。
持续：重大变更后重新测试
在重大发布、新集成或基础设施变更之后，按与你约定的计划进行重新测试，使你的安全全景保持最新。
常见问题
常见问题解答
渗透测试会干扰我们的用户吗？
我们默认使用非破坏性技术，在具有代表性的预发布环境中测试，并为生产环境约定测试时间窗口。如果某项操作看起来有风险，测试人员会停下来，先联系你指定的负责人，再继续进行。
一次渗透测试需要多长时间？
这取决于纳入范围的应用程序数量、用户角色和环境。在一次范围界定沟通后，我们会在工作开始前与您商定固定的范围、测试时间窗口和报告日期。
渗透测试能让我们达到合规吗？
没有任何测试能单凭自身使产品达到合规。我们为您的合规工作提供支持：报告的撰写方式便于审计人员和您客户的安全团队审阅，复测结果则显示哪些发现已经关闭。
我们的发现和数据如何处理，包括由 AI 工具处理的情况？
发现只会通过范围界定时商定的渠道，送达您指定的联系人。AI 辅助分析在您所选择的边界内运行：在您掌控的基础设施上或我们商定的隔离环境中进行的 私有 / 本地 AI 工程，或是在商定的提供商数据处理与保留条款下进行的 Claude Code / OpenAI Codex 工程。
