渗透测试合同：范围、交战规则与验收标准

一份可执行的渗透测试合同，应当在测试人员发送第一个请求之前回答一个实际问题：谁可以在什么时间，以哪些方法，对哪个资产的哪个版本执行哪些动作，以及什么证据代表工作已经完成？ 仅有主服务协议通常回答不了这些问题。采购方需要把法律条款、工作说明书（SOW）、书面授权和交战规则（ROE）组成一个完整文件包。

本文是面向采购方的操作清单，不是适用于任何司法辖区的法律范本。合同效力、责任分配、保密、知识产权、隐私、劳动与行业规则，以及当地的授权要求，应由法律顾问确认；安全负责人和产品负责人则要把技术边界写成测试人员能够执行的指令。这两类工作都不可缺少，但不能相互替代。

签署一组相互衔接的文件，而不是一张含糊的订单

主服务协议通常承载长期适用的法律条件，包括合同主体、费用、付款、保证、责任限制、保密、适用法律、分包和终止。SOW把采购转化为一个明确项目：目标、服务内容、时间表、依赖条件、交付物、验收程序、复测权益和变更控制。如果测试证据可能包含个人数据，还可能需要数据处理协议。ROE则是测试人员、值班工程师和事件响应人员在执行期间共同使用的操作边界。

ROE应当在开测前签署，或者被合同明确引用并纳入。它需要列出授权组织、测试团队、责任联系人、范围内与排除的系统、测试流量来源、日期和时段、允许与禁止的动作、生产保护措施、停止与恢复规则、证据处理和报告要求。NIST SP 800-115（2008年）附录B提供了ROE检查清单。使用时要结合项目和现行平台政策调整，它不是完整的现代技术测试目录。

不要把操作授权藏在“测试该应用”这样的概括性文字中。执行期间，测试人员可能需要出示授权副本和联系人信息。反过来，也不要利用ROE临时改写责任限制或客户数据权利。每项决定都应放在其责任人可以审阅和批准的文件里。

让范围可以执行：资产、环境、版本和身份

一个主机名并不是完整目标。每个资产至少要记录所有者、环境、稳定标识符、网络边界、应用或API版本、相关构建号或提交标识、租户或云账号/项目、必要时的区域，以及提供给测试的身份角色。还要记录测试源IP或其他标记，让防守团队能够区分授权流量；任何可能收到流量的依赖项，即使不是直接目标，也要列明。

范围应说明采用黑盒、灰盒还是白盒方式，是否提供源代码或架构材料，有哪些用户角色和测试租户，以及是否允许社会工程、口令攻击、持久化、文件上传、数据修改、横向移动或破坏性动作。明确的排除清单与纳入清单同样重要。当企业使用第三方SaaS、共享托管、托管服务、合作伙伴API或集团内其他公司的系统时，“全部公司基础设施”既不明确也不安全。

项目启动时要冻结测试基线。持续发布的生产系统可以在SOW中约定发布截止点或指定构建，并要求采购方披露测试窗口中的部署。某项变化看起来很小，并不表示它自动包含在原范围中。变更流程要明确谁能提出和批准变更，需要什么影响分析，何时重签ROE或授权，以及如何记录工期和费用。新域名、新租户、新API、新流量来源、新测试方法或实质版本变化，都应进入该流程。

Pentest.red范围规划器可以把初始资产清单整理为讨论材料，但仍需补充明确的所有者和批准。如果采购方还在选择服务商，应使用单独的基于证据的渗透测试服务商比较框架，不要把供应商筛选标准混进ROE。

单独检查云平台和第三方许可

客户不能授予自己并不拥有的权限。拥有一款应用，并不自动代表可以测试云服务商控制平面、支付处理商、属于其他主体的CDN租户、上游身份服务或其他客户的数据。应建立权限矩阵：每个所有者或平台一行，记录适用政策、获准资源与技术、通知或审批凭据，以及最后检查政策的日期。

当前主要云平台的官方规则说明，“允许进行云测试”这种通用条款远远不够。根据AWS的标准渗透测试政策，只有列出的客户服务可以在无需预先审批的情况下评估；客户不得测试AWS基础设施或AWS服务本身，包含Command and Control的安全测试需要预先批准，DoS技术被禁止，相关模拟则受另一套平台规则约束。Microsoft表示，客户自己的Azure资源可以在无需预先审批的情况下测试；但第三方测试人员必须取得资源所有者的明确书面授权，所有测试仍受Microsoft ROE约束；一旦测试触及Microsoft自身服务漏洞或未授权数据，就必须停止。Google Cloud表示测试客户自己的项目不需要提前通知，但必须遵守Acceptable Use Policy和服务条款，并确保测试只影响该客户自己的项目，不能影响其他客户的应用。

这些政策会变化。SOW应要求在执行前进行带日期的检查，而不是把今天的服务清单永久复制进多年合同。目标若涉及SaaS、托管服务、经销商、合作伙伴集成或集团内另一主体的基础设施，就应取得相应所有者的许可，否则将目标排除。还要指定谁负责向平台通知、谁保管平台回复。

在生产环境中建立真正的停止和恢复路径

“发生事故就停止”不是一个操作程序。应定义可观察的停止触发条件，例如错误率或延迟异常、意外数据访问、服务不稳定、客户事件指挥官发出指令、疑似越界、发现独立攻击者，或者平台服务商联系客户。列出可以要求立即停止的人、全天可用的沟通渠道、确认要求，以及停止后测试人员要做什么。如果继续执行可能扩大损害，技术负责人应有权先停下，再完成记录。

恢复测试必须由指定的客户角色作出明确决定。恢复记录要包含事件或症状、受影响资产、停止前的最后一个测试动作、保存的证据、已实施的缓解措施、调整后的方法或窗口，以及批准恢复的人。沉默、暂停时间结束或交接班都不能视为授权。如果测试从预发布转到生产、从人工验证转到高流量自动化，或从最小证明转到横向移动，不仅要批准恢复，还必须通过变更审批。

1. 签署完成主协议、SOW、所有者授权和ROE，并核对第三方及平台限制。
2. 冻结范围记录资产、版本、身份、排除项、源系统、方法、窗口和联系人。
3. 执行监控生产影响，保留快速停止路径，并明确批准变更或恢复。
4. 验收检查覆盖、证据、限制和交付质量，不以漏洞数量计价。
5. 复测在指定修复构建上验证约定发现，并给出受条件约束的结论。

除非检测能力本身就是经约定的测试目标，客户安全运营团队应知道测试来源和窗口。ROE还要说明测试地址是否加入允许列表，以及怎样区分授权活动和真实入侵。这些是生产控制措施，不是合同装饰语。

从采集到删除都要控制证据

渗透测试证据可能包含凭据、个人数据、会话令牌、配置、源码片段、客户记录，以及可被攻击者利用的弱点地图。ROE和数据条款应规定允许采集的内容、数据最小化和脱敏规则、批准的存储与传输渠道、加密要求、访问角色、处理地点、保留期限、法律保留例外、备份处置，以及触发归还或删除的事件。“稍后安全删除”留下了太多不确定性。

采购方可以要求一份证据清单，把每项发现与受影响资产和测试条件关联起来，同时避免重复保存不必要的敏感内容。双方还应决定：原始工具输出、截图、概念验证代码、请求/响应、日志和测试账号是正式交付物，还是服务商保留的工作底稿。若服务商使用分包商或托管协作系统，这些数据路径需要写入法律和数据文件。结项时应撤销凭据、删除测试账号与文件、清理客户环境中的测试产物，并取得约定的销毁确认。

报告应通过受控渠道交付，而不是普通邮件附件。客户要指定报告接收者和标准副本的负责人。在定稿SOW之前，可以先查看渗透测试样例报告和实用渗透测试报告应包含什么，以便把真正需要的内容写进验收条款。

按质量和覆盖验收，不按漏洞数量验收

发现数量不是可靠的验收指标。高质量测试完全可能只产生少量发现；低质量测试也可能用重复项和信息噪声堆出很大的数字。不要把付款绑定到最低漏洞配额、承诺的严重漏洞，或所谓“零问题”结果。验收应判断服务商是否完成了约定工作，并交付可用、可追溯的证据。即使没有发现漏洞，只要覆盖、方法、限制和证据记录达到约定标准，报告仍可能合格；这并不等于系统没有漏洞。

合同应设置审阅期和一次汇总意见流程。验收可以要求：资产和冻结版本正确；覆盖记录将项目标为已测试、不适用、受阻或未测试；列出日期和测试人员；说明方法与重大限制；提供管理层摘要；每项去重发现包含受影响资产、前提条件、证据、影响推理、严重性理由、复现和修复建议；紧急通知有记录；证据和产物状态明确。OWASP的报告指南同样将管理层摘要、测试参数与限制、技术发现和修复细节区分开来。

接受报告不表示客户同意每一个风险评分，也不表示客户承诺修复每个问题。报告验收、漏洞是否修复、企业是否接受剩余风险，是三个独立决定。合同可以把必须由服务商纠正的文档缺陷，与双方善意的技术分歧分开；后者应保留双方理由。如果双方约定“逾期视为接受”，建议明确只有在客户已通过可访问渠道收到全部必需文件之后，计时才会开始。

把复测定义为有条件的验证

复测不是无限制的第二次项目。SOW应说明包含几个轮次、提前预约要求、最终报告后的可用窗口、哪些发现符合条件、必要时的最大投入、客户需要提供什么修复已部署证据，以及错过窗口会怎样。还应说明是否测试通过同一控制路径的相关变体，以及验证时发现的新弱点如何处理。

复测也要冻结基线：发现编号、修复构建或提交、环境、配置、账号角色和日期。结果应受到条件约束，例如“在已测试条件下已修复”“未修复”“部分修复”“因前提条件不可用而无法验证”或“未测试”。不要写无条件的“已修复”。架构变化、新增端点、迁移到另一个云平台或扩展到同类系统，通常属于变更请求，而不是免费复测范围。关于如何保持证据链，可参阅渗透测试修复验证指南。

示例采购：Northstar Tickets

以下场景完全虚构，仅用于说明。Northstar Tickets准备在发布前采购一次测试。文件包包括现有主服务协议和数据条款、项目SOW、由指定资源所有者签署的授权，以及作为附件的ROE。范围包括生产环境的portal.example.invalid版本2026.10-rc3、生产环境的api.example.invalid及API模式3.14.2，以及预发布环境的Android候选版本；移动端以包名和构建哈希唯一标识。登记表列出两个测试租户、客户提供的普通用户与客服角色、服务商源地址，以及承载应用资源的指定AWS账号。公司官网、支付处理商、客服SaaS、AWS服务基础设施、员工钓鱼、DoS和其他所有租户均被排除。

允许的方法包括人工Web和API测试、以约定速率进行的有限自动发现、跨角色授权验证、文件上传验证、非破坏性的影响证明，以及对指定Android候选版本进行人工客户端测试，包括本地存储、深链接和与范围内API的交互。禁止持久化、提取真实客户记录、口令喷洒、修改生产环境中的真实客户数据、越出指定应用账号的横向移动和服务中断。文件上传验证仅使用两个获准测试租户中的合成文件，清理方式须提前约定。客户事件指挥官和服务商负责人都可立即停止工作；完成恢复记录后，只有事件指挥官或指定代理可以书面批准恢复。

启动时，产品团队建议加入beta-api.example.invalid。它不在授权中，而且使用不同部署。服务商不会“顺便看一眼”。客户提交变更请求，写明资产所有者、构建、数据分类、AWS资源边界、测试方法、速率、增量投入和修订计划。只有授权批准人更新范围和ROE后，测试才会开始。

交付物包括范围与覆盖登记、重大问题紧急通知、报告草案、结果说明会、最终报告、证据清单和一份复测备忘录。在这个虚构例子中，Northstar有五个工作日提交汇总意见；这是双方约定的项目条件，并非通用法定期限。验收条件是：资产和版本相符，受阻与未测试部分可见，每项发现可用脱敏证据复现，严重性有理由，约定文件可使用。没有最低发现数量。文档缺陷需要纠正，业务影响分歧则单独记录，不应扣住整个交付物。

双方约定，最终报告后第三十个日历日之前可以预约一次复测，前提是Northstar提供已部署修复的构建标识和可用账号。这个期限同样只是示例中的商务条件。复测覆盖报告发现和经约定、经过同一控制路径的变体。新的移动版本或无关端点需要变更请求。备忘录必须给出确切构建和测试条件，不能把有限验证写成产品没有其他漏洞的保证。

在提供访问权限之前讨论验收

协商报告质量、证据处理、复测条件和变更批准的最佳时机，是测试人员取得访问权限之前。让采购、资源所有者、安全运营、事件响应、产品工程、隐私和法律团队共同走读文件，并要求每个人实际作出项目中会遇到的决定。如果答案仍依赖给一个不在联系人清单中的人打电话，ROE就还没有准备好。

如果独立评估符合采购方的实际需要，Pentest.red可以讨论拟定范围以及渗透测试服务。在排期之前，应书面约定资产、版本、操作边界、交付物、验收检查和复测条件。项目目标应当是受控执行和可用证据，而不是承诺任何有限测试能够发现所有漏洞。