客户拿到一份 SBOM 后问：这份清单对应哪个固件？当时用了什么配置？下次重建还能复核吗？组件清单需要和具体交付物关联。
先固定这一份固件
记录固件文件名、版本、目标板及 SHA-256。源码侧记录仓库提交、子模块提交和 SDK 版本；存在本地补丁时，保留补丁标识。避免只写 main 或 latest。
让配置跟着清单走
保存工具链版本、构建命令、配置文件和关键开关。同一套源码在不同芯片、功能开关及链接选项下，可能产生不同的组件范围。SBOM 应注明对应目标与配置。
保留证据，分别解释其含义
源码目录帮助发现候选组件；compile_commands.json 帮助核对参与编译的文件与参数；链接 map 提供目标文件、静态库或段的链接线索。源码中存在网络库，不自动证明它进入本次固件。某个目标文件出现在 map 中，也不代表整库功能都被保留；裁剪与 LTO 等情况需要结合工具链检查。
给不确定项留下说明
上游来源、版本和本地修改尽量附上证据。版本无法确认时，记录候选范围、相关文件及待核查原因。人工修订保留理由，方便之后复核。
整理一份轻量交付索引
可按四类材料归档：固件及校验值；SBOM 导出文件；构建配置、命令及工具链版本；编译数据库、map 与审阅记录。再附一份 review.md，写清材料之间的对应关系、已确认项和待核查项。
这是一套建议的归档约定，可按项目条件逐步采用。构建证据可能含内部路径，应按交付范围整理可分享版本，同时内部保留完整材料。
用 Gangmu 开始整理
我发起的开源项目 Gangmu 面向嵌入式 C/C++ 组件识别与 SBOM 整理，可结合编译数据库和链接 map 审阅组件证据，并导出 CycloneDX 或 SPDX。具体参数以仓库当前文档为准。
欢迎分享 SDK 交付、组件溯源或构建证据整理中的问题。可在 GitHub 提交 issue，或联系 64031875@qq.com。反馈时请去除密钥、客户信息及不便公开的源码。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_54342123/article/details/169651705
