第三方风险安全评估：如何核查供应商与SaaS的安全性

供应商的问卷三天后就交回来了。两百多道题，几乎全部回答“是”：有加密，有多因素认证，“定期开展渗透测试”。附件是一份两页的测试报告摘要。采购部门很满意：从纸面上看，一切就绪，可以签约。

这个例子是假设的，但很常见。一家公司正在挑选云端HR平台。平台将接收员工个人数据，通过单点登录接入企业目录，并为同步账号获得一个带写权限的API令牌。仔细看附上的摘要，会发现它是一年半以前的，而且描述的是产品的另一个版本，其中并不包含买方即将启用的集成模块。至于令牌一旦从供应商一侧泄露会怎样，问卷只字未提——里面根本没有这个问题。

这正是第三方风险安全评估要解决的问题。问卷收集的是声明，而信任决策应当建立在证据之上，证据的分量要与供应商对您的数据和系统所掌握的权力相称。下文将说明：如何确定评估范围，如何搭建证据阶梯，如何解读别人的渗透测试报告，允许测试的边界在哪里，以及如何把结果转化为采购和合同决策。

第三方风险评估究竟评估什么

第三方风险安全评估回答一个实际问题：能否把您的数据、用户和业务流程托付给某个具体的供应商、软件开发商、云服务或托管服务商，以及在什么条件下托付。好的评估把治理证据、技术验证和合同跟进结合起来。最终买方了解的不是供应商如何自我描述，而是它能够证明什么。

可以从三个层面来思考。第一是组织治理：供应商如何管理网络风险，由谁负责，事件响应和漏洞修复如何运作。第二是产品安全：软件如何设计、开发和测试，哪些类别的错误在架构层面被排除。第三是运营暴露面：供应商把什么暴露在互联网上，配置是否严谨。还应加上常被忽视的第四个层面——对接点：供应商通过集成、令牌、账号和网络访问，在您的基础设施内部获得了哪些权限。

先说边界。这是评估；主动测试必须取得所有有权批准受影响系统和环境中相关工作的主体的书面授权。采购合同可以包含这种授权，但购买行为、试用账号或公开网站本身并不会自动授予授权。在买方控制范围内本地检查配置，与向供应商管理的环境发送主动测试请求是两回事。本文任何内容都不构成探测他人系统的许可。

为什么供应商的风险会变成您的风险

CISA的“设计即安全”（Secure by Design）倡议基于这样的观察：网络安全的负担不成比例地落在技术使用者和小型组织身上，而不是制造商身上。该机构呼吁供应商在高层管理层面承担产品安全责任。对买方而言，核心问题随之改变：只知道自身边界有多牢固是不够的，还要弄清随所购产品或服务一起继承了哪些风险。

这种风险通过非常具体的路径被继承。如果供应商的产品存在注入缺陷或访问控制失效，无论您自己的防护多完善，存放其中的数据都会暴露。如果供应商保管着您的目录访问令牌，其基础设施被攻破可能使攻击者触达该令牌可访问的操作、对象和系统；实际影响半径取决于令牌的存储方式、有效期与范围，以及网络控制和下游授权。MITRE的CWE Top 25依据真实公开漏洞背后的弱点编制，MITRE认为这些弱点往往容易发现和利用，可导致系统被接管、数据被窃取或应用停止运行。架构和工程控制可以防止其中一些具体变体，或降低其发生概率与影响；测试和监控只能对既定范围内的剩余风险提供有限证据。

供应链还有更深一环。CISA称开源软件是数字基础设施的基础组成部分，其内存安全指南要求制造商在外部依赖中同样考虑这一问题。您的供应商也有自己的供应商——托管、程序库、支持外包方。止步于第一环的评估只能看到局部。NIST SP 800-161 Rev. 1论述面向系统和组织的网络安全供应链风险管理实践，对这一主题有系统阐述。关于依赖、构建和组件来源的深入核查，请参阅我们的软件供应链安全评估一文。

应依据哪些文件，各自用于何处

本文采用的任何一个来源都不能单独提供这里所述的完整第三方评估方法，因此要弄清每个来源解决什么问题。

NIST网络安全框架（CSF）2.0提供了一套关于治理成果的通用语言。借助其“配置文件”（Profiles），可以描述对某一级别供应商期望的状态，并与实际状态比较。它是与采购和业务流程负责人沟通的工具，而不是测试方法。NIST SP 800-161 Rev. 1则专门针对供应链：如何把对供应商的要求嵌入组织流程，如何在从企业到单个系统的不同层级考量风险。

技术部分可参考2008年9月发布的NIST SP 800-115《信息安全测试与评估技术指南》。它把评估分为三个阶段：规划、执行和执行后，最后一个阶段包括结果分析和制定风险缓解建议。该文件支持两个目标：发现漏洞，以及验证是否符合策略或其他要求。其中的工具示例已经过时，但规划和分析的逻辑依然适用。

对于Web应用和SaaS，OWASP提供了用途不同的三层资料。OWASP Top 10是关于最关键风险的意识提升文件，有2017、2021和2025年等版本，记录中应写明引用的是哪一版。ASVS（5.0.0版）规定了可验证的安全控制要求，并明确以统一市场上验证工作的覆盖范围和严格程度为目标。WSTG说明具体如何测试；本文示例采用WSTG 4.2，每份报告都应记录实际采用的版本。

CISA的资料补充了买方视角。“按需安全”（Secure by Demand）指南面向与供应商和经销商的软件采购谈判；另有一个版本面向运营技术（OT）的所有者和运营者。CISA还与澳大利亚ASD's ACSC联合发布了关于选择安全且可验证技术的指南。它们不是合规标准，而是问题清单，能帮助把抽象的“安全”变成具体的谈判条款。

供应商分级与证据阶梯

如何对供应商分级

第一步是分级，这是实践判断，而非公开规则。考虑四个因素：供应商处理的数据有多敏感；是否拥有对您系统的特权访问；与身份系统和生产环境集成得有多深；业务关键程度，即供应商不可用或被攻破时什么会停摆。

一个处理个人数据、通过单点登录接入并自动创建账号的薪酬SaaS，需要的审查深度远远超过一个为演示文稿生成插图、不接触任何数据的服务。级别决定了要索取多少证据，以及技术验证是否值得。

证据阶梯

应针对具体主张和风险组合证据。问卷记录自我声明；文件说明策略、安全开发生命周期和漏洞管理记录；独立报告描述采用明确方法、范围和日期的测试；对自身集成的核查以及经授权的产品测试回答不同的技术问题。不能把这些证据类型普遍按强度或成本排序，应比较其范围、访问条件、方法、能力和日期。

核查您自己一侧的集成是另一回事。没有必要授权时，不能向供应商平台发送主动测试请求；但在买方控制范围内本地检查您的目录配置、发给供应商的令牌、服务账号权限以及接收Webhook的处理程序都属于您的责任范围。这项检查直接反映您授予的权限以及供应商被攻破后的潜在影响；成本和完整程度取决于具体集成。

如何规划技术工作而不越过他人边界

技术工作最好遵循SP 800-115的逻辑。规划阶段确定目标、范围、方法和交战规则；执行阶段收集数据；执行后阶段分析结果、剔除误报并形成建议。对于有Web界面的产品，把范围对应到WSTG的测试领域，并把预期的安全控制写成带版本号的ASVS要求。这样，结果在不同供应商之间、在多轮复评之间都具有可比性。

在三个正式阶段之外，还应记住报告之后开始的实用修复循环：发现问题、供应商一侧修复、对修复进行复测、记录关闭证据。这是作者的工作方法，不属于SP 800-115，但没有它，评估就只停留在罗列问题上。

测试授权

主动测试供应商托管的系统，需要所有有权批准受影响资产和环境中相关工作的主体提供书面授权。授权中要写明范围、时间窗口、双方联系人、数据处理规则以及停止工作的程序。在多租户平台上，基础设施所有者可能根本不允许测试共享组件，或只允许在专用环境中测试。此时要记住：预发布环境的结果只描述该环境，结论是否适用于生产环境，应通过比较版本、配置、数据、身份、权限、集成与实际控制措施来说明；重大差异需要另行约定检查。

不干预也能看到什么

在正常、合法使用产品的过程中，可以获得一部分信号。MDN介绍了HTTP安全机制：有助于发现和缓解跨站脚本与数据注入的内容安全策略（CSP）、CORS、跨源资源策略（CORP）、权限策略以及Cookie属性。查看供应商应用在正常使用时返回的响应头，是判断配置是否严谨的低成本指标。它仅仅是指标：缺少某个响应头不能证明存在漏洞，有了它也不能证明安全。它也不能替代经授权的测试：枚举路径、模糊测试参数和扫描都已属于干预。

应向供应商索取哪些技术证据

用带版本号的要求代替“我们遵循OWASP”

ASVS让声明变得精确。每条要求都有数字编号；由于编号可能随版本变化，OWASP建议采用带版本的写法，例如v5.0.0-1.2.5——即5.0.0版“编码与净化”一章中“注入防护”一节的第五条要求。请供应商用这样的编号说明测试覆盖范围，含糊的“我们遵循OWASP最佳实践”就无处藏身。ASVS要求以CSV、JSON等机器可读格式发布，因此可以用程序构建和处理问卷，比较不同供应商的答复。

关于弱点类别的提问

“你们安全吗？”这个问题几乎没有用。“你们在架构上消除了哪些弱点类别，又如何验证？”才提供了可评估的材料。MITRE把CWE Top 25定位为对开发生命周期和架构规划的反馈，旨在消除内存错误、注入等整类缺陷。CISA“设计即安全”系列警示聚焦于消除跨站脚本、操作系统命令注入、目录遍历和缓冲区溢出。好的供应商回答是具体的：默认自动转义的模板引擎、不把用户数据传给操作系统Shell、禁止任意文件路径、新组件采用内存安全语言——以及在构建和代码评审中如何强制执行这些做法。

MITRE还发布过基于CISA“已知被利用漏洞”（KEV）目录的弱点排名。它有助于确定重点：真正被利用的弱点应当最先提问。

默认安全及其价格

CISA强调产品应当“开箱即安全”，多因素认证、日志记录和单点登录等基础安全功能不应额外收费。这一点对照价目表就能核实。如果审计日志和单点登录只在企业版提供，而您购买的是基础版，那么您买到的是一个无法调查事件的产品。

您一侧的集成

请供应商说明集成所需的最小权限，并与其接入时实际申请的权限比较。同步只需读权限却给了目录写权限的令牌、过宽的OAuth授权范围、不校验签名的Webhook、拥有管理员权限的服务账号——这些都可以在您自己一侧发现并修正，无需测试任何他人系统。SaaS集成的常见失效点，请参阅SaaS公司渗透测试一文。

如果需要划清哪些可以在自己一侧检查、哪些需要供应商同意，这很适合作为范围沟通的话题。在渗透测试范围沟通页面上，您可以描述集成方式、角色和手头已有的供应商报告，以便共同确定对您一侧的检查以及证据索取的形式。

如何解读供应商的渗透测试报告

独立报告增加了已执行测试的观察，而问卷记录的是声明；结论的可信度取决于每项证据的范围、访问、方法、能力和日期。引用WSTG或SP 800-115、与ASVS对应固然有帮助，但这本身并不能证明深度。要读的不是封面，而是范围、日期、发现的问题以及这些问题的后续处理。

首先，比较被测对象与您要购买的对象：是否同一模块、同一产品版本、同一托管区域、同一部署模式。其次看日期和变更历史。报告发布后的大规模架构重构可能显著降低其相关性；应要求提供变更差异分析，或覆盖已变更模块、环境和集成的更新测试。渗透测试是某一时点的快照，不是认证，也不是合规意见，供应商不应把它当作担保。

再看发现的内容。如果报告声称“未发现严重漏洞”，却没有说明测试了哪些角色、场景和接口，这一结论就无法解读。如果有发现，关键是如何修复、修复是否经过复测。如何区分确认有效的修复与仅仅关闭的工单，详见渗透测试修复验证一文。

问卷、报告还是自行测试：如何权衡

问卷易于规模化：发放成本低，比较方便。但每个答案都只是声明。问卷适用于低级别供应商，也可作为确定深入审查范围的输入。当问题引用带版本号的ASVS要求和具体弱点类别，而不是“您是否遵循最佳实践”之类措辞时，问卷的价值会明显提高。

独立报告更有力，但取决于谁测试了什么。审阅报告需要专家投入时间，他们要能分辨形式化报告与有实质内容的报告。如果组合中有几十家高级别供应商，就应提前把这部分工作量纳入项目资源。

买方发起的测试回答约定的技术问题，并受所授访问权限、场景和范围限制。它需要明确授权，可能与共享平台的使用条款冲突，并带来协调成本。SP 800-115强调要理解每种方法的优势和局限；实际中这意味着按风险选择方法，而不是追求最大程度的干预。

最后，任何单次评估都只是快照。产品在变化，CWE Top 25在更新，标准在推出新版本。没有复评的项目会逐渐偏离真实风险，即使首次审查时一切都做得正确。

持续的供应商风险管理项目

借助CSF 2.0的配置文件，可以为每个供应商级别描述目标安全成果，并记录每家供应商相对于目标的当前状态。这样，问题清单就变成采购人员和流程负责人都能看懂的差距分析，不同供应商的决策也能保持一致。

1. 确定级别数据、特权、集成深度和业务关键程度决定对供应商审查的深度。
2. 索取证据围绕具体风险组合适当证据：问卷、文件、独立报告、集成核查或经授权的测试。
3. 核实与映射将范围、日期和版本与所购产品核对；技术弱点适用时映射到CWE，应用控制发现映射到带版本的ASVS，否则记录其他标准或不适用原因。
4. 作出决策批准、有条件批准、待证据补齐后再议或拒绝——并记录理由。
5. 关注触发条件重大版本发布、所有权变更、安全事件、新数据流或合同续签都会触发复评。

不要只依赖年度周期，而应设定复评触发条件。实际有用的包括：产品重大版本发布、供应商所有权变更、安全事件、新的数据流或集成，以及合同续签。其逻辑与变更驱动的渗透测试相同：检查发生变化的部分，而不是全部从头再来；详见变更触发式渗透测试一文。

每项修复任务都要跟踪负责人、期限和关闭证据。在适用时，把技术弱点映射到CWE，把应用控制发现映射到适用且带版本号的ASVS要求；其他发现则记录相关合同或控制标准，或说明为何不适用。如果多家供应商同时在会话管理或注入方面遇到困难，这就是一种规律，应体现在合同模板和下一轮采购的问题中。

还要始终记录每份参考资料使用的版本以及每项证据的获取时间。标准会更新版本、也会过时，因此正是带日期和版本的记录，才能让供应商档案在审计中或事件发生后站得住脚。

合同与采购：买方真正的筹码在哪里

买方影响力最大的时候是在签约之前。作为实践建议，可以考虑以下条款：获取最新独立测试报告的权利、供应商就重大安全相关变更进行通知的义务、严重问题的约定修复期限，以及请求和批准买方发起测试的明确程序。具体措辞及其法律效力是律师的问题，而不是安全报告的问题。

向供应商提的问题要具体。多因素认证、日志记录和单点登录是否包含在您的套餐中且不额外收费？是否公开了内存安全路线图，是否覆盖外部依赖？哪些弱点类别在架构上被消除，如何强制执行？测试覆盖哪个ASVS版本、哪些要求？如果供应商加入了CISA自愿性的“设计即安全”承诺，其公开的进展材料显示了什么？承诺本身不是认证，但进展报告是具体的材料，可以阅读并与问卷答复相互印证。

如何选择供应商评估服务商

聘请外部团队审查供应商时，要评估的是流程而不是营销。寻找依据SP 800-115、WSTG等公认来源的方法；适用结果与注明的ASVS版本或CWE编号对应，其他结果则对应相关合同或控制标准；书面的交战规则，以及取得所有有权批准相关工作的主体授权的清晰程序。报告应包含可复现的发现、明确的范围局限和切实可行的修复建议。

询问服务商：在任何主动测试之前如何记录授权，如何说明未测试的区域，如何验证修复并记录证据日期。承诺保证结果，或愿意在没有取得所有有权批准相关工作的主体书面授权时测试他人系统，都是危险信号。按这些标准比较服务商，可参考渗透测试服务商比较一文。

如果问题涉及行业合规、认证或正式的审计意见，那是另一项工作，需要具备相应资质和权限的机构来完成；渗透测试不能替代此类意见。在Pentest.red的渗透测试服务范围内，可以讨论对您一侧集成的检查、对供应商报告的审阅，以及对供应商产品的测试——后者仅在取得所有有权批准受影响资产和环境中相关工作的主体书面授权后进行。

评估决策以及如何使其站得住脚

每次评估都应以四种有记录的结果之一结束：批准；有条件批准，例如附带合同修复承诺或限制集成权限；推迟到提供具体证据之后；拒绝。记录理由、所审阅的证据及其日期和参考资料版本。这能加快复评并保持一致。

回到开头的例子。合理的结果很可能既不是“签约”也不是“拒绝”，而是“待证据补齐后再议，同时缩小影响半径”：索取覆盖集成模块和当前版本的报告，确认所选套餐是否包含审计日志，并立即把令牌限制到同步所需的准确操作、对象、租户和属性，或在取得充分证据前暂停或撤销不必要的写权限。这样的决策既能向采购解释，也能向审计人员解释。

第三方风险评估要发挥作用，就必须以证据为基础、与风险相称，并与标准版本挂钩。以这种方式建立供应商审查的组织，能够向管理层、监管机构和审计人员说明为何信任每一家供应商，以及什么情况会改变这一决定。