对产品的固件进行完一次安全扫描之后，在页面上列出来的那些漏洞，是不能直接拿过来当作长期基线的，因为接下来软件的升级、供应商组件的更新，还有外部威胁情报的变化，都会让风险的数量不停地发生变动。利用Cybellum这个产品安全平台，我们可以去创建、合并和校验SBOM，并且结合产品的版本、软件组件以及风险信息，去持续地监控漏洞，而Cyber Digital Twin还能从固件的二进制文件里面，把SBOM、版本历史、操作系统配置等信息都给提取出来，这就给后续做比对工作提供了基础。

　　一、怎样建立Cybellum漏洞基线

　　一条漏洞基线，必须对应着一个清清楚楚的产品版本，不要把多个开发分支、多个固件包，还有不同供应商给的东西，都塞进同一条记录里面去。基线的作用，其实就是把某一个时间点上的资产范围、组件版本、漏洞状态，还有处置结论，都给它固定下来。

　　1、首先把基线的对象确定好

　　我们可以先照着产品型号、硬件版本、固件版本、发布分支，还有供应商组件，建立起一层一层的结构；对于开发分支、量产版本，以及售后维护版本，需要分开来管理才行。Cybellum本身是支持按照不同的产品版本和分支，去管理SBOM的流程的，同样它也能持续去分析新软件的更新，以及量产以后设备上的版本。

　　2、导入固件和SBOM数据

　　把当前这个待确认版本的固件二进制文件、供应商提供的SBOM，还有内部的组件清单，都导进平台里面去。假如同一个产品的数据，是从好几个地方过来的，那就先把它们合并好、修正完，并且做一次校验，然后再去看漏洞的数量是多少。当SBOM里面缺少了组件的版本或者供应商的信息时，后面匹配出来的漏洞结论，就会很容易失真。

　　3、完成漏洞的初次筛选

　　平台把漏洞识别出来以后，可以先依照影响的产品、组件版本、风险的级别，还有当前适用的状态，去把它们梳理整齐。Cybellum的漏洞管理能力，是会结合着产品的上下文来做风险分析的，而且也可以把风险状态，输出成自定义的报告，或者是VEX、CSAF这一类的报告文件。

　　4、冻结第一个有效的快照

　　等到确认好了资产范围、组件的版本以及风险的结论之后，就把当前这个版本，存成一份基线的快照。在这份基线记录里面，至少要把产品版本、固件文件、SBOM的版本、扫描的时间、漏洞的总数、高风险的数量、对适用性的判断，还有具体的责任人这些，都给保留下来。

　　二、基线变化要怎么去跟踪

　　基线建好之后，平常要关心的，并不单单是漏洞的总数而已，真正需要去解释清楚的，是到底新冒出来了哪些漏洞、有哪些风险已经被关掉了、有哪些组件发生了变动，还有就是这些变动，到底是来源于代码本身的更新，还是因为外部的威胁情报起了变化。

　　1、按照版本去做差异比较

　　每次发布一版新固件，或者收到供应商发来的新包，都应该去创建一条新的版本记录，然后再拿它跟前面那条还在生效的基线，比一比两者之间的差异。比较的时候，重点就去看看新增了哪些组件、删掉了哪些组件、哪些组件的版本变了，还有哪些漏洞是新加的，哪些是已经消失了的。可不要直接就把旧的版本给覆盖掉，不然往后就说不清楚，风险到底是怎么一步一步变过来的。

　　2、把新增漏洞区分成两类

　　新增的漏洞，大致可以分成两种：一种是因为产品本身更新而产生的，比如说引进了新的开源库或者新的供应商组件；另一种，则是因为外部的威胁情报发生了变化，好比某个旧的组件刚刚被公开了一个新的CVE。Cybellum具备持续监控新软件更新、产品版本还有不同分支里漏洞变化的能力，这在产品量产以后用来做风险跟踪，也同样能够用得上。

　　3、优先去盯住高风险的波动

　　漏洞总数如果只是小小地变动了一点，倒不一定非要马上启动升级流程。可要是高风险的漏洞忽然之间变多了，那就要先去看一看，是不是又新加了什么组件，有没有哪个关键组件的版本倒退回去了，或者是碰上了新公开出来的漏洞。反过来，如果数量突然掉下去一大截，那也得去查一查SBOM是不是少了东西，不能光把数字的下降，就当成了风险已经解决掉。

　　4、把处理状态的变化保留下来

　　每一条风险，都要把它是适用、待确认、不适用、缓解中，还是已关闭这样的状态给记录下来，并且把做出这些判断的依据，也一并留好。平台着重的一点，就是要把从漏洞发现出来、进行分析，一直到缓解，整条链路都保持得完完整整、可以追溯；这一类记录，等到后面需要用到法规材料，或者做事件响应的时候，还用得上。

　　三、基线异常时怎么去排查

　　当趋势图，或者是风险清单，出现了不太正常的波动时，通常应该先去查一查数据的边界对不对，然后再去看漏洞本身的问题。好多看起来好像是突然冒出来的风险，真要去细究，往往是因为版本的关联给搞错了，又或者是SBOM更新得不完整。

　　1、确认固件是不是传错了版本

　　这一步可以把文件名、哈希值、分支、发布时间，还有供应商那边的交付记录都核对一下，免得把测试用的包，错当成了量产的包。

　　2、检查SBOM是否完整

　　要是某一次扫描的结果里，一下子少了一大堆组件，那就要先去看看SBOM那边的导入、合并，还有校验工作是不是都做完了。Cybellum是支持跨产品、跨团队地去管理SBOM的创建、修正和审批流程的，所以在对基线进行复核的时候，得确认这些步骤确实没有被中途打断。

　　3、留意组件映射有没有变化

　　对于同一个组件，要是它的名称、版本的格式，又或者是供应商那一栏的内容发生了变化，那它就很可能会被识别成一个新增的组件。到了这个时候，应当回到资产清单里面，重新去核对一遍，先别着急，把冒出来的所有漏洞都当成是新冒出来的问题。

　　4、把复核的节奏固定下来

　　比较推荐的做法是，在版本发布的时候、供应商交付的时候、有重大CVE被披露的时候，还有在做定期的安全评审时，都去把基线更新一遍。每一次更新的时候，都把差异的摘要，还有处置的结论都给保留下来，这样往后回头追溯的时候，就会清楚很多。

　　总结

　　总的来讲，要建立Cybellum里面的漏洞基线，关键就是要把产品的版本、固件文件、SBOM覆盖的范围，还有漏洞的状态，都给它固定下来，再存成一份可以往回追溯的快照。而对于基线变化要怎么去跟踪，重点就是去比较不同版本之间的差异，把产品自身更新带来的变化，跟外部情报变动带来的变化，给区分开来，并且持续地把风险处理的状态记录下来。一条合格的基线，不应该只是一张写满漏洞数量的表格，它要能够说清楚，某一個特定的产品版本，当前都包含了哪些组件、受到了哪些风险的影响，以及有哪些问题是已经被处理掉的。