近期，多起开源组件投毒和闭源软件漏洞披露事件再次将软件供应链安全推至企业采购决策的前台。对采购方而言，问题已不再是“是否要关注”，而是“如何在采购流程中有效核验”。当供应商的销售材料普遍宣称“安全合规”“响应迅速”时，采购方真正需要的是将抽象承诺转化为合同条款、交付物和持续维护阶段可验证的具体证据。
供应商声明与可验证证据的差距
软件供应链安全的核心难点在于信息不对称。供应商官网的安全白皮书、宣传册上的“通过等保三级”“符合ISO 27001”等标识，属于营销层面的声明，并不等同于产品本身在组件层面的安全性。一个常见误区是，采购方将企业资质认证等同于软件代码安全，但前者衡量的是供应商内部管理流程，后者才是采购合同实际交付的客体。
可验证的证据链条应当从三个层面展开：组件清单（SBOM，软件物料清单）是否随交付物提供、已知漏洞披露记录是否可追溯、漏洞修复承诺是否有合同约束。其中，SBOM 是核验的起点——它列出了软件中包含的每一个开源或第三方组件及其版本号，是判断漏洞影响范围的基础。没有 SBOM，采购方在漏洞爆发时甚至无法快速评估自身是否受影响，更遑论要求供应商限期修复。
采购合同阶段的核验要点
在合同谈判阶段，采购方应围绕软件交付的透明度要求设定明确条款，而非停留在原则性表述。
组件清单的交付义务应明确：供应商须在交付时提供机器可读格式（如 SPDX 或 CycloneDX 标准）的 SBOM，并约定在软件生命周期内组件发生变更时更新清单的频率。需警惕供应商以“商业机密”为由拒绝提供完整清单——SBOM 仅包含组件名称、版本和许可证信息，不涉及源代码，属于行业通行的安全交付物。
漏洞披露渠道与时限应写入合同：供应商是否有公开的漏洞披露页面或安全公告渠道？发现漏洞后的披露时限是多久？对于被利用的高危漏洞，行业常见的响应窗口为 24 至 72 小时发布修复或缓解方案，但这一时限必须写入合同才具有约束力。
修复责任边界需明确：若漏洞源自上游开源组件，供应商是自行修复、向上游提交补丁，还是仅升级组件版本？修复后的验证标准和测试责任由谁承担？这些细节直接决定漏洞响应是“纸面承诺”还是“实际能力”。
交付验收与持续维护阶段的关注点
软件交付并非采购流程的终点，而是安全核验的起点。
验收环节应包含对 SBOM 的实质性检查：清单是否完整覆盖所有第三方组件？是否与实际交付物一致？可要求供应商提供 SBOM 生成工具和流程说明，以验证清单的可复现性。对于关键业务系统，采购方可考虑在验收时引入独立的安全扫描，将扫描结果与供应商提供的 SBOM 对照，识别未声明组件。
持续维护阶段的核心是漏洞响应的实际表现。采购方应要求供应商提供历史漏洞披露与修复记录，而非仅看其当前安全宣传。可关注以下问题：过去一年披露的漏洞数量与修复平均耗时是多少？是否存在长期未修复的已知漏洞？重大漏洞（如 CVSS 评分 9.0 以上）的响应时间线是否清晰可查？
供应商协作机制同样需要验证：当采购方自行发现漏洞时，供应商是否有明确的接收渠道和响应流程？紧急情况下能否直接联系到安全技术负责人而非仅通过客服工单？这些协作机制的顺畅程度，往往在真实安全事件中才见分晓。
行业动态对采购实践的影响
近期供应链安全事件呈现两个显著趋势：一是针对开源生态的投毒攻击更加隐蔽，攻击者通过伪造组件名称、利用依赖混淆等手段渗透企业构建流程；二是监管层面推动 SBOM 从“最佳实践”走向“合规要求”，部分行业和地区的采购政策已开始强制要求软件交付附带组件清单。
对采购方而言，这意味着核验标准需要动态更新。单纯要求“提供 SBOM”已不足以应对风险，还需关注清单的完整性和更新机制；单纯依赖供应商自查报告也不够，独立验证能力应成为采购评估的一部分。对于安全敏感度较高的行业（如金融、能源、政务），在采购评审中引入技术侧的安全尽调，将组件透明度和漏洞响应能力作为与价格、功能并列的评分维度，是当前较为务实的应对方向。
软件供应链安全的采购核验没有一劳永逸的方案，它贯穿合同、交付和运维全流程。采购方的核心任务，是将供应商的“安全承诺”转化为“可验证的交付物”，并在合作关系存续期间持续监督其兑现程度。
