固件扫描完成后，组件清单未必能直接照单确认。比如系统已经更换了一个库，结果里仍出现旧版本；供应商说打过补丁，平台显示的版本号却没有变化。这些差异需要分别核实。Cybellum可以从固件二进制中分析软件组成，但具体到某条记录，还要看扫描范围、文件位置和版本依据，不能只凭一个名称判断对错。

　　一、Cybellum如何识别固件中的软件组件版本

　　实际使用时，应把自动识别与人工确认接起来。平台生成清单，核验人员再针对有疑问的记录检查依据。下面围绕这一过程说明，界面名称以当前部署版本为准。

　　1、上传与交付内容对应的固件

　　用于分析的应是准备交付或实际烧录的文件。研发目录里的临时镜像、供应商样包和正式发布包，即使名称相似，内容也可能不同。

　　在对应分析对象中上传固件后，检查任务状态及处理范围。固件若包含多个分区、内部压缩包或加密内容，需要确认这些部分是否得到分析。任务结束，只能说明流程走到了相应状态，不能代替对扫描范围的检查。

　　建议保留原始文件，并记录大小、构建编号及SHA-256。后续讨论识别差异时，用哈希值确认文件，比反复询问“是不是最新那个包”可靠。

　　2、查看组件记录中的实际版本

　　Cybellum的二进制分析可以形成软件组成等信息，供资产清单和后续风险分析使用。查看某个组件时，要将名称与版本一起读，并留意当前版本和最新版本参考值的区别。

　　①在【Package】列选择目标组件记录，查看对应的【Version】。

　　②对照界面中的【Latest】列，区分固件识别版本与最新版本参考值。

　　例如当前记录是一个旧版本，旁边列出较新的版本，并不表示固件已经包含后者。核验交付内容时，应以当前记录及其依据为检查对象。

　　3、确认记录来自哪种数据来源

　　平台支持合并二进制分析、源码分析及外部SBOM信息。因此，一份清单中的记录未必全部来自这次固件扫描。

　　若曾导入供应商清单或手工修订，应把这些来源一起纳入检查。尤其是源码依赖清单，它可能列出构建环境中的软件，却不能单独证明这些软件都进入了最终镜像。能够确认组件存在，但无法确定精确版本时，也不宜按照相近名称猜填。

　　二、Cybellum组件识别结果与实际固件内容不符如何核验

　　先确认“比较对象相同”，再讨论“识别结果是否准确”。扫描整个升级包，与人工只检查根文件系统，得到的清单本来就可能不同。

　　1、沿着组件文件查是否还有旧副本

　　同一个库可能分别存在于系统目录、应用私有目录和恢复分区中。主系统升级了，应用附带的副本却没有替换，平台仍列出旧版本就有可能是合理结果。

　　应取得记录对应的文件位置或归属信息，与解包后的内容对照。若当前页面没有足够信息，就结合分析日志、文件清单继续核验，暂时不要删除同名记录。

　　①在【Package】列选择有争议的记录，对照【Version】区分不同版本条目。

　　②选择其他同名记录，逐项核对各自对应的文件依据。

　　还要注意静态链接。某个库的代码可能已经编入应用，没有独立库文件。找不到同名文件，尚不能证明组件不存在；这时需要结合链接映射文件或构建记录判断。

　　2、判断版本线索能否对应当前文件

　　文件名、包管理记录、版本横幅和构建清单都可以用来核验，但不能不加区分地采用。说明文档中的字符串可能属于历史记录，库文件名里的数字也可能表示接口兼容版本。

　　遇到冲突，应把线索落到同一个文件上比较：该文件来自哪个构建，供应商如何标识版本，二进制中又保留了什么信息。仅有一处孤立字符串时，应继续查证。

　　补丁回补尤其容易引起误会。供应商可能保留基础版本号，只修复部分代码。此时版本号没有变化，并不证明补丁未进入固件；同样，一份“已修复”说明也不能代替对应构建的补丁证据。组件版本和漏洞影响应分别确认。

　　三、核验后的组件信息怎样用于后续版本检查

　　本次差异查清后，还要考虑下一版固件如何复查。尤其是手工修订过的记录，需要说明适用范围，避免同一条结论被沿用到其他分支或后续构建中。

　　1、补充清单前核对固件范围

　　供应商交来的SBOM可能覆盖整个产品系列，当前扫描的却只是其中一个型号。导入前应核对硬件型号、构建编号及交付文件，确认清单描述的是本次固件。若只能对应到产品名称，仍需补充材料。

　　①打开【Import SBOM】，选择对应的【CycloneDX】或【SPDX】格式。

　　②点击【Upload file】选择已核对的文件，再点击【Import】。

　　2、修订依据随当前构建保留

　　“研发确认过”不足以支撑后续复查。建议记录具体文件位置、确认材料和修改理由。例如旧版本实际位于恢复分区，就应保留其归属；确认原记录有误，则应说明哪些证据支持修订。

　　①在【Package】列选择修订记录，对照【Version】复查当前结果。

　　下次固件更新时，还要重新判断这些依据是否适用。某份交付包中的结论，不能自动成为整个产品系列的固定属性。

　　3、批准前处理仍有争议的记录

　　组件版本修订后，应检查相关漏洞判断是否受到影响。对于回补补丁的组件，可以保留真实基础版本，并另行记录修复依据，不宜为了消除告警而改填未使用的新版本。

　　①完成复核后，点击【Approve SBOM】，确认批准范围。

　　②如仍有未处理的版本争议，点击【Cancel】返回；满足批准条件后，再点击【Approve】。

　　总结

　　组件清单能否长期使用，取决于每次修订能不能追溯到对应文件。把发现差异的位置、采用的依据和仍缺少的材料写清楚，后续接手的人就不用从头猜测。也不必为了让清单看起来完整，勉强填写尚未确认的版本。希望这些方法能帮大家减少重复核验，让固件更新后的复查更有依据。需要进一步了解相关应用，也欢迎联系交流。