SOC 2 渗透测试：范围、方法与审计师可用的证据

设想这样一个场景：一家面向中型企业的 B2B 薪酬计算服务正在进行首次 SOC 2 Type 2 审查。在观察期结束前一个月，一位大客户发来安全问卷，其中一项要求是："请附上覆盖贵司 SOC 2 报告系统边界的渗透测试报告。"公司确实有一份报告，是半年前以最低价格采购的：供应商扫描了营销网站和一个测试环境，附上四十页扫描器输出，并给出"无问题"的结论。客户的安全团队提出三个问题：承载薪资文件的生产 API 是否经过测试？客户之间的隔离是否经过验证？发现的问题是否已修复并复测？对这三个问题，诚实的回答都是"没有"。

这个场景是虚构的，但采购风险是真实的：SOC 2 渗透测试可能被当作一份文件购买，而不是一次有实质内容的评估。企业如果只按价格和页数选择，就有可能先为无法回答审计师问题的证据付费，再为这些问题暴露出的补充测试付费。下文将讨论 SOC 2 对渗透测试究竟说了什么、如何按系统边界确定范围、依据哪种方法测试、如何把发现转化为可追溯的证据，以及选择供应商时应关注什么。

SOC 2 对渗透测试说了什么，没说什么

SOC 2 不是认证。组织可以在独立注册会计师（CPA）服务审计师完成审查（examination）后取得 SOC 2 报告；该报告涉及服务机构在安全性、可用性、处理完整性、保密性或隐私方面的相关控制。其依据是 AICPA 的信任服务准则（Trust Services Criteria）2017 版及 2022 年修订的关注要点（points of focus）。Type 1 和 Type 2 是报告类型，而非成熟度等级：简单地说，前者针对某一时点的控制设计，后者还涵盖控制在一段期间内的运行情况。

有一个细节常被曲解：AICPA 准则并未设定"每年必须做一次渗透测试"的普遍要求。准则以控制目标的形式表述，实现方式由组织自行选择。渗透测试之所以进入审查视野，是因为具体情况把它纳入：组织在系统描述中自己写下的控制（例如"每年至少进行一次外部渗透测试"）、风险评估的结论、合同中对客户的承诺，或审计师对监控和漏洞管理证据的期望。因此，关于渗透测试的第一次对话应当与审计师进行，而不是与供应商：选定了哪些信任服务类别，系统边界在哪里，哪些分包服务机构被排除在外，证据需要覆盖哪个期间，审计师打算如何使用测试结果。

渗透测试本身不是 SOC 2 鉴证。测试人员可以对特定控制在已测试场景、范围和条件下是否有效作出结论，但 SOC 2 意见由服务审计师出具，测试人员不能保证得到干净报告。NIST SP 800-115 将漏洞发现和针对策略或其他要求的验证列为可选评估目标。各方应约定本项目追求其中一项还是两项。对 SOC 2 证据而言，把技术发现与选定控制的检查结合起来往往有价值：缺少控制背景的发现难以定位，而过于狭窄的符合性检查可能遗漏客户数据实际经过的路径。

按 SOC 2 系统边界确定渗透测试范围

范围应当跟随报告中描述的系统，而不是跟随方便或便宜的测试对象。根据系统描述，边界可能包括存储、处理或传输客户数据的组件：生产应用、公开及合作伙伴 API、认证与会话机制、管理控制台和客服工具，以及支撑它们的云或网络基础设施。只测试营销网站可能得到很少发现，却不能据此对范围内产品作出干净结论，也无法有力证明边界其他部分的控制。

范围文件应列出什么

好的范围文件无需作者在场也能读懂。它逐一列出应用、域名、API、环境和云账户的名称；说明为测试创建了哪些角色和租户；描述它们之间预期的边界。排除项要单独、明确地列出并注明原因，例如"计费服务商属于分包服务机构，按其自身计划测试""移动应用不在本期报告边界内"。审计师应能看到哪些内容未经测试，并理解这是有意的决定而非遗漏。

环境是另一个问题。有时直接测试生产环境风险较高，工作会转到预发布（staging）环境。这是合理的选择，但结果不会自动适用于生产环境：配置、功能开关、密钥、网络规则和数据量的差异都会改变结论。如果在预发布环境测试，应记录与生产环境的已知差异，并与审计师商定哪些检查仍需在生产环境中确认，例如外部配置和响应头。

授权、交战规则与第三方平台

NIST SP 800-115 把规划作为评估的第一阶段，这对 SOC 2 尤为合理。开始工作前，双方应书面约定：范围包含和排除的内容、测试时间窗口、禁止使用的技术、测试数据及意外发现的敏感数据的处理方式、停止条件，以及出现意外时的紧急联系人。

授权必须来自对每个目标系统真正有决定权的人。商务总监在供应商合同上的签字，并不赋予测试云服务商基础设施、合作伙伴 SaaS 服务或第三方运营平台的权利：它们有自己的规则，需要单独确认。如果系统的一部分属于子公司或客户，也需要取得他们的同意。

攻击者视角与租户隔离

范围不仅由资产清单决定，还由测试所采用的视角决定。通常包括：外部未认证用户、每个重要权限级别的已认证用户，以及在多租户产品中，试图访问另一租户数据的某一租户用户。对 SOC 2 报告的读者来说，最后一种视角往往最重要：企业客户最关心的是，隔壁客户看不到自己的薪资文件。如何为云产品设计此类检查，可参阅我们关于 SaaS 企业渗透测试的文章。

如果你还在梳理边界和角色，这正是与 Pentest.red 讨论测试范围的好时机：根据系统描述以及环境和角色清单，可以提前看清测试在哪里能为审计师提供有用证据，在哪里会超出渗透测试所能证实的范围。

方法：NIST SP 800-115 与 OWASP WSTG

NIST 的三个评估阶段

NIST SP 800-115 于 2008 年 9 月发布，取代了 SP 800-42。它把技术测试描述为三个阶段：规划、执行和执行后。规划涵盖目标、范围、规则和后勤；执行涵盖具体技术，从发现和扫描到渗透尝试；执行后涵盖发现分析、修复建议和报告。该指南讨论各项技术的优势与局限，而不承诺一套全面的测试计划。

该文件年代较早，应与当前的应用测试方法结合使用，而非单独依赖。但作为框架它很有用：当测试明显按公认结构进行规划、执行和分析时，审计师更容易接受结果。NIST 目录还将该指南与多个控制族相关联——审计与问责、评估与监控、风险评估、系统与服务获取、系统与通信保护、系统与信息完整性。这有助于说明技术测试与控制领域的关系。但目录中的关联并不意味着你系统描述中的某项具体控制有效。测试和复测可以为该控制在已记录条件下的表现提供证据；审计师还会结合控制设计、运行情况及其他相关材料作出评价。

Web 应用与 API 的实操方法

对 Web 应用和 API，OWASP Web 安全测试指南（WSTG）提供了更细致的方法。它是 OWASP 的旗舰项目，涵盖配置、身份、认证、授权、会话管理、输入验证、业务逻辑和客户端测试。供应商应说明所依据的版本（例如 4.2），并展示其测试计划如何与之对应。

关键在于可验证性。供应商内部的私有检查表，外人无从审查。有名称、有版本的方法，能让审计师、客户和你自己的团队了解执行了哪些类别的检查，哪些被有意跳过。

覆盖深度：OWASP Top 10、ASVS 与 CWE 弱点类别

OWASP Top 10 是关于最关键 Web 应用安全风险的意识文件，反映了从业者的广泛共识；OWASP 发布了 2025、2021 和 2017 版，报告应注明所用版本。对 SOC 2 渗透测试而言，它是下限而非上限。只声称"覆盖 OWASP Top 10"的报告，描述的是最低主题集合，而不是测试深度。

OWASP ASVS 解决的是另一个问题：它定义可验证的应用安全要求，缩小市场上测试严格程度的差异。每项要求都有标识符，OWASP 建议连同标准版本一起引用，格式如 v5.0.0-1.2.5：版本号，然后是章、节和要求编号。要求还以机器可读格式发布。这对 SOC 2 很方便：与带版本要求挂钩的发现，可以与去年对比、在工单中跟踪，并且无需解释即可核查。需要注意：只有在要求确实适用时才应映射 ASVS，映射本身并不能证明应用符合该标准。

CWE 分类的价值在于另一方面。MITRE 根据真实 CVE 数据发布"最危险的 25 个软件弱点"（CWE Top 25），例如 2025 年版，并将其定位为对开发和架构的反馈。当具有合适技术弱点的发现采用适用 CWE 标签时，一系列报告就成为数据：可以看出已识别的缺陷类别是消失了，还是在新代码中重现。但不要混淆层次：CWE 描述的是弱点类型，而不是被利用的事实。CWE-79 标签说明发现属于哪一类；证明该漏洞在你的系统中确实可被利用的，是测试人员的复现。

CISA 的"设计安全"（Secure by Design）计划指向同一方向。其警示呼吁厂商消除整类漏洞——跨站脚本、操作系统命令注入、目录遍历——而不是逐个修补。对渗透测试而言，这意味着按适用的弱点类别归纳发现，并在受影响路径中追查根因。如果测试人员在某个处理程序中发现命令注入，应检查共用的进程调用路径，并在存在同一根因之处采用安全的调用设计；单个发现本身不能证明整个服务都存在该缺陷。

HTTP 层：会话、Cookie 与浏览器策略

Web 测试很大一部分发生在 HTTP 层。协议本身不在请求之间保存状态：从 HTTP 的角度看，每个请求都是独立的。但这并不意味着服务器不能有会话。常见做法是服务器自己保存会话数据，通过 Set-Cookie 头给客户端一个标识符，浏览器在后续请求中带回。另一种做法是自包含的签名令牌，由客户端携带状态。两种设计都合理，也各有失效点：可预测或无法撤销的标识符，缺少 Secure、HttpOnly 和 SameSite 属性，注销或修改密码后会话依然有效，服务器未正确校验令牌。因此，会话的创建、存储、终止和撤销是测试的核心领域，保护受限资源的认证机制同样如此。

许多浏览器防护通过响应头配置。内容安全策略（CSP）规定页面可加载哪些资源，有助于缓解跨站脚本与数据注入。CORS 告诉浏览器是否允许其他来源的脚本读取响应；如果服务器反射攻击者控制的 Origin，同时允许使用有效凭据，受害者浏览器中的脚本可能读到该响应，但 CORS 不能替代服务端授权。对于某些跨源 no-cors 请求，CORP 可以阻止浏览器把响应体交给请求上下文，却不一定阻止请求本身发出。权限策略（Permissions Policy）限制页面代码对浏览器功能和 API 的访问。

团队可以在付费测试前先做响应头初步检查，例如使用 HTTP Observatory；所需投入和覆盖范围取决于系统规模与配置。提前修复明显的响应头问题，可以为自动化工具不够可靠的领域留出更多评估时间，例如授权逻辑、租户隔离和业务流程滥用。相关方法详见我们关于业务逻辑安全测试的文章。

扫描器、黑盒、灰盒还是白盒

NIST SP 800-115 把漏洞扫描和渗透测试视为各有优势与局限的不同技术。扫描覆盖面广且可重复，适合定期监控。人工渗透测试能发现扫描器难以识别的问题：角色之间的授权缺陷、租户隔离被突破、对业务流程步骤顺序的滥用。成熟的计划两者兼用。常见的采购错误是收到包装成渗透测试的扫描器输出：文件看起来像证据，但高风险路径仍未经检验。

固定预算可能迫使人在深度与广度之间取舍。如果范围无法穷尽测试，应优先考虑涉及客户数据的路径、认证与会话、管理功能以及租户之间的边界。对大量低价值资产浅尝辄止，是对同样工时的较差利用。应把优先级写入范围文件，让审计师看到这是有意识的、基于风险的决定，而不是疏漏。

测试时间应与审计师和发布计划协调。在重大架构变更之后进行测试，并在审计师审阅证据之前留出修复和复测时间，比在期间内随意某个时点测试更有价值。如果系统变化很快，可以用针对变更的定向测试补充计划内的测试，这一方法见我们关于变更触发式渗透测试的文章。

从发现到证据：报告、修复与复测

在 NIST SP 800-115 中，发现分析和修复建议属于执行后阶段，而不是可有可无的附录。对 SOC 2 而言，报告应让未参与工作的人也能理解：测试了什么、何时、从哪些视角、依据何种方法、结果如何。每个发现都应包含严重程度、受影响组件、适用时的 CWE 分类、适当时对应的带版本 ASVS 要求、业务影响和建议。证明材料应可复现，并与发现的风险相称。验证需要时可以包含受保护的概念验证，但应避免秘密、多余个人数据和不受控传播。日志和截图中的令牌、密码和密钥应脱敏，个人数据应最小化，报告本身应限制访问并设定明确的保存期限。

接下来是一个实践循环。NIST 并未正式展开描述它，但缺了它，报告对审计师价值有限：修复、复测、记录剩余风险。

1. 边界与授权依据系统描述确定范围，取得有权所有者的书面授权，准备测试角色与租户
2. 多视角测试外部用户、各个角色、跨租户访问；发现需复现并分类
3. 工单与修复每个发现关联工单、负责人，以及消除根因而非单个实例的变更
4. 在约定环境中复测验证原始场景及合理变体；结论仅限于所测环境和变体
5. 剩余风险未关闭的发现以书面形式接受：负责人、理由、复审日期

复测应从一开始就纳入项目。审计师和企业客户都会问：严重问题是否已关闭，修复是否经过确认。复测结论只在其实施范围内有效：如果复测是在预发布环境中针对原始场景进行的，就不能证明生产环境能抵御该攻击的所有变体。如何组织此类验证、什么才算关闭的证据，详见我们关于渗透测试修复验证的文章。

根因分析让渗透测试的价值超出审计本身。如果发现带着 CWE 标签交给开发团队，几个周期后就能看出系统已学会消除哪些缺陷类别、哪些反复出现，以及哪里需要在架构、库或代码评审上做出改变。

如何选择 SOC 2 渗透测试供应商

CISA 发布了面向软件客户的"需求安全"（Secure by Demand）指南：它教采购方向供应商提出具体、可核实的问题，而不是轻信营销。选择渗透测试服务商时同样适用。封面精美的样本报告说明不了多少，重要的是供应商如何回答关于方法、授权和复测的问题。

可以询问：遵循哪种方法及其哪个版本，在测试计划中如何体现；发现是否会映射到 CWE，并在适当时映射到带版本的 ASVS 要求；如何为每个系统获取并记录书面授权，基础设施部分属于第三方时如何处理；测试将覆盖哪些视角——未认证、按角色、跨租户；是否包含复测，如何记录关闭情况。还应索取一份脱敏的样本报告，并询问供应商如何处理工作中发现的敏感数据、谁能访问、何时删除。更全面的服务商比较框架，见我们关于渗透测试供应商比较的文章。

潜在危险信号包括：没有正式的书面授权流程；不说明方法，或说明了却没有版本；没有适用的 CWE 或要求映射，也不解释为何不适用；不提供复测；样本报告只是明显的原始扫描器输出。最明显的一条是承诺"保证通过 SOC 2"。意见由审计师出具，任何测试人员都无法承诺其结果。

如果你是软件厂商，渗透测试正是对照 CISA 倡导的"默认安全"理念检查产品的好机会：多因素认证、日志记录和单点登录应无需额外付费即可提供给客户。可将以下内容纳入范围：面向人员的 MFA 是否强制执行并能抵御绕过，日志是否完整且受保护，SSO 配置是否正确。服务和工作负载凭据——API 密钥、集成令牌、服务账户——需要单独测试：MFA 不适用于它们，相关问题是权限范围、轮换、存储和撤销。

当系统边界和审计师的问题都明确后，可以带着它们与 Pentest.red 讨论渗透测试服务：纳入哪些资产和角色、选择哪些视角、如何安排复测。SOC 2 本身——审查和报告——只能由独立审计机构执行；渗透测试为其提供材料，但不能替代其工作。

把渗透测试纳入风险管理循环

NIST 网络安全框架 2.0（CSF 2.0）帮助组织理解并改进网络安全风险管理；它提供概况（profile）、快速入门指南和信息性参考，展示 NIST 各项资源之间的关联。放在这一框架中，渗透测试就不再是一年一次的采购，而成为持续循环的一项输入：发现与组织概况中的目标成果相对照，下一次测试根据系统的变化来规划。

在实践中，决策顺序大致如下。首先，与审计师确认渗透测试结果是否以及如何使用、截止何时。然后依据系统描述确定范围：资产、环境、角色、租户、排除项。付费测试前先做好基础卫生——响应头、CSP、CORS、明显的配置错误。选择测试视角并记录理由。按有名称、有版本的方法、CWE 与 ASVS 映射、复测和授权纪律来选择供应商。依据书面交战规则开展工作。按根因修复、复测、记录剩余风险，并把 CWE 趋势反馈给开发团队。最后，将结果与 CSF 概况相对照，规划下一个周期。

这一顺序是作者的实践建议，而不是 SOC 2 或 NIST 的要求。它的意义在于，让你在与供应商交谈时，清楚自己需要什么、为什么需要、将如何评判结果。

结论：可重复的证据循环

SOC 2 渗透测试在达到项目约定目标，并产出审计师能够从范围追溯到方法、从发现追溯到处置结果的证据时，才具有实际价值。根据目标，它可以把真实弱点发现与选定控制或要求的验证结合起来。所需的一切都已具备：NIST SP 800-115 的阶段结构、OWASP WSTG 的实操方法、带版本的 ASVS 要求、用于趋势分析的 CWE 分类、对 HTTP 机制的理解，以及 CISA 倡导的采购纪律。

这些文件都没有包含的，是 SOC 2 针对你所在组织的具体规则。这些规则由你的系统描述、风险评估、对客户的承诺和审计师共同决定。从与审计师的对话开始，然后依据方法透明度、标准映射、复测和授权纪律来选择渗透测试，而绝不要依据"干净报告"的承诺。这样，测试就从一年一次的合规采购，变成一个确定范围、测试、修复和学习的循环，让产品在两次审计之间同样更加安全。