越来越多开发方在项目验收或投标阶段被客户要求提供「软件物料清单」，说明系统里用了哪些开源组件、什么版本、什么许可证。这件事过去靠口头说明就能过关，现在往往要落到文档上，甚至写进合同附件。

SBOM（Software Bill of Materials，软件物料清单）本质是一份组件账本：记录一个软件产品由哪些第三方与开源组件构成、各自版本、来源与许可证。建立它的难点不在概念，而在于项目做了几年之后，没人说得清依赖是从哪一层带进来的。

现象：客户开始索要组件清单，开发方却拿不出来

常见的场面是：客户的信息化或安全部门发来一份表格，要求填写系统使用的开源组件、版本号与许可证类型。项目组临时找人回忆，或者翻一遍构建配置文件，交上去的清单缺项、版本对不上，被退回来重填。

出现这种情况通常不是因为项目不规范，而是因为过去没有把「组件清单」当成交付物来管理。它散落在不同人的机器、不同的代码仓库、不同的环境里。尤其是 B/S 管理系统这类持续迭代多年的项目，依赖关系随需求变化层层叠加，靠人工整理很难齐全。

排查方向一：依赖来源分散在不同层次的工程里

第一件要弄清楚的事，是组件究竟从哪里进入系统。一般分为三类：一是后端与前端工程直接声明的依赖；二是构建与打包工具本身携带的依赖；三是部署环境里安装的运行时与中间件。

很多团队只整理了第一类，漏掉后两类。运维层面的组件同样属于软件供应链的一部分，交付给客户时也在其安全审查范围内。

排查时不必一步到位覆盖所有工程。建议先选一个对外交付、客户关注度高的系统做样板，跑通流程后再推广。若系统本身就是在做软件定制开发与系统集成过程中搭建的，可优先从交付物清单里找线索。

第二个常见问题是版本口径不一致。开发环境的依赖清单、测试环境实际安装的版本、生产环境正在运行的版本，三者往往不同。清单上写的是一个版本，服务器上跑的是另一个版本。

原因通常是升级时只更新了一部分环境，或者部署包被人手工替换过。SBOM 若只按代码仓库生成，就会与真实运行状态脱节。

处理办法是把「生成清单」和「部署验收」绑在一起：每次上线后，从实际运行环境反向采集一次组件信息，与仓库侧清单比对差异。流程可以写进交付规范，作为服务范围与交付流程中的固定环节。

补全版本之后，还要看许可证。客户审查关注的重点往往是两件事：组件是否来自可信的上游仓库，许可证是否与项目使用方式冲突。

实际操作中，很多依赖只记录了名称与版本，没有记录许可证文本与获取地址。这类信息需要随组件一并留存，否则客户追问时又要重新查证。建议在清单里至少保留四个字段：

需要说明的是，许可证合规的判断标准随客户与项目性质不同，具体尺度建议在立项时与客户法务或安全部门确认，不要自行拍板。

清单静态生成一次不难，难在维护。系统上线后还会打补丁、换组件、加模块，如果这些变化没同步进清单，一两年后清单就失效了。

较多项目卡在运维交接环节：开发方撤场，清单没有随之更新，后续接手方无从判断现状。常见做法是把清单作为运维交接材料的组成部分，规定每次版本变更时同步更新并留档。

存量系统较多的团队，可能还要做一轮梳理与重构，把零散的部署方式收敛到统一规范上，再谈清单维护会轻松很多。

根本的做法是转变定位：SBOM 不是应付一次检查的材料，而是随项目持续存在的技术资产。

具体可在三处着力。其一，在需求阶段就与客户确认清单的字段口径与提交频率，写进合同或技术附件，减少后期返工。其二，把组件采集步骤放进构建与部署的标准动作中，尽量自动完成，降低人工整理遗漏。其三，接手历史遗留项目时，先做一轮依赖梳理，摸清底数再承诺交付内容。

国产 OA 等平台类产品在交付时通常自带组件说明，二次开发部分产生的依赖则需自行补入清单，这部分容易被漏。

下一次客户提出组件清单要求时，可以按下表逐项自查，每项都能用「有 / 无 / 待确认」作答：

供应链透明化是一条渐进的要求，不会一次到位。先从一个系统、一份清单开始做起来，把字段补齐、把流程固定，后续推广会顺手得多。需要具体做法时，可以了解我们的软件定制开发与系统集成能力。