网硕互联帮助中心嵌入式项目中的 SDK 目录，往往比实际固件包含更多代码。关闭的功能、例程、备用库和多份组件副本，都会影响第三方组件盘点。
我是 Gangmu 的发起人。这篇文章整理一套审阅思路：把组件身份与构建范围分别记录，让 SBOM 中的结论可以回到证据中核对。
1. 先定义清单对应的构建
至少记录工程提交、工具链版本、目标板和构建配置。相同源码换一份配置，启用的组件可能不同；如果清单没有对应构建，后续很难判断它描述的是哪份固件。
2. 区分三类证据
| 证据 | 能帮助回答的问题 | 需要注意 |
| 源码与识别规则 | 目录里可能有哪些第三方组件？ | 源码存在不代表已交付 |
| compile_commands.json | 哪些源文件参与了编译？ | 编译数据库必须对应本次构建 |
| linker map | 哪些对象具有链接证据？ | 需要考虑工具链格式、重名对象和裁剪 |
三类证据应相互补充。缺少某个输入时，保留范围说明，避免把不确定结论变成确定的组件列表。
3. 组件名和版本号分开审阅
厂商可能复制上游库、修改目录名、删除版本声明，再回移补丁。识别出组件身份，并不自动意味着精确版本已经确认。应核对版本依据、厂商差异和源码声明，保留尚未解决的冲突。
4. 用 Gangmu 辅助整理
Gangmu 使用社区维护的规则识别嵌入式 C/C++ 组件，可结合编译数据库和链接 map 补充构建证据，并导出 CycloneDX/SPDX。
仓库提供了修改 GmSSL 的受控示例，读者可以查看改名、版本信息移除和源码修改的具体处理。复核时应固定仓库版本，并保留原始输入和输出；单个受控示例不能代表任意 SDK 的识别准确率。
5. 导出之后审阅什么？
- 清单是否对应正确的工程版本和构建配置？
- 相同组件的多个副本是否被区分？
- 版本结论是否有依据，厂商修改是否被保留？
- 未识别目录是否被明确记录？
- 许可证信息是否结合源码声明与许可证文件核对？
- 清单中组件的构建范围是否有足够证据？
生成 SBOM 是盘点和后续安全工作的输入，不能替代完整的产品合规判断。
一起补充公开样例
目前希望收集组件改名、多份拷贝、厂商回移补丁和链接裁剪等可公开复现的情况。欢迎在项目 issue 中提供公开工程、工具链、构建配置和预期结果。
工具采用 Apache-2.0，独立规则库采用 CDLA-Permissive-2.0。联系邮箱：64031875@qq.com。
评论前必须登录！
注册