面向审计准备的渗透测试：如何构建经得起审查的证据

设想一个假设的情境。一家公司销售带有客户门户和公开 API 的 B2B 平台。一位大客户正在准备自己的供应商审计，要求该公司说明其安全问卷中声明的控制措施是如何经过测试的：租户之间的访问隔离、通过单点登录（SSO）进行的登录，以及管理操作的日志记录。公司手里有一份渗透测试报告，但已经超过一年。报告描述的是迁移到 SSO 之前的门户版本，对新的计费 API 只字未提。跟踪系统中有两项高严重性发现被标记为“已修复”，但从未有人进行复测。

这里的问题不在于是否还需要再做一次渗透测试，而在于哪一组证据能让审计师从每一项声明的控制措施出发，追溯到具体的测试、测试结果以及修复确认。下文说明如何规划渗透测试，使其结果能够作为这样的证据；这些证据的边界在哪里；以及在下单之前需要作出哪些决定。

渗透测试能为审计提供什么，不能提供什么

是证据，而不是结论

面向审计准备的渗透测试，是一种经过授权的安全测试，其规划和记录方式使结果能够作为证据使用。它回答一个具体问题：组织如何知道，在测试当日、在约定范围内，其技术控制措施确实有效。

同时，渗透测试并不能确立合规性，不能替代认证或鉴证，也不是关于控制有效性的保证意见。这些结论由审计师或评估方依据其所适用体系的规则作出，服务商的报告只是其工作的输入之一。报告中如果出现“经渗透测试，系统符合要求”之类的表述，应视为警示信号，而不是优点。

第二个限制同样重要：渗透测试不能保证不存在漏洞。它展示的是测试了什么、使用了什么方法、在什么期间进行、得到了什么结果。凡是没有测试的内容，仍然处于未经测试的状态，一份诚实的报告会通过列出排除项和前提假设直接说明这一点。

技术测试的双重用途

NIST SP 800-115 是 NIST 于 2008 年发布的信息安全技术测试与评估指南，内容涵盖测试的规划与实施、发现的分析以及缓解策略的制定。其摘要指出，技术测试既可用于发现系统或网络中的漏洞，也可用于验证是否符合政策或其他要求。对审计而言，关键在于后者：只有当测试结果能够与事先明确的要求相对照，而不仅仅是一份问题清单时，测试才真正有用。

一份只列出问题、却没有说明测试了什么、依据哪些要求、测试之后发生了什么的报告，几乎无法为审计师提供依靠。围绕明确的方法和带版本号的要求编写的报告，则会留下一条可以追踪、并且日后可以复核的线索。

从声明的控制措施到约定的范围

“控制措施—系统—测试”对照图

准备工作不应从 URL 清单开始，而应从组织已经向审计师或客户声明的控制措施清单开始，这些声明可能出现在政策文件、安全问卷和系统描述中。对每一项控制措施，需要确定它作用于哪些系统、哪种测试能够为其提供证据，以及该测试属于渗透测试还是其他形式的评估。这样，测试范围就来自需要证明的内容，而不是来自预算或惯用模板。

第一步实际工作，是向审计师确认证据需要覆盖哪些系统和控制措施，以及对方是否明确期望渗透测试。NIST 和 OWASP 都没有声称某位审计师要求渗透测试，或接受某种特定的报告格式，因此你所适用的审计体系的要求需要事先商定。下表展示典型情境如何转化为范围决策，以及由此获得的证据有哪些边界。

确认所发现攻击面的归属

在侦察阶段，服务商经常会发现不在约定清单中的子域名、IP 地址或云资源。在确认归属之前，不得对其进行主动测试：该资产可能属于第三方或前供应商，也可能托管在条款要求事先通知的服务商处。正确的顺序是：记录这一发现，交给资产所有者，取得确认，并就是否纳入范围作出书面决定。发现未登记资产这件事本身对审计也有价值，因为它显示资产登记与实际情况的吻合程度。

假定已失陷：测试从哪里开始

假定已失陷场景从约定的失陷状态开始，例如一名普通员工的账户，或对内部网段中某台服务器的访问权限。它展示接下来可能发生什么：攻击者能推进多远，网段隔离、监控和权限分离在哪里发挥作用。但这种测试并不能证明初始访问是可能实现的，也不评估外部边界。报告中必须明确描述起始点，否则审计师可能会把结果理解得比实际更宽泛。

各项标准在审计证据包中的角色

每份参考资料负责问题的不同方面。角色混淆，是报告看起来很扎实、却经不住审计师追问的常见原因。

NIST SP 800-115：规划框架

该指南为工作提供结构：规划、实施测试、分析发现和制定缓解策略，并比较各项技术手段及其优点与局限。它明确表示自己并不是完整的测试计划，因此组织仍需建立自己的测试计划。其技术概述早于许多现代云架构和 API 架构。因此，合理的做法是把它作为规划和报告的框架，而具体流程则取自持续维护的 OWASP 资料。

WSTG 与 ASVS：流程与衡量尺度

OWASP Web 安全测试指南（WSTG）说明如何开展 Web 应用测试。OWASP 应用安全验证标准（ASVS）规定验证哪些内容：它既是测试 Web 应用技术安全控制的基础，也是一份安全开发要求清单。ASVS 声明的目标之一，是统一市场上验证工作在覆盖范围和严格程度上的差异。ASVS 的要求以机器可读格式发布，包括 CSV 和 JSON，因此便于导入跟踪系统，并按标识符记录覆盖情况和发现。对于这两份文档，报告都应注明实际使用的具体版本。

OWASP Top 10、CWE Top 25 与 KEV：确定优先级，而非测试流程

OWASP Top 10 是一份意识提升文档，反映业界对 Web 应用最关键安全风险的广泛共识。它有助于向管理层解释风险，但它是风险清单，而不是测试流程。因此，“测试覆盖了 OWASP Top 10”这一说法作为证据，弱于映射到 ASVS 要求并依照 WSTG 执行的测试。

MITRE CWE Top 25 每年列出最严重、最普遍的弱点，这些弱点往往容易发现和利用。与之相关的 CWE Top 10 KEV 弱点清单，依据 CISA 已知被利用漏洞（KEV）目录对正被积极利用的弱点进行排名。MITRE 本身也把可利用性洞察和风险优先级排序列为 Top 25 的用途之一。如果报告显示测试聚焦于正被积极利用的弱点类别，审计师看到的就是基于风险、而非随意划定的范围。CISA“设计即安全”系列警报涉及跨站脚本、操作系统命令注入、目录遍历和缓冲区溢出，指向的也是同样的类别。

CSF 2.0：与目标成果建立关联

NIST 网络安全框架 2.0 作用于风险治理层面。它的配置文件、快速入门指南和信息性参考，使组织能够把测试结果与已经定义的目标成果联系起来。这样，渗透测试就不再是一份孤立的文件，而是针对具体目标的证据。关于标准如何在整个应用审查过程中转化为决策，可参阅基于标准的应用安全审计一文。

如何让发现可追溯

每项发现必须包含的内容

可追溯性意味着审计师能够从声明的控制措施追溯到测试，从测试追溯到发现，再从发现追溯到其关闭。为此，每项发现都应包含：

• 可复现的描述，包括日期、条件和所用角色；
• 受影响的资产及其版本或环境；
• 映射到的 CWE 标识符；
• 引用带版本号的 ASVS 要求，或其他被违反的要求；
• 严重程度的判定依据；
• 如存在相应控制措施，与向审计师声明的该控制措施的关联。

还应另外记录测试用例来自哪个 WSTG 版本，以及刻意从范围中排除了哪些弱点类别及其原因。没有解释的排除看起来像缺口，有依据的排除则体现为经过考虑的决定。属于 CWE Top 10 KEV 清单中弱点类别的发现，值得标记出来优先修复。

HTTP 配置还是已确认的利用

Web 系统的许多控制措施可以在 HTTP 层观察到。MDN 将 HTTP 描述为无状态协议：Cookie 为部分交互增加了状态，HTTP 身份验证用于核实客户端身份。因此，会话管理和身份验证是天然的测试对象。在通过响应头实现的机制中，MDN 列举了内容安全策略（CSP）、跨源资源共享（CORS）、跨源资源策略（CORP）和权限策略（Permissions Policy），并提到可用其 HTTP Observatory 工具检查配置。

响应头设置作为证据很方便：容易观察，修复后复核成本也低。但是，存在某个响应头并不能证明控制措施有效。测试应检查策略是否真正约束了行为，报告也应把配置检查与经实际利用确认的发现区分开来。

要求引用中的版本号

ASVS 建议在要求标识符中注明版本：不带版本的标识符会被视为指向最新内容，而不同版本之间编号可能发生变化。同样的逻辑适用于 WSTG、OWASP Top 10 的不同版次，以及每年更新的 CWE Top 25。一份只写“依据 ASVS 测试”而不注明版本的报告，等到审计师阅读时可能已经含义不清。应引用实际使用的版本，而不是阅读报告当天能找到的最新版本。

修复、风险接受与复测

NIST SP 800-115 把测试视为一个不以报告为终点的循环：分析发现和制定缓解策略本身就是完整的阶段。证据包如果能展示三件事，就会更有说服力：问题已被发现；问题有了明确负责人，并已修复或经正式风险接受；修复已经过验证。MITRE 指出，对常见根本原因的洞察有助于消除整类缺陷，而 ASVS 同时也是安全开发要求清单。因此，要求标识符把发现与开发人员需要满足的要求联系起来，同一问题在下次审计前再次出现的可能性也随之降低。

1. 发现可复现的描述、受影响资产、CWE 标识符，以及注明版本号的要求引用
2. 负责人与决定指定负责人，并选择修复或附带复审日期的正式风险接受
3. 修复完成变更，并将其与跟踪系统中的发现编号和系统版本关联
4. 复测在修复后的版本上重复同一场景，并记录结果和日期
5. 证据包将发现、决定和复测结果汇集为供审计师追溯的一条完整线索

什么才算关闭

跟踪系统中的“已修复”状态只是团队的陈述，而不是证据。关闭需要通过在修复后的版本上复测同一场景来确认，并记录日期和结果。如果复测显示修复只是部分有效，该发现应保持打开状态并更新描述。如果组织决定不修复某个问题，则需要一份风险接受决定，写明负责人、理由和复审日期。关于如何证明修复确实有效，可参阅渗透测试修复验证一文；关于如何管理从发现到确认的整个循环，可参阅漏洞修复管控一文。

相对于审计现场工作的时间安排

测试应足够早地进行，以便在审计现场工作开始前留出修复和复测的时间。本文参考的资料中没有任何一份给出标准的提前期。合适的时间窗口取决于预计的发现数量以及变更流程的运作方式，因此最好依据组织自身的修复历史，而不是套用通用规则。如果时间已经很紧，向审计师展示一份有明确负责人的修复计划，比在未复测的情况下关闭发现更为诚实。

历史证据的时效与局限

旧报告中哪些内容会过时

渗透测试反映的是系统在测试当日的状态。一份一年前的报告仍然能证明一些事情：在那一时期进行过测试，发现了哪些问题，以及这些问题是如何处理的。但它无法说明之后新增的组件、发生变化的功能，以及此后被修改过的配置。在本文开头的假设示例中，旧报告可以作为“发现—修复”循环的历史记录，却不能证明 SSO 和新 API 按声明的方式运行。

因此，在使用历史结果时，应明确写出测试日期、系统的版本或构建号、测试范围，以及此后发生了哪些变化。旧证据应被赋予多大分量由审计师决定，但如果局限被直接说明，审计师作出判断会容易得多。

需要重新测试的变更

CISA《安全软件部署》指南强调在部署过程中进行稳健的测试和度量。发布频繁的组织需要解释两次测试之间如何维持保障。但这并不意味着每一次代码提交都需要一次付费渗透测试。值得进行新一轮人工测试的，是与安全相关的具体变更：新的身份验证或授权方案、新的外部接口或 API、多租户模型的改变、迁移到不同的环境，或新增能够访问敏感数据的集成。其他变更则由流水线中的自动化检查和配置管控来覆盖。关于如何把变更映射到测试范围，可详细参阅变更触发的渗透测试一文。

测试技术与测试环境的选择

NIST SP 800-115 区分了渗透测试、漏洞扫描、安全评估和风险评估，并强调每种技术各有优点和局限。对审计而言，这提醒我们没有哪一种技术能满足所有需求，所做的选择及其理由应记录在报告中。这一记录本身就表明测试经过了有意识的规划。

扫描、人工渗透测试与配置审查

自动化扫描能够覆盖大量资产，而且易于重复。人工渗透测试则能深入业务逻辑、组合问题和授权缺陷，这些通常是扫描器发现不了的。配置审查为可观察的设置提供低成本、可重复的证据。报告说明对哪项资产采用了哪种方式时，证据会更有力。覆盖 OWASP Top 10 便于解释，而映射到 ASVS 更为精确，只是需要更多投入。

生产环境还是预发布环境

测试生产环境更真实，但运营风险更高。预发布环境更安全，但组织需要证明它在代码版本、配置和集成方面与生产环境一致。如果测试在预发布环境中进行，应在范围说明中写明，并列出与生产环境之间已知的差异。

让测试工作本身处于受控状态

授权与交战规则

任何测试都必须获得对范围内系统拥有权限的人员的明确书面授权。如果托管服务商或 SaaS 服务商的条款要求事先通知或批准，也同样适用。交战规则中应记录日期、目标、排除项和联系人。本文说明如何组织经授权的工作，并不授予、也不暗示任何测试授权。

停止条件与数据处理

以下事项都应事先约定：排除的技术手段（例如任何可能降低可用性的操作）、对测试中接触到的敏感数据的处理规则、测试期间发现严重问题时的升级渠道，以及明确的停止条件。这些安排本身也是审计证据：它们表明测试处于受控状态，对运行中系统的风险得到了管理。

下单测试之前采购方需要作出的决定

为审计采购渗透测试，买的是证据质量，而不是测试人员的工时。既然 ASVS 的创建目的之一是统一验证工作在覆盖范围和严格程度上的差异，市场上的各家服务必然存在差别。应据此组织征询方案，使各家回复能够按相同要求进行比较。

向服务商提出的问题

• 你们将遵循哪些方法及版本？测试用例将如何记录？
• 发现是否会映射到 CWE 标识符和带版本号的 ASVS 要求？
• 能否提供一份脱敏的样本报告，展示方法、范围和复测部分？
• 是否包含复测？如何证明发现已经关闭？
• 授权、交战规则和停止条件如何记录？
• 测试中接触到的敏感数据如何处理？
• 由谁执行测试？能证明哪些相关经验？

关于如何按相同标准比较多家服务商的回复，可参阅基于证据的服务商选择框架。

报告中的警示信号

有些迹象会削弱报告的审计价值，但其本身并不能证明测试质量差：只引用“OWASP Top 10”，却没有版本号，也没有与要求的映射；没有复测；范围只是一串 URL 列表，没有角色和账户；方法说明含糊；承诺“合规”或“没有漏洞”；假定已失陷场景却没有描述起始点。不要未经核实就接受服务商关于认证、客户或成果的声明，应索取证据并独立核实。

投入预算之前的五个问题

• 需要证明什么？向审计师确认证据需要覆盖哪些系统和控制措施，以及对方期望的是渗透测试还是其他形式的评估。
• 范围包括什么？列出应用、API、环境和用户角色，并结合 CWE Top 25 和 KEV 清单确定优先级。
• 用什么衡量尺度？用带版本号的 ASVS 要求进行验证，用 WSTG 作为测试流程，用 NIST SP 800-115 作为规划和报告结构。
• 采用哪些技术组合？针对每项资产在扫描、人工测试和配置审查之间作出选择，并记录理由。
• 如何证明问题已关闭？指定负责人，建立风险接受流程，并在审计现场工作前安排复测。

如果无法回答第一个问题，应暂停采购：在还不清楚需要什么证据时就下单测试，很可能无法回答审计师的问题。最好事先整理好系统、角色、限制条件和预期证据的清单，例如使用渗透测试范围准备表单，并以此作为与 Pentest.red 讨论工作的起点。

以可重复的过程取代一次性报告

渗透测试对审计的价值，在于有记录、可重复的过程，而不在于一次性的报告。依据 NIST SP 800-115 进行规划，依据 WSTG 确定测试流程，对照带版本号的 ASVS 要求进行验证，参考 CWE Top 25 和 KEV 清单确定优先级，明确范围及其边界，让发现可追溯，进行复测，并如实说明证据的时效——这些共同构成一条审计师可以追踪的线索。

首次准备审计的组织，可以先对风险最高的系统开展范围明确的测试，并做 ASVS 映射和复测。更成熟的组织，可以把测试纳入 CSF 2.0 配置文件，将其与安全相关的变更挂钩，并跟踪弱点类别在历次测试之间的变化。无论哪种情况，渗透测试始终是审计证据的来源之一，而关于合规的结论，则由实施审计的一方作出。