软件供应链安全评估：如何检查供应商、依赖与构建流水线

先看一个假设场景。一家小公司运营在线预订服务。它的产品里有从厂商处采购的证件识别 SDK、来自公共仓库的几百个软件包（大多是传递依赖，团队里已经没人记得它们）、运行在云端 runner 上的构建流水线，以及一个支付组件——它会把支付合作方 CDN 上的脚本直接加载到结账页面。周一，团队发布了一个新版本，自己的代码一行都没改。可生产环境照样迎来了某个传递依赖的新次版本、更新过的构建 runner 镜像，以及合作方脚本的新修订版。

这个例子是为说明问题而虚构的，并非真实事件。但它点出了关键：生产环境中运行的大量内容既不是你的团队写的，也没有经过你的团队审查，而其中每一个环节都可能因失误或蓄意带来弱点。对自家应用做渗透测试，只能部分回答这个问题。

软件供应链安全评估要回答的问题更宽：某段代码、某个组件、某个构建步骤或某条交付渠道，是否可能把你没有预料到的东西带进生产环境？你手里是否有可核验的证据证明不会？下文介绍评估包含什么、如何开展、什么样的证据才算充分，以及怎样向服务方提出需求，才能让结果彼此可比。

软件供应链评估覆盖哪些内容

四个范围层级

第一层是采购的软件和厂商产品：成品系统、带集成的 SaaS、以二进制形式交付的 SDK 和库。在这一层，采购方通常透明度最低，但合同上的抓手最多。

第二层是开源和第三方组件，它们通过包管理器、vendoring 或干脆复制粘贴进入你的应用。这类组件数量多、更新节奏不受你控制，而且每一个都有自己的链条：维护者、仓库、发布流程。

第三层是构建与发布流水线，它把源代码变成可部署的制品：版本控制系统、CI/CD、runner、密钥存储、制品与容器镜像仓库。

第四层是运行时依赖。最直观的例子是用户浏览器代表你的网站加载的第三方脚本：统计分析、聊天组件、支付表单、A/B 测试。

每一层都需要自己的组合：文档审查、技术测试和合同核查。用同一个工具覆盖全部四层，是常见的陷阱。

流程审计与技术评估不是一回事

NIST SP 800-204D 讨论的是在 DevSecOps 中把软件供应链安全措施融入 CI/CD 流水线。由此自然引出一个重要区分。流程审计关心的是：每个环节归谁负责、谁审批变更、留下了哪些证明。技术评估检查的是：流水线中的信任边界在哪里、能否被跨越——能否替换依赖、在 runner 上执行代码、拿到签名密钥。

两者都需要，但回答的是不同的问题。一份整整齐齐的发布审批制度，并不能证明 runner 不会在能访问生产密钥的情况下执行外部人员 pull request 里的代码。流程方面的内容，可以参阅我们关于审计 DevSecOps 流程的文章。

为什么只扫描交付的制品远远不够

MITRE 发布 CWE Top 25 Most Dangerous Software Weaknesses（最危险软件弱点 Top 25）。2025 年版基于对当年数据集中 CVE 记录的根因分析。MITRE 认为这些弱点往往容易发现、容易利用；按其评估，它们会导致攻击者完全接管系统、窃取数据或破坏应用运行的漏洞。对于供应链评估而言，当受影响的软件被采购，或作为依赖进入另一家组织时，这些弱点类别就与评估相关。

MITRE 的另一个观点更重要：根因分析可以作为厂商开发生命周期和架构规划的反馈。它有助于消除整类缺陷，例如内存安全问题或注入问题，而不是发现一个修一个。

对供应链评估来说，由此可以得出一个实际结论。对交付版本跑一遍扫描器，看到的只是一张快照。它无法告诉你同类错误会不会在下一个版本中重现，也无法告诉你供应商修复它们有多快。因此，评估需要结合三件事：对交付产品做技术测试，了解它是如何构建出来的，以及检查供应商如何应对已发现的弱点。

举个假设的例子：两个库的发现数量相同。第一个库的问题是旧代码的遗留，而现有流程已经不会再放进新的注入问题。第二个库则是每加一个新功能，就多一条用字符串拼接出来的 SQL 查询。数字一样，风险却不同。

如何开展评估：从授权到复测

NIST SP 800-115 的流程框架

NIST SP 800-115（Technical Guide to Information Security Testing and Assessment，信息安全测试与评估技术指南）于 2008 年 9 月发布，取代了 2003 年的 SP 800-42。从形式上看，该文件把评估分为三个阶段：规划、执行和执行后工作，后者包括结果分析、报告以及制定缓解建议。它列出的目的包括发现系统或网络中的漏洞，以及核验是否符合政策或其他要求。当被检查系统的一部分属于供应商时，这两个目的都很重要。

该指南侧重于具体技术及其优势与局限，并明确说明它是关键要素的概览，而不是一套完整的测试方案。因此，合理的做法是把它当作程序框架——工作规则、技术选择、报告、整改跟踪——而检查本身的内容则取自更专门的标准。

SP 800-115 对应若干安全控制族，包括 System and Services Acquisition（系统与服务采购）、Risk Assessment、Assessment, Authorization and Monitoring 以及 System and Information Integrity。采购控制族的存在是个很好的提醒：评估范围不仅包括你开发的东西，也包括你购买的东西。

实践中的工作循环

在正式阶段之上，可以搭建自己的工作循环。这是作者的实践方案，并非标准本身的结构。

一切从盘点开始：有哪些供应商、组件和流水线，其中哪些是关键的。接着需要书面授权和工作规则，并与每一个系统所有者达成一致，包括其环境可能受影响的供应商。然后是文档审查：开发实践、组件清单（如果供应商提供 SBOM）、以往评估报告、漏洞披露政策。之后是对交付制品和集成应用开展经授权的技术测试。循环的收尾是对照特定标准版本的要求进行分析，并在合同双方指定整改负责人、确定复测日期。

1. 盘点列出供应商、组件、流水线和第三方脚本，并按业务影响排序。
2. 授权与每一个系统所有者（包括环境可能受影响的供应商）商定书面授权和工作规则。
3. 文档与测试审查开发实践和组件清单，再对制品和集成开展经授权的技术测试。
4. 分析将发现对应到特定标准版本的要求和根因类别，并注明证据类型。
5. 整改与复测在合同双方指定负责人，确定期限，并对修复进行复测。

授权与环境：结果能支撑哪些结论

在测试第三方产品之前，应确认书面权限：产品部署在你的基础设施中这一事实本身并不能确定允许测试的范围，许可协议或 SaaS 条款也可能限制此类行为。授权书应列明系统、允许使用的技术、测试时间窗口以及发生故障时的联系人。

第二个细节是环境。测试常常在预发布（staging）环境进行，这很合理，但其结果不能不加说明地照搬到生产环境。组件版本、配置、所接入的集成以及网络限制都可能不同。报告应明确写出每项检查在哪里进行，以及已知与生产环境存在哪些差异。

如果你是第一次梳理这样的范围，值得提前讨论：哪些属于你、哪些属于供应商、哪里需要单独同意、需要什么样的证据。你可以通过范围描述表单与 Pentest.red 沟通这些问题。需要明确边界：渗透测试提供技术发现和证据，但它不是认证、鉴证，也不是合规意见。

把构建流水线当作信任边界

边界在哪里

构建流水线是源代码变成用户实际拿到的东西的地方。因此，应把它看作一串信任边界，而不是一堆工具。技术评估中的典型问题是这样的：谁能绕过评审修改主分支？runner 是否会执行外部贡献者 pull request 中的代码，这个任务能否访问密钥？依赖从哪里解析——内部镜像，还是直接从公共仓库？同名的公共包能否顶替内部包？第三方 CI action 和基础镜像是固定在不可变标识上，还是固定在所有者可以重新指向的标签上？谁对制品仓库有写权限？

关于基础设施即代码，还需单独说明：对 Terraform 模板或清单做静态分析，并不能证明实际运行的环境与源码一致，因为手工改动和配置漂移不会进入代码仓库。详见我们关于基础设施即代码安全评估的文章。

制品来源证明及其局限

SLSA 1.2 规范把构建来源证明（build provenance）描述为可核验的信息，用于把成品制品追溯到其源代码和构建过程。要据此判断制品是否符合预期，核验方还需把来源证明与制品本身绑定、验证签名、确认构建者身份属于信任根，并将各字段与预先设定的预期策略进行比较。

但即使经过核验，来源证明也只能确认其中声明且已检查的来源属性，不能证明制品没有漏洞或恶意代码。如果攻击者拿到了代码仓库的写权限，而预期策略允许该修订版，真实性核验通过的来源证明仍会如实说明：这是用已被篡改的源码构建的。只有在核查了规范特定版本的要求之后，才能声称产品达到某个 SLSA 等级，而不能仅凭存在签名就下结论。

下表汇总了各范围层级、典型故障点以及实际能拿到的证据类型。

带版本号的要求：让结果可以比较

把 ASVS 当作合同语言

采购这类服务时，最大的问题是结果不可比。有的服务方把粗略浏览一遍称为"评估"，有的则指数周的人工核验。OWASP ASVS 的初衷之一，就是通过一个开放且可商用的标准，拉平 Web 应用安全验证在覆盖范围和严格程度上的差异。它为检查应用及其环境中的技术安全控制提供依据，同时也是一份安全开发要求清单。本文所说的是 5.0.0 版。

与供应商打交道时，ASVS 还可以充当合同语言。要求编号可能在版本之间变化，因此 OWASP 建议连同版本号一起书写，例如 v5.0.0-1.2.5。不带版本号的编号默认指向标准的最新版本——也就是说，旧合同中某条引用的含义可能在不知不觉中改变。要求清单以机器可读格式发布，包括 CSV 和 JSON，因此很方便嵌入问卷、合同和任务跟踪系统。

如果采购方既不写明 ASVS 版本、也不写明级别，评估依据就会含糊不清，结果也会更难在供应商之间或同一供应商的两次评估之间进行有效比较。

其他参考资料及其作用

OWASP Web Security Testing Guide（WSTG）描述的是测试流程。在原始材料撰写时，稳定版为 4.2，5.0 版尚在开发中，因此值得事先约定服务方依据哪个版本工作。2025 年版 OWASP Top 10 是一份提升意识的文件，反映了业界对最关键 Web 应用风险的广泛共识。它是合理的最低参照，但不是验证标准。2025、2021 和 2017 三个版本同时存在，再次说明不写年份地引用"OWASP Top 10"是含糊的。

这里还有一个重要限制。ASVS、WSTG 和 OWASP Top 10 面向的是 Web 应用。构建系统、打包、移动 SDK 以及其他非 Web 组件需要调整后的标准，报告应明确指出参考标准在哪里不再适用。

浏览器中的第三方代码：采购清单里看不到的供应商

你的页面从别人的域名加载的脚本，是以你网站的权限运行的：它能看到 DOM、表单字段以及没有 HttpOnly 标志的 cookie。然而它的供应商往往没有经过任何评估：脚本是市场部门加上的，合同里也不涉及安全。

浏览器提供了几种限制后果的机制。Content Security Policy（内容安全策略）可以规定客户端能为页面加载哪些资源，有助于缓解跨站脚本和数据注入攻击。Cross-Origin Resource Policy（跨源资源策略）让网站可以为自己的资源启用针对某些跨源请求的保护。Permissions Policy（权限策略）明确规定网站代码可以使用哪些浏览器功能，例如摄像头、地理定位或支付 API。对于内容固定的外部脚本和样式表，可以声明 Subresource Integrity（子资源完整性）加密哈希；如果收到的字节与哈希不符，支持该机制的浏览器将拒绝执行脚本或应用样式表。对跨源资源，供应商服务器必须通过 CORS 允许请求，元素也必须使用 crossorigin。如果供应商有意在同一地址动态更改内容，发布时必须同步更新哈希，否则完整性检查会阻止更新。

Mozilla HTTP Observatory 等工具可以帮助检查配置。这些措施能缩小攻击面，但不能替代对代码供应商本身的评估。一条放行支付合作方域名的严格 CSP，在这个域名本身被攻陷时也无济于事。

如何利用弱点数据确定优先级

2025 年 CWE Top 25 还附带两份清单。On the Cusp 收录了以微弱差距落选主榜的弱点。CWE Top 10 KEV Weaknesses 则对 CISA 已知被利用漏洞（KEV）目录中正被积极利用的漏洞背后的弱点进行排名。三者合起来提供了三个层面：常见且危险的弱点、处于边缘的情况，以及在真实攻击中出现过的弱点。

与供应商合作时，这些清单有两种用法。第一，询问每一家关键供应商：它的开发流程如何预防、发现和整改这些清单中的弱点类别。具体的回答——评审中内置了哪些检查、用了哪些分析工具和规则、如何跟踪修复——本身就能说明成熟度。含糊其辞的回答同样能说明问题。第二，把对你最重要的组件的技术测试向这些类别倾斜。例如，MITRE 指出操作系统命令注入很受攻击者关注。如果某个 SDK 会把用户输入传给外部工具，这就是一个显而易见的测试点。

MITRE 把这类清单与减少漏洞、节约成本和客户信任联系在一起，而供应商在处理这些弱点上的公开程度，也是判断其对产品安全态度的有用信号。

这里需要谨慎。基于公开 CVE 记录的排名反映的是被报告和被分析过的内容，而不是所有产品中的所有弱点。可以用它来聚焦精力，但某家供应商在这些类别中没有发现，并不意味着它是安全的。如何把这类数据变成工作队列，可以参阅我们关于基于风险的漏洞优先级排序的文章。

需要事先商定的取舍

深度与广度

按 ASVS 高级别对一家关键供应商做深度验证，所需精力可能和粗略审查几十个低风险组件差不多。这种取舍应当明确。按业务影响对供应商排序，并把排序写进评估计划，这样半年后也能说清楚，为什么一家花了两周，另一家只发了一份问卷。

文档证据与技术证据

问卷便于规模化，但取决于填写者的诚实和能力。技术测试能提供更有力的证据，但需要授权、环境以及供应商可能加以限制的访问权限。SP 800-115 关于权衡每种技术优势与局限的原则在这里直接适用。一条实用规则是：在每项发现中注明它基于哪类证据——"经测试确认"、"供应商声明"或"由文档推断"。

一次性评估与周期性评估

SP 800-115 发布于 2008 年，作为流程参考依然有用，而 ASVS 5.0.0 和 2025 年的各份清单以后可能修订。任何评估都只是检查当日的快照。如果没有与供应商重大版本和标准更新挂钩的复测计划，随着时间推移，这份文件对当前风险的说明力会逐渐减弱。触发复测的好时机是重大变化：SDK 新的主版本、更换 CI 平台、在敏感页面上新接入第三方脚本。

如何把发现变成工作和验收决策

把发现当作工程任务

评估结果只有变成有负责人的任务才有用。每项发现都应记录证据依据、供应商方或公司内部的负责人以及复测条件；带版本号的要求引用和根因类别只在适用时添加。复测是一项单独的工作：应在约定的路径和场景中检查整改是否覆盖问题类别，而不只是演示过的例子；结论仍受该测试范围限制。如何证明这一点，请参阅我们关于渗透测试整改验证的文章。

为了不让结果停留在一份孤立的技术报告上，应把它与风险管理联系起来。NIST CSF 2.0 的配置文件（Profile）可以描述当前状态和目标状态，这样管理层就能把供应链评估结果与其他网络风险指标放在一起看。

验收决策方案

这套决策方案仅作示例：最终决定应由获授权的风险负责人结合具体情境和剩余风险作出，单一数值评分不能代替这项判断。先按业务影响和暴露程度对供应商和组件排序。对于 Web 应用和 API，选定 ASVS 的版本和级别，并注明 OWASP Top 10 的年份，将其作为安全意识参考；对于构建流水线、打包系统、移动 SDK 和其他非 Web 组件，则选择适用且注明版本的系统专用标准。然后决定哪里需要技术测试、哪里有文档就够，并把测试向 CWE Top 25 和 Top 10 KEV 中的相关类别倾斜。记录决策及其理由，并把重新评估安排在重大版本发布和标准更新时。每一项决策都应能追溯到适用且带版本号的标准和证据类型。

如何选择服务方，以及开工前要讨论什么

只有在内部范围和方法清楚之后，才值得比较服务方：目标是可比、可复现的证据，而不是一份带着响亮名头的报告。可以向每个候选方提出同样的问题。

他们会引用哪些标准和版本？每项发现是否都带有带版本号的要求编号？他们如何区分文档审查和技术测试，又如何记录证据类型？书面授权流程是否涵盖供应商的系统，是否保证未经每个所有者明确同意不开始测试？能否提供一份样本报告，包含按 CWE 做的根因对应以及整改验证部分？他们的方法如何处理非 Web 组件、构建流水线和第三方客户端代码？如何应对标准更新，例如 WSTG 新版本的发布？

对无法核实的说法要保持谨慎。认证、客户名单和检出指标都需要独立核实。关于供应商风险的更宽视角，可参阅我们关于第三方风险安全评估的文章；软件供应链评估则是对其技术部分的深化。

如果你想把其中一部分工作交给外部团队，可以与 Pentest.red 讨论技术范围：测试哪些组件、流水线和集成，在哪些环境中，需要哪些授权，以及证据以什么形式提交。渗透测试服务介绍和范围描述表单可以帮助你做好准备。如果你需要的是法律意见、认证或鉴证，则需要单独的合格评估——渗透测试无法替代。

结论：可复现比漂亮的报告更重要

软件供应链安全评估之所以有用，在于它可以重复、可以比较：它与标准版本绑定，区分证据类型，并通过根因解释发现。流程框架、可核验的要求和根因数据是三根不同的支柱，任何一根都替代不了其他两根。

无论是自己开展评估还是委托他人，都要坚持三点：经授权且描述明确的范围、带版本号的要求，以及标注了证据类型的根因报告。正是这些让结果在不同供应商之间、在不同时间之间可以比较——也让你在一年后能够判断情况是否有所改善。