给固件生成过一次 SBOM，后续版本是否可以沿用？如果只修改了功能配置，这个问题尤其容易被忽略。
同一份 SDK 可以构建出多个产品型号。网络协议、加密实现、文件系统和示例功能的启用状态不同，实际构建范围就可能不同。这篇文章整理的是一套比较方法，不包含对某块开发板新增的实验结果。
把“源码变化”和“构建变化”分别记录
比较两个固件时，先固定工程提交、依赖来源和工具链版本，再记录两份配置的差异。如果同时升级 SDK、切换编译器并修改功能，清单的变化就很难归因。
为每个配置保留独立证据
- 工程提交和目标板信息。
- 配置文件及生成配置的步骤。
- 本次构建的 compile_commands.json。
- 本次构建的链接器 map 和产物摘要。
- 识别工具、规则版本以及对应的 SBOM。
不要把配置 A 的编译数据库与配置 B 的 map 混合使用。文件名相同，也不代表来自同一次构建。
清单变化应该怎样审阅？
对新增或消失的组件，分别检查源码是否变化、是否参与编译、是否具有链接证据。一个配置关闭的库仍可能保留在 SDK 源码中；编译过的对象也可能在链接时被裁剪。
如果库仍然存在但版本变化，应核对上游版本依据和厂商补丁。组件名称相同，并不足以证明它是同一个实现。没有识别结果的目录也值得记录下来，以免把识别遗漏误当作组件消失。
Gangmu 在这个流程中的位置
我是 Gangmu 的发起人。这个开源工具使用社区规则识别嵌入式 C/C++ 组件，可结合编译数据库与链接 map 补充构建证据，导出 CycloneDX/SPDX。可以对两个配置分别生成结果，再按上述问题审阅差异。
项目源码和使用文档
输入缺失、工具链格式差异、重名对象和厂商修改都可能影响判断，因此应保留不确定项，避免只比较组件数量。生成清单也不能替代完整的产品合规工作。
欢迎提供公开工程样例
希望收集同一 SDK、多种构建配置的公开工程，讨论哪些组件变化能够被证据解释，哪些还需要补充规则或工具链适配。反馈时请附工程版本、配置差异、工具链和预期结果。
提交公开样例和问题。联系：64031875@qq.com。工具 Apache-2.0，独立规则库 CDLA-Permissive-2.0。同一 SDK 的不同功能配置可能改变固件组件范围。本文整理配置对比时应保留的构建证据，以及怎样审阅组件新增、消失和版本差异。
