SOC 2 能否接受由 AI 执行的渗透测试？

误解：SOC 2 要求渗透测试必须由人类顾问执行，没有例外。信任服务准则（Trust Services Criteria）中没有任何地方这样规定——但这种看法十分普遍，常常让团队措手不及。越来越多的安全团队全年持续运行由 AI 驱动的渗透测试，而不是每年委托一次测试项目——随后在 SOC 2 审计时，他们会向审计师提出一个对方此前从未被问过的问题：如果渗透测试是由 AI 智能体而非人类顾问执行的，您会接受这份渗透测试报告吗？

SOC 2 是否接受由 AI 执行的渗透测试？是的，但有条件——下面我们来看看哪些条件对审计师真正重要。

本文其余部分将逐一说明这一结论成立的原因：SOC 2 实际上要求什么，为什么持续的 AI 测试比年度渗透测试更契合审计期间，以及审计师会接受的 AI 生成证据与会被拒绝的 AI 生成噪声之间有何区别。

SOC 2 其实并没有提到“渗透测试”

人们第一次仔细阅读信任服务准则时，往往会对此感到意外。AICPA 在 TSP Section 100 中定义了信任服务准则（2017 年版准则，并于 2022 年发布了修订后的关注点）。仔细阅读官方文档就会发现，正文从未点名要求进行渗透测试。它要求的是组织评估其控制措施是否有效运行，而渗透测试已成为审计师期望用于评估技术控制措施的市场标准方式——这并非因为该框架要求采用这一特定方法，而是因为没有其他方法能够证明控制措施在攻击下确实有效，而不仅仅是停留在纸面上。

以下三项准则承担了大部分分量：

准则	要求内容	为什么审计师通过测试方法来评估它
CC4.1——监控活动	实体评估其控制措施是否存在并正常运行	检查控制措施（阅读配置、核对策略文档）只能确认它存在；对其发起攻击才能确认它有效
CC7.1——漏洞识别	实体识别其基础设施中的漏洞	这意味着一项持续性活动——漏洞不会按固定的年度计划出现，因此证据需要覆盖整个审计期间，而不是其中的某一天
CC7.2——安全事件检测	实体实施检测程序以识别异常	实时攻击是为数不多能够产生真实事件、并观察检测机制是否真正触发的方法之一

因此，“我们需要为 SOC 2 做一次渗透测试”实际上是“我们需要可信的证据，证明我们的控制措施在整个被审计期间都能经受住主动破坏的尝试”的简略说法。这一区别很重要，因为它意味着审计师真正关心的问题从来不是由谁或由什么执行了测试——而是测试产出的内容是否构成可信、可复现的控制有效性证据。AI 智能体所面对的评判标准与人类测试人员完全相同。

Type II 审计为持续性证据而设计，而非单一快照

SOC 2 有两种类型，二者的差异甚至会改变“可接受证据”的含义。

• Type I 证明控制措施在某一时间点设计得当。
• Type II 证明控制措施在整个审计期间有效运行——通常为六到十二个月。

传统的年度渗透测试只产生一个数据点：一份日期落在该期间内某一天的报告。对于 Type I 审计，这样的匹配是合理的。而对于 Type II 审计，这存在结构性错配——要用一个快照来代表十二个月的控制运行情况，而在该测试项目日期之前或之后发生的一切都完全没有证据支撑。

正是在这一点上，持续的、由 AI 驱动的测试改变的是证据的形态，而不仅仅是证据的数量。由于智能体式渗透测试平台可以在整个审计期间运行周期性的测试，而不是在期间内只开展一次测试项目，证据链自然会覆盖 Type II 意见所证明的同一时间窗口。在审计期间第七个月披露的新 CVE，会在第七个月就针对您的环境进行测试，而不是等到下一年的年度渗透测试碰巧发现时才被追溯性地察觉。这在结构上更契合 Type II 审计实际想要证明的内容——这不是绕过要求的捷径，而是对要求更贴切的满足。

AI 渗透测试报告必须满足哪些标准才能用于 SOC 2？

对于 SOC 2 审计而言，产生某项发现的工具并不是审计师真正关心的问题。审计师早已接受大量自动化输入（漏洞扫描器、配置合规工具、基于日志的监控）作为辅助证据。决定一份渗透测试报告——无论由 AI 还是由人执行——能否站得住脚的，是同样一份简短的属性清单：

1. 可复现的证据，而非严重程度评分。一项发现需要有请求/响应对、复现路径，或其他可供第三方独立确认影响的材料——而不是附加在模式匹配结果上的置信度评级。
2. 有文档记录、可供检查的方法论。审计师需要能够读到实际测试了什么——哪些入口点、哪些假设、哪些验证步骤——而不是凭信任接受一个黑盒式的“相信模型”的说法。审计师对黑盒保持职业怀疑是有充分理由的。
3. 具名且负责的人工签核。在整个链条的某个环节，有一位具体的、具备资质的人员审查了结果，并对报告的准确性负责——就像由人执行的测试项目会写明签署报告的测试人员一样。
4. 明确且经过约定的范围。该项目覆盖哪些系统、覆盖多长时间，以及这些内容如何对应到审计边界。无论由谁执行测试，范围不明确或不断变动都会削弱证据质量。
5. 整个期间内证据格式保持一致。如果 Type II 审计所依赖的证据在中途改变了形态——报告结构不同、覆盖范围不同，而且没有任何解释——这会被视为危险信号，而不是创新。

以下是第 1 点和第 2 点在实践中的样子，取自移动后端上一个真实的对象级授权失效（Broken Object-Level Authorization）发现——端点名称、令牌和可识别的值均已脱敏。

图 1：发现本身——严重程度、对缺陷的通俗描述，以及根因确认：存在漏洞的端点忽略了某个请求头，而一个同类端点则正确地强制执行了该请求头。下面的其余图片将追溯这一具体发现是如何被规划、复现和重新验证的。

图 2：复现路径的前两步——先通过硬编码的客户端凭据获取一个全局 Bearer 令牌，然后按照目标的加密方案对请求负载进行加密。已为发布做脱敏处理。

图 3：图 2 中的请求实际产生的响应——在未提供任何用户令牌的情况下，返回了一个有效账户的完整 PII 对象。这就是第 1 点所说的“可复现的证据”：第三方可以重新运行这一完全相同的请求并得到相同的结果。

图 4：同一发现背后的测试计划——一个具名的规划智能体、明确的目标（确认请求头绕过、验证该令牌是否足够、检查在轮换后是否依然有效等），以及从基线记录和攻击面映射开始的分阶段任务列表。这就是第 2 点所说的“可供检查”：审计师可以准确读到计划和测试了什么，而不仅仅是结果。

这五项属性没有一项是 AI 所特有的。一份平庸的人工渗透测试报告同样会在这些标准上不达标——发现含糊、没有复现步骤，分包商无人能说出名字，范围从未形成书面记录。由 AI 执行的测试不会被放宽评分标准，也不需要被放宽：真正验证其发现的智能体式测试，比仓促的人工测试项目或基于特征签名的扫描都能更稳定地达到这一标准。

“由 AI 执行”在哪些情况下会悄然失去证据效力

值得警惕的失败模式并不是“审计师因为涉及 AI 而拒绝了它”，而是把 AI 扫描器误当成 AI 渗透测试，并把前者贴上后者的标签交给审计师。

扫描器——无论是否有 AI 辅助——都是对代码库或在线目标进行模式匹配，并报告它认为可能存在的问题。如果不经验证，这样的输出只是一份假设清单，而不是检测结果：误报量大，没有复现路径，也没有证据表明任何内容展示了真实影响。作为审计证据，它比一次普通的人工渗透测试更弱而不是更强，因为审查人员仍然需要重做这些工作才能知道哪些是真的。一次扫描更大范围的攻击面也改变不了这一计算——在 Web、移动和 API 资产上并行运行多资产扫描，只会让每小时产出更多未经验证的假设，除非下游有某个环节真正确认哪些是真实的。

AI 渗透测试在性质上就不同，而不仅仅是速度不同：侦察、假设、测试、验证，以及——至关重要的——一个检查某项发现是否会与另一项发现组合成更严重问题的步骤。具体对 CC7.1 证据而言，关键的区别在于报告是表明某个凭据已在真实端点上被证实有效，还是仅仅被标记为“可能的硬编码密钥”。前者是证据；后者只是一条仍需人工追查的线索。

正是出于这个原因，Ostorlab 的 Agentic Deep Scan 也围绕同一原则构建：检测阶段发现并利用问题，产出一个可运行的请求、该请求产生的响应，以及该响应所证实的具体论断。随后，一个独立的验证阶段会在任何人看到结果之前独立地重新运行该漏洞利用——使用新获取的令牌，而不是手头已有的令牌；与一个正确执行该控制措施的端点进行对比检查，以排除全局配置错误；使用替代的输入格式并随时间重复运行，以确认该问题不是某一个特定请求的偶然结果。这正是审计师可以据以采取行动的证据，与只是把验证工作推给下游的报告之间的区别。

图 5：同一发现的验证阶段——在一批账户上重新运行漏洞利用以排除偶然结果，然后使用新获取的令牌重复执行，以确认该问题与原始会话无关。这一阶段在检测之后、发现呈现给任何人之前运行。

审计师真正希望看到的证据包

无论测试是持续进行的还是单次项目，由人执行还是由 AI 执行，一份可用于 Type II 审计的证据包通常都需要相同的组成部分：

组成部分	所证明的内容
方法论文档	测试了什么、如何测试、通过什么流程测试——包括 AI 智能体的假设是如何生成和验证的
范围说明	测试项目覆盖哪些系统、环境和时间窗口，并对应到审计边界
每项发现的证据	显示真实影响的请求/响应对、复现步骤、截图或日志——而不仅仅是严重程度标签
人工审查记录	谁审查了这些发现、何时审查、作出了怎样的判断——即审计师可以引用的具名问责
修复与重新测试证据	确认所报告的问题已被修复，并且修复经过了独立的重新验证，而不只是被标记为已关闭
覆盖范围图	测试证据实际覆盖了审计期间的哪些部分，使缺口清晰可见，而不是被假定为不存在

如果一个项目能够针对整个审计期间提供全部六项内容，那么由 AI 智能体执行各个测试周期这一事实只是实现细节，而不构成反对理由。

在不打乱现有审计的前提下引入持续 AI 测试

实践中的错误不在于运行由 AI 驱动的测试——而在于在审计期间中途改变证据形态却不告知任何人。以下几点可以让过渡平稳进行，而不是带来意外：

• 在审计期间开始之前就与审计师沟通，而不是等到报告到期时。大多数审计师并不反对更多、更好的证据；他们反对的是毫无预警地以陌生格式出现的证据。
• 尽早展示样例报告。在它成为支撑某项控制措施的唯一证据之前，让审计师先看看一项发现是什么样子——包括其中的证据。
• 提前约定节奏和格式。每周、持续或每月的测试周期都是可行的；破坏信任的是在中途切换格式而不记录原因。
• 如果审计师需要，保留一个熟悉的锚点。有些审计机构仍然更习惯将一次年度的、经过更多人工审查的测试项目作为持续项目中的一个环节，至少在第一个周期内如此。这是合理的过渡步骤，而不是承认 AI 测试不算数。

尚未尘埃落定之处

AICPA 的信任服务准则目前尚未包含关于由 AI 执行测试的明确表述，各审计机构如今愿意评估 AI 智能体参与的程度也各不相同。将证据直接输入 SOC 2 审计的合规自动化平台已经开始接受由 AI 执行的渗透测试报告作为有效的辅助证据——市场上的工具一侧正走在标准表述的前面，尽管各个审计机构仍会逐案设定自己的标准。有些机构会以极少的阻力接受一份证据充分的 AI 渗透测试报告；另一些则会要求一位具名、具备资质的人员审查并共同签署这些发现，之后才会依赖它——这是合理的要求，值得提前规划，而不是抵触。在指导意见跟上实践之前，更稳妥的做法是充分记录：保持方法论清晰明确，让每份报告都有一位负责的人员，并把审计师的质疑视为一次关于范围的讨论，而不是对这种方法的否定。

常见问题

SOC 2 是否要求进行渗透测试？并没有明确要求。信任服务准则要求提供控制措施有效（CC4.1）以及漏洞得到识别（CC7.1）的证据，而渗透测试已成为产生此类证据的公认方式——但这是基于准则形成的审计师期望，而不是框架正文中点名的要求。

AI 智能体的发现能否满足 CC7.1 的证据要求？可以，前提是这些发现经过验证，而不是模型的原始输出：每一项都需要有可复现的可利用性证据，而不是给模式匹配结果打上的严重程度评分。未经验证的 AI 生成线索与未经验证的扫描器告警一样，都达不到这一标准。

完全自主、未经审查的 AI 渗透测试报告能否用于 SOC 2？通常不能。审计师期望他们所依赖的任何报告背后都有一位具名且负责的人员。AI 智能体可以执行测试；但仍需要一位具备资质的人员审查结果并为其背书。

就合规目的而言，AI 渗透测试与漏洞扫描有何不同？扫描报告的是可能存在的问题；渗透测试——无论由 AI 还是由人执行——则通过侦察、假设、测试和验证，证明哪些问题实际可被利用。审计师将未经验证的扫描输出视为较弱的证据，因为仍需要人工来判断哪些是真实的。

在持续 AI 测试之外，我们是否应保留年度人工渗透测试？许多组织会这样做，至少在过渡期内如此：要么是因为审计师希望有一个熟悉的锚点，要么是因为定期的、由人主导的测试项目能够增加基于判断的测试（业务逻辑、与社会工程相关的场景），从而补充而不是重复系统化的 AI 覆盖。

结论

SOC 2 评判的从来不是工具——而是证据。完全由 AI 智能体执行的渗透测试可以满足 SOC 2 Type II 审计的要求，并且在某些方面比单次年度测试项目更契合基于期间的证据模式，因为持续测试自然会覆盖审计所证明的时间窗口。它无法跳过的，是那些从一开始就与工具无关的部分：可复现的证据、审计师真正能读懂的方法论、一位为报告背书的具名人员，以及在计时开始之前各方就已达成一致的范围。只要把这些做好，测试是按照咨询公司设定的日程运行，还是由一个在凌晨 2 点推演各种假设的智能体运行，就不再是值得关注的问题。

更值得关注的问题是，当同样的逻辑被应用到 SOC 2 之外时会发生什么。PCI DSS、HIPAA 以及其他各种合规框架都依赖同样的理念——控制措施要能经受住攻击，而不只是存在于纸面上。它们是否已经准备好接受由 AI 执行给出的答案，我们将在另一篇文章中探讨。