进攻性安全咨询：测试范围、标准与服务商选择

先看一个假设的场景。一家小型 B2B 软件公司即将签下第一份大型企业合同，客户的安全团队要求提供“一份近期的渗透测试报告”。研发负责人手上有三份报价方案。第一份承诺两周内“按 OWASP Top 10 检测应用”。第二份叫作红队评估，却几乎没有说明工作边界。第三份列出了带版本号的 ASVS 要求，写明了排除项，并包含修复后的复测。三份方案都以进攻性安全服务的名义出售，乍看之下似乎只需比较价格和工期。

这个例子是虚构的，但其中的问题是真实的：三份方案回答的是不同的问题。一份寻找已知类别的缺陷，一份检验团队能否察觉攻击，第三份则针对一组既定安全措施给出可追溯的评估结果。如果采购方不清楚自己要问的是什么问题，最终拿到的报告既无法交给客户，也无法交给工程师，更无法与下一份报告对比。下面我们来看进攻性安全咨询如何运作、每种工作形式究竟能证明什么、如何在不陷入官僚主义的前提下使用标准，以及如何识别一个结果真正可用的服务商。

以“进攻性安全”之名，实际买到的是什么

进攻性安全咨询，是由专业人员像攻击者那样审视你的系统，但前提是获得明确的书面授权、在约定边界内、遵循保护生产环境的规则。采购方通常需要三样东西：对真正可被利用的弱点的独立判断；工程师能够据以行动的证据；以及工作遵循公认方法、而非某位测试人员个人习惯的信心。

这个名称涵盖了一整类工作。NIST SP 800-115（2008 年发布的《信息安全测试与评估技术指南》）把渗透测试、漏洞扫描及其他检查技术视为同一评估过程的组成部分。该指南还提出了两个值得在任何项目中牢记的目标：发现系统或网络中的漏洞，以及验证是否符合策略或其他要求。发现与验证是两项不同的任务，哪一项为主，决定了其余的一切。

同样重要的是明白这类项目不是什么。渗透测试不等于认证、合规鉴证，也不等于审计师对安全措施充分性的意见。它展示的是在特定边界、特定日期内能够发现并确认的内容。报告中没有某项发现，并不能证明不存在漏洞。

最后，进攻性工作不能替代安全开发。CISA 的“设计即安全”（Secure by Design）倡议认为，网络安全的负担过多地落在了客户和小型组织身上，技术厂商应当在管理层面承担产品安全的责任。当咨询项目能够支撑这种责任时，它的价值最大：不只是罗列缺陷，而是解释缺陷产生的原因，并帮助消除整类缺陷。

项目要回答什么问题：工作形式及其能证明的内容

采购中代价高昂的错误，是把回答不同问题的工作形式放在一起比较。更好的起点不是服务名称，而是你需要获得什么样的证据。

漏洞扫描

扫描提供广泛且可重复的覆盖。它能快速遍历大量资产，报告潜在问题：过时的版本、危险的配置、已知漏洞。但如果没有进一步验证，它可能无法说明问题在具体环境中的后果，也可能产生误报。扫描适合日常安全卫生和变更管控，却不适合回答“攻击者实际上能做什么”。

渗透测试

渗透测试尝试在约定边界内确认某个弱点确实可被利用，并展示其后果。证据更有力，但在同等投入下覆盖面更窄。这里很大一部分价值来自攻击链：几项中等严重度的发现单独看似无害，组合起来却能访问其他用户的数据。也要记住这类证据的边界：一次成功的利用只说明在已记录的条件下攻击是可能的，却无法说明它发生的频率。

按 ASVS 要求进行验证

按选定的 OWASP ASVS 要求进行验证，回答的是另一个问题：在约定的严格程度下，哪些既定安全措施有证据支持？当客户或审计方需要可追溯的评估结果时，这种方式很有用。每项发现都对应一个双方理解一致的要求编号。即便如此，这种验证仍然是证据而非证书：它有助于收集证明材料，但不会给出具有法律意义的符合性结论。

红队评估与假定失陷评估

对手模拟演练通常被称为红队评估，它检验的不只是防御，还有检测与响应：监控团队能否察觉攻击者的行动，以及会采取什么措施。这一领域的术语并未标准化，因此需要就实质内容审视服务商的说法：目标是什么、约束是什么、成功标准是什么、生产系统如何得到保护。

另一种形式是假定失陷（assume breach）评估。它从预先约定的失陷状态开始：例如，测试人员持有一个普通员工账号，或可以访问一台工作站。这样能节省时间，让工作聚焦于横向移动和权限提升。但这类项目的结果并不能证明初始访问可以从外部获得：那是一个前提假设，而不是一项发现。关于如何选择起点和成功标准，我们在假定失陷评估一文中做了详细讨论。

外部攻击面评估

如果问题是“我们有哪些东西能从互联网上看到”，就需要攻击面侦察：查找域名、服务、云资源以及被遗忘的测试环境。这里有一个重要的前提。发现某项资产并不意味着获得了测试它的许可：在进入主动检测之前，需要确认该资产确实属于客户，并且客户有权授权对其开展工作。如何建立这种确认流程并对发现排序，可参见外部攻击面评估一文。

标准：采购方与服务商的共同语言

在进攻性项目中，标准不是为了让报告显得分量十足。它们让双方事先就计划覆盖什么达成一致；要确认实际执行情况，还需要已执行测试及其结果的记录。不过，并非每个项目都需要同样的文件：Web 应用适用一组参照，工业网络则需要完全不同的另一组。

OWASP WSTG：测试目录

OWASP Web 安全测试指南（WSTG）本质上是一份通用的 Web 应用测试目录。本文以 WSTG 4.2 作为带版本的参照，不对项目当前状态作出判断。方法与 WSTG 类别的对应关系显示适用 Web 工作的计划覆盖和排除项；实际执行情况则由测试记录和结果证明。合同中应固定所选版本。

OWASP ASVS：带版本的可验证要求

ASVS 的设立初衷，是统一市场上 Web 应用安全验证在覆盖面和严格程度上的差异。本文采用 5.0.0 版，但不声称它仍是当前版本。标准本身建议引用要求时加上版本前缀，例如 v5.0.0-1.2.5，因为编号可能在不同版本之间变化。对采购而言，这是一个很实用的细节：带版本的编号让发现可追溯，让复测可复现，即使复测由另一家服务商执行。

OWASP Top 10：面向管理层的词汇

OWASP Top 10（2025 版，此前为 2021 版和 2017 版）定位为提升意识的文件，是迈向安全开发的第一步。它是与管理层沟通的便利语言，但不是测试计划。“测试 OWASP Top 10”这种表述，远比绑定到具体 WSTG 测试和 ASVS 要求的范围更窄，也更难核查。

NIST SP 800-115：流程框架

SP 800-115 于 2008 年 9 月发布，取代了 SP 800-42。它就技术测试的规划与实施、发现的分析以及风险缓解策略的制定提供了实用建议，并强调了每种技术的优势与局限。从形式上看，该指南把评估分为三个阶段：规划、执行和执行后阶段，后者包括结果分析和提出建议。文件没有为现代云和 API 场景提供完整方法，NIST 本身也将其定位为关键要素的概览，而非完整的测试方案。但作为流程框架，它依然有用。

对于专业领域的工作，这些文件并不足够。例如在评估运营技术（OT）时，应参考行业材料，包括 CISA 面向 OT 所有者和运营者、关于选择数字产品时应考虑哪些因素的指南，并引入单独的专业力量。

优先检查哪里：弱点类别及其根本原因

有经验的顾问不只是逐项跑测试。他们知道在你的技术栈中哪些弱点类别值得特别关注，并能通过根本原因来解释一项发现。

MITRE 的 2025 年 CWE Top 25 在这里很有帮助，它是对已公开漏洞背后严重弱点的排名。关键是要正确解读：CWE 分类的是弱点类型，而不是某个具体系统被利用的概率。在榜单上排名靠前，并不意味着你的系统存在这种缺陷，也不意味着它一定会被利用。对采购方而言，这份榜单的价值在于另一处：可以借它检查报告解释的是根本原因还是仅仅是症状。

MITRE 还发布了相关的 CWE Top 10 KEV 弱点榜单，依据 CISA 已知被利用漏洞（KEV）目录对弱点排序，也就是依据有记录的实际利用情况。这是一个有用的优先级参照，因为它突出显示了已确认被利用漏洞目录中出现的弱点类别；但榜单本身并不能确定某个具体系统被利用的可能性。

CISA“设计即安全”的材料指向同一方向：其中有关于跨站脚本、操作系统命令注入和目录遍历的警示，CISA 与 FBI 还联合发布了针对缓冲区溢出的警示。ASVS 方面也包含防范操作系统命令注入的要求。当某个弱点类别同时出现在 MITRE、CISA 和 OWASP 的材料中，并且与你的技术栈相关时，应在范围中明确写出，而不是指望服务商默认会检查。

症状与原因的区别，用一个假设的例子就很容易说明。报告写道：“搜索框存在 XSS。”开发人员对一个参数做了转义，复测通过，一个月后同样的缺陷又出现在商品目录的筛选器中。好的报告会换一种表述：该模块关闭了模板引擎的自动转义，因此该模块中任何用户提供的字符串都可能带来危险。这样的表述引导修复整类问题，而不是单个实例。

顾问应向开发人员讲清楚的 HTTP 机制

Web 测试需要熟练掌握 HTTP，好的报告用这种语言与开发人员沟通。单个 HTTP 请求并不携带此前交互的记忆，但应用可以在 HTTP 之上保持状态：服务器端会话可以由 cookie 标识，其他方案则使用令牌。因此测试人员要检查会话如何签发、绑定在什么上、何时以及如何失效，以及在退出登录或修改密码之后会话会怎样。

有两种机制经常成为配置错误的来源。内容安全策略（CSP）可以限制资源加载，并在配置报告功能时暴露策略违规；它是额外的防御层，不能替代正确的输出编码。CORS 决定浏览器中的脚本能否读取来自其他源的响应，它不是服务器端的授权机制。当浏览器会发送可用凭据，而且策略使敏感响应可被外部站点读取时，过于宽松的 CORS 才会形成相应风险；严格策略仍不能保护 API 免受直接请求。Cross-Origin-Resource-Policy 头也有类似的细节：它可以阻止页面获取某些 no-cors 响应的内容，却不一定能阻止请求本身被发出。把这些机制与访问控制混为一谈的顾问，会给出错误的建议。

采购方需要权衡的取舍

深度与广度

对单个关键应用进行窄而深的测试，可能发现广泛扫描遗漏的攻击链；广泛扫描则可能找到深度测试边界之外的被遗忘资产。SP 800-115 强调每种技术的优势与局限并非没有道理：没有哪一种方法能提供完全的确定性，在它们之间做选择是一项管理决策。

真实性与安全性

测试越接近真实攻击者的行为，证据越有说服力，运营风险也越高。这种风险要在开始之前加以控制：书面授权、边界、测试时间窗、紧急联系人和停止条件。环境是另一个问题。在预发布环境测试更安全，但其结果不能不加说明地照搬到生产环境：那里的配置、数据、集成和安全防护可能都不同。

一次性检查与持续的信心

报告反映的是测试日期当时的系统。WSTG 自身也说明，其各版本反映的是发布时的状态，同样的逻辑适用于测试结果。在发布频繁的情况下，更有用的做法是围绕具体的、与安全相关的变更来安排检查：新的认证机制、新的外部集成、访问权限模型的变化。这并不意味着每次提交都需要单独做一次渗透测试。如何识别这类变更并围绕它们安排检查，我们在变更触发式渗透测试一文中做过分析。

找缺陷与消除原因

CWE 把理解根本原因视为消除整类缺陷的途径，例如内存安全或注入类问题。“设计即安全”倡导厂商在设计阶段就减少可被利用的缺陷。只罗列症状的项目，会让组织在下一个版本中依然带着同样的缺陷。

授权、安全规则与数据处理

授权不是走形式。许可必须来自每一个有权批准对相关资产和环境进行测试的一方。如果应用运行在云上，或依赖第三方 SaaS、CDN 或承包商的托管服务，这些主体可能有各自关于可接受测试的规则。一位高管在信函上的签字，并不能让对他人基础设施的攻击变得合规。

开始之前，应记录资产清单和明确的排除项、测试时间窗、双方的紧急联系人，以及立即停止工作的条件：例如服务不稳定，或发现真实入侵的迹象。如果报价方案对这些问题回答含糊，就是需要警惕的严重信号。

数据问题要单独约定。测试过程中，即使收集这些内容并非目标，服务商仍可能接触到个人数据、密钥和令牌。合理的做法是：日志和证据中只收集必要的最少内容，对密钥做脱敏，限制对材料的访问，保护其完整性，并事先规定保存期限和删除程序。也不要以为“只读”测试账号就一定安全：如果通过它能看到他人的文档或配置，那已经是相当重要的访问权限。

如果你还不确定项目应回答什么问题、应纳入哪些资产，可以在评估费用之前就与 Pentest.red 讨论。渗透测试范围确定页面说明了为这次沟通值得准备哪些关于资产、环境和约束条件的信息。

把发现转化为运营层面的改变

NIST 网络安全框架 2.0（CSF 2.0）旨在帮助组织理解并改进网络安全风险管理，其组成包括配置文件（profile）、快速入门指南和参考资料。如果把进攻性测试的发现表述为与 CSF 配置文件中目标成果之间的差距，它们会更有用：技术事实由此转化为有明确负责人的管理决策。

修复优先级不宜只看严重度标签，还应考虑可利用性和对外暴露程度。公开 API 中的中危漏洞，可能比隔离的内部测试环境中的高危发现更需要优先处理。与 CWE Top 10 KEV 弱点榜单和 CISA 建议进行对照，是优先级排序的一项输入，还要结合潜在影响、现有控制以及适用义务。

有些发现指向的不是配置错误，而是产品决策。“设计即安全”的材料呼吁厂商把多因素认证、日志记录等基础安全功能默认提供，而不是作为付费附加项。如果测试恰好在这些方面发现缺口，修复责任应在产品团队，而不只是管理员。

复测让循环闭合。带版本的 ASVS 编号和 WSTG 测试引用，使同一家或另一家服务商能按同一标准检查修复情况。ASVS 要求清单以机器可读的格式发布，包括 CSV 和 JSON，因此可以方便地在自有工具中跟踪覆盖情况。要记住，复测的结论只适用于所声明的范围和条件：修复了一个接口，并不能证明相邻接口也已得到保护。关于如何证明修复确实有效，详见渗透测试修复验证一文。

如果服务商提供借助 AI 的分析或报告，应像对待其他任何方法一样严格审查：人工如何复核结论，客户数据流向何处，谁有权访问这些数据。

如何选择服务商：检查方法与报告

既然 ASVS 的设立初衷就是统一市场上参差不齐的覆盖面和严格程度，采购时的第一项检查就是方法的透明度。请服务商展示其方法如何对应 Web 工作中的 WSTG 类别、需要验证所选应用控制时的 ASVS 要求，以及包含规划、执行、结果分析和缓解措施制定的流程。

第二是报告。一份有力的报告会指明受影响的资产，描述安全的复现方式，解释后果，给出 CWE 弱点类别，引用带版本的要求，并提出开发人员能够执行的建议。网站上的介绍并不够：请索取一份脱敏样例。

第三是上文讨论过的授权与安全。第四是利用现有的采购方指南。CISA 发布了面向与供应商谈判的软件采购方的“按需安全”（Secure by Demand）指南，以及单独面向 OT 所有者和运营者的指南。它们有助于向所有供应商提出相同的问题。更详细的方案比较方法，见我们的渗透测试服务商比较一文。

以下几个问题能快速区分出成熟的服务商：

• 哪些 WSTG 类别和带版本的 ASVS 要求在范围内，哪些被排除？
• 你们如何把发现对应到 CWE 类别，关于根本原因会写些什么？
• 开始工作前，你们要求哪些授权、停止条件和紧急联系人，由谁提供？
• 是否包含复测，复测结果是否引用相同的编号？
• 能否展示一份脱敏的报告样例，并以机器可读形式交付结果？
• 具体由谁执行工作，交付前如何检查报告质量？

工作循环：从问题到复测

SP 800-115 的正式阶段，即规划、执行和执行后阶段，描述的是评估过程本身。对采购方而言，最好再补充一个实践循环，它比测试开始得更早、结束得更晚。这不是标准的要求，而是作者的工作方案。

1. 明确问题确定需要哪种证据：发现、覆盖、针对所选安全措施的证据，还是抵御攻击的能力
2. 设定边界与授权记录资产、排除项、时间窗、数据处理、停止条件以及每个有权批准测试的一方的许可
3. 开展测试执行约定的检查，并记录确认每项发现时的条件
4. 分析根本原因在适用时把发现对应到 CWE 和 Web/API 要求，并指定修复负责人
5. 复测重复原始场景和相关变体，或说明等效检查的依据；明确限制结论

第一步比看上去更重要。问题模糊的项目，很可能以一份无法据以行动的报告收场。第二步要固定参照体系：对 Web 应用来说，是 WSTG 的具体版本和带版本的 ASVS 要求；与管理层沟通时，是 OWASP Top 10；排定优先级时，是 CWE Top 25 和 Top 10 KEV；与治理衔接时，是 CSF 2.0 配置文件。对于其他类型的系统，这套参照会有所不同。

测试结束后，每项发现都应交给具体团队，并根据风险、运行条件以及适用的监管或合同义务设定期限。连续几份报告应按相同的要求编号进行比较，从而看清消失的是整类弱点，而不只是个别实例。CWE 和“设计即安全”推动的正是这样的结果。

如果你希望与外部团队一起走完这个循环，可以与 Pentest.red 讨论具体条件：渗透测试服务的介绍有助于了解工作形式，而具体的范围、验收标准和复测安排，最好针对你的系统来商定。超出常规渗透测试的任务，例如法律意义上的认证或工业流程评估，需要单独的专业评估。

什么让进攻性安全咨询真正有用

当进攻性安全咨询获得所有有权批准者的授权、以双方都能理解的参照为依据、并与消除根本原因相结合时，它才真正有用。OWASP 提供测试目录和可验证的要求，NIST SP 800-115 提供流程框架，CWE 提供弱点类别的语言，而 CISA 则把责任推向安全设计和审慎采购。

回到开头的三份方案。选择的依据不应是最宽泛的承诺，而应看哪一份回答了你的问题、展示了方法、把发现与带版本的要求挂钩、解释了原因，并包含结论边界清晰的复测。这种做法能把一次性报告转化为可追溯的证据，用于验证修复并跨版本跟踪弱点类别；报告本身并不能保证风险降低。