如何选择渗透测试服务商：从实质出发比较供应商

先讲一个明确标为虚构的故事，用来说明一种可能发生的采购失误。一家做企业开票服务的小型 B2B 平台即将与一家大客户签约，对方要求提供独立渗透测试的结果。研发负责人向三家公司发出询价，收到了三份整齐的方案。三份方案都写着"依据 OWASP Top 10 进行人工测试"，都列出"信息收集—测试—报告"三个阶段，工期相近，还都附上了一份精美的样例报告。团队选了回复最快的那一家。报告按时交付，里面有几个中危问题，全部修复，客户也很满意。

半年后，一位外部研究人员报告：只要修改请求中的一个标识符，就能通过公开 API 读取其他组织的发票。双方商定的范围写的是"Web 应用"，没有单独列出 API，并且只提供了一个租户下的一个账号。因此，已完成的工作没有明确测试、也无法充分证明跨租户隔离。单账号测试仍可能发现公开可达的 API 缺陷，但无法系统覆盖不同租户之间的角色和对象。三份方案看起来相同，其覆盖假设却仍不清楚。

这正是选择渗透测试服务商的真正难点。服务商之间的实质差异可能被报价方案的相似措辞掩盖。应从范围假设、方法论深度、证据质量、独立性、复测流程，以及服务商如何处理你的数据等方面寻找差异。下面介绍如何把这些差异摆到台面上，做出一个能向审计人员、管理层和自家工程师解释清楚的决定。本文不提供公司排名，也不谈价格：这是一套适用于任何候选名单的比较方法。

为什么渗透测试方案无法直接比较

方案措辞经常集中在同样的词语上：OWASP、人工测试和带修复建议的报告。这些标签本身并不能说明计划开展的工作是否等价。"全面的 Web 应用测试"这句话没有承诺任何可衡量的东西：相对什么而言的全面？覆盖多少个角色？哪些接口？哪个环境？如果第一天就发现测试环境与生产环境差别明显，又会怎样？

第二个原因是信息不对称。服务商清楚自己的工作哪里扎实、哪里单薄，而采购方只能看到文字。因此，采购方的任务不是挑出最有说服力的文本，而是提出合适的问题、索取合适的证据，让每个候选者的长处和短板都同样清晰可见。

第三个原因是计量单位不一致。一家按人天报价，一家按应用数量，还有一家按 IP 地址或 API 端点数量。在确定统一的范围和统一的覆盖描述方式之前，价格和工期的比较并不可靠：这些方案可能描述的是名称相同、内容不同的工作。

从范围入手：你到底在买什么

比较最先在范围上失效，因为每家服务商都会按自己的理解去填补空白。所以第一步是撰写一份统一的范围文件，原样发给所有候选者。文件中列出系统和接口——Web 客户端、公开和内部 API、移动客户端、管理后台——需要使用的角色和租户、环境、排除项、测试时间窗口以及期望的成果形式。

如果范围还比较模糊，最好在发出询价之前先梳理清楚——例如可以与 Pentest.red 团队一起讨论：纳入哪些系统和角色、有意排除哪些内容、最终需要什么样的证据，都可以通过范围沟通表单记录下来。这并不能替代竞争性采购流程，但能让不同服务商的方案具备可比性。

角色、租户与业务逻辑

对于多用户产品，通常需要多个角色和至少两个受控租户，才能直接检验跨租户隔离。访问控制是核心问题之一。自动化扫描器可能漏掉上面发票案例那样的授权和逻辑缺陷，因为它未必知道对象应当属于谁；只用一个账号进行的测试无法覆盖同样的跨租户路径。如果产品中有复杂流程——退款、额度限制、多级审批、优惠码——应当在范围中明确写出。这类测试如何开展、如何采购，可参阅我们关于业务逻辑安全测试的文章。

测试环境还是生产环境

在具有代表性且隔离良好的测试环境中开展测试，可以降低对生产运行的影响，但测试环境并不天然属于低风险，结论也只适用于该环境。如果配置、组件版本、集成、WAF 规则或数据存在差异，结果就不能不加说明地套用到生产环境。应要求每家服务商比较两个环境、说明生产环境仍需进行哪些检查，并在报告中记录差异。

攻击者的起点

不带凭据的外部测试回答的是"外部人员能做什么"。assume-breach（假定已失陷）测试则从双方约定的失陷状态开始——例如一名普通员工的账号，或对某个容器的访问权限——并展示从那里出发还能做到什么。边界必须清楚：assume-breach 并不能证明初始访问在现实中一定能够获得，它只是把这种访问作为起始假设。如何界定这类工作的范围、能得出哪些结论，可参阅我们关于假定失陷安全评估的文章。

外部攻击面发现是另一种情况。过程中发现的域名和地址不能立即发起攻击：必须先确认它们归你所有，并且属于已授权的范围。愿意"顺便把发现的东西都测一遍"的服务商，体现的不是勤勉，而是缺乏纪律。

比较不同的服务形式，最方便的方法是看每一种真正能说明什么、不能说明什么。

方法论：是流程，而不是标准清单

许多方案都会列出 OWASP 和 NIST。问题不在于是否提到了某个标准，而在于它是否体现在测试计划、执行过程和报告之中。

测试流程与可衡量的覆盖

OWASP Web Security Testing Guide（WSTG）说明了如何测试 Web 应用；本文采用 WSTG 4.2。可靠的服务商会写明所遵循的 WSTG 版本和计划涵盖的测试类别，并解释哪些类别不适用于你的产品及其原因。

OWASP Application Security Verification Standard（ASVS）解决的是另一个问题——为安全控制措施设定可验证的要求。它所声明的目标，是通过一项开放且可用于商业的标准，使市场上参差不齐的覆盖范围和验证严格程度趋于规范。本文采用 ASVS 5.0.0；标准本身建议引用要求时带上版本号，格式类似 v5.0.0-1.2.5，因为不带版本的编号可能在不同版本之间发生变化。两份对应同一组 ASVS 要求的方案可以逐行比较；两份只写"全面测试"的方案则无法比较。

OWASP Top 10 的 2025 年版仍然是一份提高意识的文件，用于说明 Web 应用最关键的安全风险。它是一条有用的底线，但"已按 OWASP Top 10 测试"描述的是最低要求，而非完整覆盖。

测试技术及其局限

NIST SP 800-115 是 2008 年发布的一份信息安全测试与评估技术指南。它描述了评估的各个阶段——规划、执行以及执行后阶段，后者包括分析发现项和制定缓解策略——并强调每种技术的优势与局限。同时，该文件明确表示自己并不是一套完整的测试计划，而且它的年代也值得注意：面对现代 Web 技术，它提供的是工作框架，而不是检查清单。

对访谈的实际启示：请服务商说明它将对你的范围使用哪些技术，以及每种技术最可能遗漏什么。自动化扫描可以高效识别部分已知组件版本和常见配置错误；推理授权、业务逻辑以及多种机制的危险组合通常需要人工分析，具体方法组合取决于范围。如果只回答"我们有自研的新一代扫描器"而不谈局限，这本身就是一个值得重视的信号。

技术深度：访谈中要核实什么

与真正执行测试的人——而不仅仅是销售经理——进行一次简短的技术访谈，可以揭示整套文件没有写明的假设和局限。要问清楚具体由谁执行工作、是否有分包商参与、复测时是否仍由同一团队负责。

会话、跨源策略与安全头

HTTP 协议本身并不在请求之间保存状态，但这并不妨碍应用构建会话——包括服务器端会话：cookie 中只存放一个标识符，会话数据本身保存在服务器上。要询问团队如何检验会话的完整生命周期：会话标识固定、退出登录和修改密码时的会话撤销、cookie 属性、并发登录与过期时的行为。

这里也能看出测试人员是否理解各种防护机制的边界。CORS 决定的是来自其他源的浏览器脚本能否读取响应；它不是服务器端的授权机制，也拦不住从浏览器以外发出的 API 请求。Cross-Origin Resource Policy 可以阻止浏览器暴露或嵌入某些跨源 no-cors 响应；它并不是通用的请求拦截机制，请求本身仍可能到达服务器。Content Security Policy 能降低脚本注入的后果，但不能消除注入的成因。把这些概念混为一谈的测试人员，要么高估、要么低估发现项的严重程度——无论哪种情况，开发人员的时间都会花错地方。

凭据与服务商的访问权限

另一个话题是服务商如何获得访问权限。人工测试人员应当在系统支持时使用启用多因素认证的个人账号；对已认证用户流程的自动化可以使用权限受限的测试用户凭据。只有真正以工作负载身份运行的检测才可能需要最小权限的服务密钥或令牌，人工 MFA 并不适用于这类凭据。工作结束后应撤销测试访问；对仍然有效的凭据，则在存在泄露、复用风险或访问设计需要时进行轮换。"只读"访问本身并不意味着低风险：即使没有写入操作，读取配置、密钥或个人数据也可能造成严重影响。

报告是留在你手中的产品

项目结束后，报告会成为修复决策的主要输入之一。NIST SP 800-115 把分析发现项和制定缓解策略纳入评估流程，因此只罗列问题的报告没有完整运用这套评估逻辑，也不足以支持修复团队采取行动。

弱点类别与有证据支持的原因

将软件发现项映射到适用的 CWE 编号，可以为不同项目和服务商提供共同语言。CWE 描述的是弱点类别，不是被利用的可能性，也不能单独说明该产品中的具体成因。只有报告具备支持证据时，才应给出单独的原因说明，例如代码或可观察行为证明缺少对象归属校验，或用用户输入拼接命令。分类和成因都有证据支持时，二者可以指导更广泛的修复。解释反复出现的 CWE 模式时，仍需保证范围和测试方法可比。

结合攻击者视角确定优先级

一个没有解释的"高危"标签说明不了多少问题。优秀的报告会从可达性、攻击者所需权限、影响以及利用背景等方面论证严重程度。MITRE 发布的 2025 年 CWE Top 25 除主榜单外，还公布了 CISA Known Exploited Vulnerabilities（已知被利用漏洞）目录中漏洞所对应弱点的排名——这是此类背景信息的可能来源之一。如何基于这类数据确定优先级，在我们关于基于风险的漏洞优先级排序的文章中有详细讨论。

还有一条认真负责的服务商应当主动说明的限定：一次成功的复现证明问题是可能存在的，但并不能说明它出现或被利用的频率。

证据及其处理规范

复现步骤应当让你的团队能够在已授权的环境中安全地重复验证。同时，报告本身不能成为泄露源：证据中的令牌、密码和个人数据要做脱敏处理，测试日志要尽量精简，对它们的访问权限和保存期限要事先约定。请每个候选者提供一份脱敏的样例报告，并用同一张验收表对所有样例进行评分。

复测修复结果与相关缺陷路径

复测是各家服务商差异可能相当明显的一环，尽管方案中往往只用一行字带过。要问清楚：复测是否包含在工作内容中、提供几轮、修复之后多久可以进行，以及最终结论会怎么写。

合格的复测结论应与条件绑定：哪个构建版本、哪个环境、用什么方法验证。不附这些信息的"已修复"无法核实，也不能推及其他环境。复测应重复原始场景和商定的相关变体，使其经过同一修复机制，并记录未测试路径；有限的复测无法证明整个弱点类别已经消除。如果对操作系统命令注入的修复只是过滤掉某一个字符，其他语法形式仍可能被利用。即使不经过 shell、以独立数组的形式传递参数，如果用户能够提供一个会被程序解释为选项的值，也仍然无法防止参数注入。

这一思路与 CISA 的 Secure by Design（设计即安全）理念一致。该机构倡导在设计阶段就把安全纳入考量，以大幅减少可被利用的缺陷；其 Secure by Design 系列警示专门讨论了如何消除整类缺陷——跨站脚本、操作系统命令注入、目录遍历。建议写成"转义这个参数"而不是"消除这一类问题的成因"的服务商，给组织带来的价值更少。如何证明修复真正有效，可参阅我们关于渗透测试修复验证的文章。

独立性、数据与授权

比较服务商不止于技术层面。服务商会拿到凭据、弱点信息，还可能接触到个人数据，因此它自身的成熟度也是评估的一部分。CISA 的 Secure by Demand 指南是为与第三方供应商进行采购谈判的客户编写的，其思路在这里可以直接套用：要了解你托付访问权限的那一方有怎样的安全实践。

独立性

有必要弄清服务商是否在某种特定结果中存在利益。如果它同时销售安全产品或修复服务，这不构成拒绝的理由，但需要确认发现项和建议不是为了推销产品而量身定制的。另外要问清楚由谁执行工作——自有团队还是分包商——以及这一点在合同和保密协议中如何体现。

数据处理

向每家服务商提出相同的问题：凭据和测试产物存放在哪里、谁能访问、报告通过什么渠道交付、何时以及如何销毁所有这些内容、销毁如何得到确认。如果服务商无法具体回答，这本身也是一种回答。

每个有权授权一方的许可

只有在获得明确的书面授权，并约定好测试规则、测试时间窗口、升级联系人和数据处理条款之后，才可以开展测试。授权必须来自每一个有权给予授权的相关方：如果部分系统托管在云服务商、托管公司或 SaaS 合作伙伴处，或者产品属于集团内的另一家公司，也必须考虑它们的规则并取得其同意。选定服务商这件事本身并不授权任何测试。在这些文件办妥之前就愿意开工，是一个严重的警示信号。

不同服务商做法之间的权衡

没有哪一种形式在所有情况下都优于其他形式；关键是要明白你为所选的形式付出了什么代价。

用 OWASP Top 10 描述工作，便于向管理层沟通，但该文件是提高意识的清单，而不是完整的验证计划。与 ASVS 要求绑定可以得到可衡量的覆盖，但需要采购方投入精力：选择章节和级别、排除不适用的内容、商定状态标注方式。

服务商的自有方法论可能很强，但很难与他人的方法相比较。对于适用的 Web 和 API 工作，应要求每个候选者把方法映射到带版本号的 WSTG 类别和 ASVS 要求；对于移动端、云、基础设施和其他组件，则要求明确的技术标准与方法。服务商不必放弃自己的流程；这种映射和组件专用标准能让比较更容易。

一次性测试只是某个时间点的快照。NIST Cybersecurity Framework 2.0 将网络安全视为一种需要理解和管理的风险，而单次渗透测试只是这种管理的一个信息来源。对于发布频繁的产品，一种选择是把定期的广泛评估与针对具体安全相关变更的测试结合起来：新的认证方案、新的公开 API、数据存储模式的改变。这并不意味着每一次代码提交都需要一次付费渗透测试；如何筛选这类变更、如何采购此类工作，可参阅我们关于变更触发渗透测试的文章。

最后是参考依据的年代问题。SP 800-115 仍然有助于组织规划和分析工作，但它发布于 2008 年。至于检查的具体内容，更合理的做法是依据带版本号的 ASVS 5.0.0 和 WSTG，以及 2025 年版的 OWASP Top 10 和 CWE Top 25——每次都写明版本号，而不是写"最新版"。

渗透测试报告记录的是在约定范围、时间和方法下发现的问题，并不保证不存在其他漏洞。它可以作为更广泛符合性评估的一项证据；认证、鉴证或符合性意见仍是独立工作，其文件和出具方要求应与具备该类评估资质的专业人员另行确定。

向服务商提出的问题与警示信号

只有当所有候选者收到同一组问题、答案可以逐行比较时，这些问题才真正有效。对于适用的 Web 和 API 范围，请服务商说明 WSTG 版本和带版本号的 ASVS 要求；对于移动端、云、基础设施或其他组件，则要求明确的技术标准和方法。询问软件发现项在适用时如何映射到 CWE、CWE 不适用时采用什么分类，以及任何成因说明有哪些证据支持。还要询问利用背景如何影响修复顺序。了解将使用哪些技术，以及在你的范围内它们最可能遗漏什么。问清楚凭据、测试数据和报告如何保护、保存和销毁，复测包含哪些内容、结果如何记录。最后，询问结果将如何向管理层呈现——是以风险影响的方式，而不是按颜色统计的数字。

警示信号同样容易辨认。用形容词描述覆盖范围。样例报告中没有根本原因，也没有复现条件。服务商说不出自身方法的局限，或者承诺"修复后不再有漏洞"。提出把报告包装成"安全证书"。当然，还有在没有书面授权的情况下就愿意开工。

如果想看看 Pentest.red 如何回答这些问题，可以把发给其他候选者的同一份范围文件发给我们，与其他候选者在同等条件下讨论测试计划、样例报告和复测条款。服务形式详见渗透测试页面。

如何做出决定并保留决策依据

为了避免选择被最光鲜的演示所左右，应当在收到方案之前就商定评估标准及其权重。开发自有产品的组织，可以给根本原因分析和对研发的反馈更高的权重；验证特定一组控制措施的组织，则可以更看重要求的可追溯性和清晰的覆盖定义。关键是权重要事先写下来，并且不会因为某个候选者给人留下特别好的印象而改变。

1. 统一范围所有候选者收到同一份文件：系统、角色、租户、环境、排除项、攻击起点以及期望的证据。
2. 可比较的回答每家服务商把适用的 Web/API 工作映射到带版本号的 WSTG 和 ASVS，为其他组件说明标准，并列出技术局限。
3. 证据评审脱敏报告、技术访谈和数据处理规则按照一张事先商定的评分表进行评估。
4. 决策与授权记录选择依据；每个有权授权的一方批准其责任范围，并在开工前满足适用的托管或服务商条款及测试规则。
5. 验收与复测依据证据验收发现项，在注明的条件下复测修复情况，经验教训用于下一次采购。

决策要连同依据一起记录：采用了什么范围、收到了哪些回答、哪些证据起了决定作用。这在审计人员提问时和下一次采购时都会派上用场。项目结束后，应当回到这张表：在范围和方法可比的情况下，反复出现的弱点类别证据是否减少？报告用起来是否顺手？访谈中承诺的深度是否兑现？发现项数量本身不能证明已经改进。根据实际情况调整权重，下一次比较就不必从零开始。

把 ASVS 要求作为测试人员和开发人员之间的共同语言也很有帮助。该标准以机器可读的格式发布，包括 CSV 和 JSON，因此同一组要求可以转化为待办事项、测试计划和验收标准。这样一来，只要同时记录了范围、状态和方法，即使更换服务商，后续结果也会更容易与此前工作比较。

结论：选择可以核查的工作成果

有据可依地比较渗透测试服务商，靠的是几件简单的事：所有人使用同一份范围，用带版本号的参考依据代替形容词，用证据代替承诺，有清晰的复测流程，并在授权和数据方面守住纪律。当所有人回答同样的问题时，严谨程度的差异自然就会显现。

对某个具体组织而言，合适的服务商应当让计划、执行和报告都能追溯到商定的参考依据，其证据能够支持对被测系统修复结果的验证——并且始终在经过适当授权的范围之内。