为什么收到清单不等于能用
假设一家企业在采购门禁管理软件时，按照安全团队的要求在合同里写了一句“供应商应提供软件物料清单”。项目上线时，供应商发来一份表格，列了几十个组件名称，没有版本号，也没有说明这份清单对应哪一个发布版本。半年后，一个常用开源组件被曝出严重漏洞，安全团队想确认门禁软件是否受影响，却发现清单无法回答这个问题，只能再发邮件询问供应商，等了一周才得到答复。清单存在，但在最需要的时候没有发挥作用。
美国国家电信和信息管理局在 2021 年发布的软件物料清单最低要素文件，把要求分为三类：数据字段、自动化支持，以及实践和流程。数据字段包括供应商名称、组件名称、组件版本、其他唯一标识、依赖关系、清单作者和时间戳；自动化支持要求使用可被机器读取的通用格式；实践和流程则涉及更新频率、覆盖深度、对“已知未知”的说明、分发方式和访问控制。美国网络安全和基础设施安全局在 2025 年发布了更新版的征求意见稿，提议增加组件哈希、许可证、生成工具和生成背景等要素，目前应把它视为草案而非定稿。
在采购条款里写清可验收的要求
JOTOglobal 建议由采购负责人和安全负责人共同把要求写进技术附件，而不是只留一句原则性条款。附件至少说明：清单采用哪种机器可读格式；每个发布版本、补丁版本都要随版本提供对应清单；清单需要覆盖到什么深度，例如至少列出直接依赖，并说明间接依赖的覆盖情况；对无法确认的部分要明确标注为未知，而不是省略；以及交付方式、更新时限和由谁接收。若软件以云服务形式提供，企业拿不到可安装的软件包，应改为要求供应商说明其组件管理和漏洞响应流程，并约定在出现公开漏洞时多长时间内答复是否受影响。
条款中还应写明企业内部的接收和保管责任。清单可能暴露供应商的技术细节，企业应限定能够查看的人员范围，并按合同约定的保密条款保存。对于关键系统，可以要求供应商同时提供与清单配套的漏洞说明，用于标注某个已知漏洞在其产品中是否可被利用，从而减少逐一排查的工作量。所有这些要求都应在投标阶段就提出，便于供应商评估能否满足，而不是在验收时才临时追加，引起合同争议。评标时可以把清单样例作为评分项之一，要求投标方提供一份同类产品的真实清单供技术团队试读。
到货后按三步验收
第一步是格式和完整性检查。由安全团队用常用的开源或商业工具打开清单，确认文件可以被解析，每个组件都有名称、版本和唯一标识，清单作者和生成时间填写齐全，并核对清单声明的产品版本与实际交付的软件版本一致。第二步是抽样核对。在授权的测试环境中安装软件，由工程人员选取几个主要组件，检查安装目录、软件包信息或运行时显示的版本，与清单记载进行比对；发现不一致时，记录差异并要求供应商解释或重新生成清单。
第三步是试用一次真实查询。安全团队选取一个近期公开的漏洞，假设需要确认产品是否受影响，用清单在资产管理或漏洞管理系统中检索，记录从开始查询到得出结论所用的时间，以及是否还需要联系供应商。如果检索结果需要大量人工判断，说明清单的标识方式或覆盖深度还不够，应在验收意见中列明并约定整改时间。三步检查的结果、发现的问题和供应商的回复，一并写入验收报告，由采购、安全和系统负责人共同签字。若供应商在约定期限内仍无法补齐关键字段，验收报告应写明对应的付款节点或保留条件如何处理，并由采购负责人跟进。
上线后的维护、误区与适用边界
上线后，系统负责人要确保每次升级都同步更新清单，并在资产管理系统中把清单与具体部署的实例关联起来。若清单只保存在共享文件夹里，出现漏洞时往往找不到对应版本。常见误区之一是把清单当作一次性交付物，签收后再也不更新；另一个误区是认为有了清单就等于软件安全，实际上清单只说明“里面有什么”，并不说明这些组件是否存在可利用的漏洞，后者仍需要漏洞情报、供应商公告和必要的测试共同判断。
本文的条款要点和验收步骤是 JOTOglobal 提出的组织建议，不构成法律意见，具体合同措辞应由企业法务结合当地法规和供应商情况确定。最低要素文件主要面向美国联邦采购场景，其他地区和行业可能有不同的强制要求。小型或定制软件的供应商可能难以一次满足全部要求，企业可以按系统重要性分级提出，并在合同中约定逐步达到的时间表。云服务、硬件固件和人工智能模型的物料说明仍在发展中，应结合供应商实际能力评估。