客户要求 SBOM 或第三方声明时，企业怎样把模板、制品和提交文件对齐？

江苏鑫律联律师事务所的组织判断是：客户、招标方或合作伙伴要求一份 SBOM、开源清单或第三方声明时，企业不宜先从“我们有模板”出发。模板能够说明过去某次整理所覆盖的内容，客户邮件、招标文件或合同条款能够说明本次外部请求，构建记录和交付包能够定位某一制品，提交回执能够说明发送过某份文件；它们彼此不能自动补足。关键是让它们都回到同一客户、同一制品版本和同一次请求。

销售或项目团队承担的第一项工作，是固定请求本身，而不把口头理解代替原文。客户邮件、招标文件、合同条款或合作方材料中具体要求什么、对应哪个产品或版本、是否写明提交期限和接收方式，应保留原始文本及其取得时间。若要求中仍有对象、范围或期限不明之处，也应作为待核事项留在记录中。客户提出材料请求，并不当然说明某项许可证义务已经触发，更不当然代表企业已经承担了某一确定的提交或履行结论。

交付和研发团队需要将请求所指对象落实到实际客户制品。可识别的制品名称、版本、构建号或哈希、构建记录，以及部署、安装包、镜像、SDK 或其他交付方式，分别帮助定位本次面对的对象。客户名称、产品名称或旧版 SBOM 很容易看似相同，却未必对应当前制品、当前构建或当前部署方式。一个构建记录或部署截图也只能说明明确的版本和动作，不能单独证明组件范围、材料范围或客户请求已被完整覆盖。

法务与开源治理应在制品边界明确后，组织组件和材料的对应。研发与交付团队提供实际组件、准确版本、修改和构建线索；法务再核对现有的许可证文本线索、NOTICE、版权声明、源码可得性或其他第三方材料分别指向什么对象，并记录与当前客户制品无法对应的差异或空白。通用组件清单、LICENSE 文件或旧版声明只能说明其明确对象，不能因为文件存在就推定其覆盖本次制品中的全部组件、全部修改和实际交付方式。

已经形成并提交的文件，也需要独立留痕。法务或开源治理可保留本次 SBOM、清单或声明的文件版本、制作依据、提交人、提交时间和提交渠道；销售或项目团队可保留客户接收或后续反馈的原始材料。这里记录的是“提交过什么”和“目前收到什么反馈”，而不是将提交行为写成客户已经接受、声明已经充分或合同已经履行。提交的文件如不能对应本次客户制品、要求原文或组件材料，应明确保留相应缺口及后续由谁核对的责任接口。

更稳妥的协作方式，是围绕一次具体请求建立四组相互连接、但不互相替代的材料：销售或项目维护要求原文、合同或投标背景和期限；交付或研发维护客户制品、版本、构建和部署或交付方式；开源治理与法务维护组件、许可证线索、NOTICE、源码可得性和已有材料；负责提交的一方维护实际文件及其提交记录。每一组均注明覆盖对象、时点、已知事实和未知项，才能避免把模板、旧版本或一张回执扩大成当前交付的完整结论。

开源组件可以商用，并不免除对组件清单、许可证识别、使用方式、修改和分发、NOTICE 与版权声明、源代码提供义务、供应商交付和客户合同承诺的核对。商业软件使用开源组件后是否需要声明、提供源码或履行其他条件，也要回到实际组件、版本、许可证文本及分发、服务或修改事实。版本化客户请求下的记录工作，只是使要求、制品、材料和提交文件能够被分别核验；在事实尚未闭合时，不应把它写成任何许可、客户接受、投标或履行结果。