在设备软件里，我们经常会看到这样的组合：一部分是自己开发的代码，一部分是开源的库，还有供应商给的交付包，甚至可能还夹杂着一些提前编译好的二进制文件，这些东西统统都算作第三方组件。那么当项目跑起来以后，到底该怎么用Cybellum去追踪这些组件，又怎样才能在它们悄悄发生变更的时候及时发现，其实最关键的一点，就是要给每一个产品版本都维护好一份可以不断更新的物料清单（也就是大家常说的SBOM），然后把组件的变化跟漏洞带来的影响串在同一条线上去看，这样做才不至于遗漏掉关键信息。

　　一、Cybellum里头第三方组件怎么追踪

　　追踪第三方组件，单靠拿一张Excel表格去登记是远远不够的；随着组件数量慢慢堆上去，人工清单很容易把版本号、依赖关系和供应商来源给漏掉，等到后面突然爆出漏洞，再想快速圈定影响范围就变得特别费劲。

　　1、先给产品建立组件的基线

　　第一步，需要在产品资产这个模块里，把产品型号、软件版本、固件版本以及开发分支这些信息都区分清楚，然后再把对应的SBOM给导进去。如果供应商这边本来就已经提供了现成的SBOM，那就可以直接把它纳入到产品清单里面去；要是还没有特别完整的清单，那就要结合固件分析的结果，一点一点地补全，整个平台本身就支持对SBOM做创建、合并、修正、编辑和审批这一系列操作，很适合把不同来源的数据整理成一套统一的基线。

　　2、把组件的基本标识信息补全

　　每一条组件记录至少都要核对这些内容：组件叫什么名字、版本是什么、从哪儿来的、供应商是谁、用的什么许可证，还有它属于哪一个产品。比方说像OpenSSL这种组件，要是只在表格里写了一个名字，却没有标清楚具体的版本，那等到漏洞匹配的时候，就根本没办法判断真实的受影响程度。如果同一个组件有好几种不同的叫法，也一定要把名称给统一掉，免得明明就是同一个库，却被拆成了好几条不同的记录，最后把统计都搞乱了。

　　3、按层级去理清依赖关系

　　设备里的软件并不是一张平平坦坦的清单，主控固件、通信模块、中间件和第三方库之间，是存在一层一层的依赖关系的。Cybellum这边给出了一种可以从系统层级一直往下钻到组件层级的风险视图，顺着这个视图，我们还能继续去查看某个组件关联到的CVE编号、策略违规项，还有其它的安全问题，不用再在不同页面之间来回翻找。

　　4、把SBOM的更新绑进版本发布流程里

　　每当固件要发布、补丁要交付，或者供应商那边替换了某个软件包，都要顺手把对应版本的SBOM给更新一次；千万不要让测试版本、量产版本和售后补丁这三个环节共用一模一样的一份清单，要不然过后想确认到底是哪一批设备真正被影响到了，就变得非常难分辨。

　　二、怎么发现Cybellum里第三方组件的变更

　　发现第三方组件变更，重点是把前后两个版本放在一起比对，而不是光盯着当前手头这一份清单看；不管是新增加了组件、删除掉了组件，还是版本升级、降级，每一次变动都得留一个痕迹，特别是当供应商临时换掉了一个库文件的时候，更需要立即去复核一下。

　　1、为产品创建起新的版本节点

　　每次拿到一份新的固件或者新的软件包以后，就可以在原来那个产品的底下，给它新建一个版本或者新的分支，然后再把这一轮的SBOM传上去；平台能够照软件更新、产品版本以及分支这些维度，持续地去监测漏洞的变化情况，这样就很容易把这次带来的差异跟之前的历史版本分开来观察，不会混到一起。

　　2、对照组件的新增、删除和版本变动

　　在对比前后两个版本的时候，需要重点看四种变化：这次新加进来的组件，被移除掉的组件，版本往上升级的，还有版本往后退的。假如发现组件的总数忽然间就比原来多了不少，那还要多留一个心眼，去查一查是不是把调试工具、测试用的库或者重复的依赖，一不小心也带进了正式发出去的包里。

　　3、同步查看随之而来的漏洞影响

　　组件一旦发生了变更，光把版本号记下来是不够的；新换上去的版本有可能会修掉原先的漏洞，但也有可能反而带进新的风险。Cybellum支持对产品里的漏洞做持续监控，还能帮忙定位到具体是哪些产品受到了新漏洞的影响，这样就不用人工在那边一条漏洞一条漏洞地翻对。

　　4、检查许可证的变化

　　每次第三方库被替换掉之后，还应该去核对一下它的许可证类型，以及附加的使用限制；平台本身也提供了对开源软件许可证策略做检查和管理的功能，很适合在版本变化的时候，顺手把许可证那边的风险也同步排查一遍，防止后面因为不合规而出问题。

　　三、怎样维护好Cybellum里第三方组件的变更记录

　　维护变更记录这件事，目的不是单单留一份当前的SBOM就完了，而是要让这些记录能够在以后的研发管理、供应商管理和漏洞响应的时候都派得上用场；如果你手上只保着一份当下的SBOM，那将来别人问你历史版本里到底发生过什么，就很难解释得清楚。

　　1、把版本命名固定下来

　　产品型号、固件包的名称、SBOM文件的名字，还有扫描结果的命名，这几样东西最好用一套统一的规则来串；比如可以把产品型号、发布日期、分支名称和构建编号都揉进去，保证它们之间能互相识别，省得东西一上传就找不到对应的原始包了。

　　2、给每次变更保留说明

　　每一次替换组件的时候，都要把旧版本号、新版本号、为什么要换、供应商是哪家、影响到了哪几个模块，以及验证的结果逐项记录一遍；如果这次改动跟修补某个漏洞有关系，那还要把对应CVE的编号，以及关闭掉这个漏洞的依据一块儿写上去，往后别人接手的时候一眼就能看明白。

　　3、建立起定期复核的节奏

　　在开发阶段每出一个新版本，就要更新一次SBOM；等到产品已经批量生产出去之后，还得继续盯住有没有新冒出来的漏洞，以及供应商是不是发过来了新的通知。按照Cybellum平台强调的思路，监控这件事是从设计阶段一直延伸到量产之后的，不能只在发布前集中做那么一回，必须弄成一个持续滚动的事情。

　　总结

　　总结起来，Cybellum里面对第三方组件的追踪和变更发现，大致可以按照这么一个顺序来处理：先建起一份SBOM的基线，把组件该有的信息都补齐；接下来每当版本更新时，就去创建一个新的产品版本，再把前后组件的差异对比出来，同时把漏洞和许可证这两项一块儿核验掉。真正需要管理的，从来就不是一张死板板的静态清单，而是每一个产品版本里面连着的那些变化轨迹；只要能把SBOM、产品版本和风险记录串在一根线索上，后面再遇到供应商升级，或者听到有漏洞通报的时候，判断哪些设备受到了影响，就会轻车熟路很多。