产品在正式上线运行之后，漏洞管理这件事就不能只靠最初扫描时留下的那一份清单了，因为新的漏洞公告、组件版本更正、供应商发来的通报，还有企业内部自己发现的风险信息，会一直不停地冒出来。Cybellum的做法，是把SBOM和资产数据跟漏洞情报关联在一起，并且对软件更新、产品版本和分支中的风险做持续分析，平台不单单依赖某一个漏洞库，也支持把企业自己的内部漏洞信息纳入到评估里面去。

　　一、漏洞情报怎么同步进来

　　Cybellum的漏洞情报同步，大致可以分成三类情况：公共情报的更新、私有漏洞的导入，还有产品版本的重新分析。这三类数据的来源不一样，更新失败以后要排查的方向也不同，所以分开来看会更清楚。

　　1、先把产品版本和SBOM确认好

　　进到目标产品的页面里面，选好需要检查的Version或Branch，然后再打开漏洞管理那块区域。这个时候先看一眼这个版本是不是已经关联了一份完整的SBOM，组件名称、版本号、CPE和PURL这些标识是不是都已经填上去了，有没有缺失。Cybellum的新版漏洞引擎会结合CPE和PURL来提高匹配的准确度，要是组件的标识本身就不完整，那即便漏洞情报已经进了平台，也可能没办法落到具体的产品上面去，这是最开始就要排除的一个排查方向。

　　2、查看公共漏洞情报的情况

　　进到【Assurance&Vulnerability Management】或者【PSIRT】这类相关页面，就可以看到当前这个产品受到了哪些漏洞的影响。Cybellum会把公共情报、私有情报、EPSS评分还有研究的结论组合到一起来用，并且会对新版本、新分支和软件更新做持续的监控。不同部署版本的界面也许长得不太一样，从v3.7往后，漏洞面板里新增了【Resources】和【Sources】页签，可以拿来查看情报的来源，以及背后的证据链，方便追溯。

　　3、把内部发现的漏洞信息导进去

　　企业内部自己发现的漏洞、供应商那边还没公开的通报，或者专属的修复通知，这些都可以当成私有漏洞来导入。从Cybellum v3.1开始，就已经支持通过界面或者API的方式把私有漏洞上传进来，让它们跟公共漏洞数据库一起参与后续的评估。在导入动作做完之后，不要以为就完事了，还要再回到目标产品的版本页面，确认这些新导入的信息是不是已经匹配到对应的组件上去了。

　　二、更新失败时该从哪里查起

　　更新失败的时候，不要上来就重复上传SBOM。比较合理的做法是先判断一下，到底是情报本身没有成功进到平台里面，还是情报虽然在平台里，但没有跟当前这个产品版本匹配上，这两类问题的处理方式很不一样。

　　1、先从Sources页签查起

　　打开一条具体的漏洞记录，去看看【Sources】和【Resources】这两个页签里面的内容。要是发现好几个来源都已经有记录了，但产品页面上偏偏没有显示出风险提示，那就要优先去检查组件的版本号、CPE、PURL，还有分支绑定的情况。反过来说，如果Sources里面完全没有新数据，那就要让管理员去查一下情报同步任务的执行状态，以及外部数据源的连接是不是还正常。

　　2、检查组件版本写得到底准不准确

　　组件名称是同一个，但版本号不一样，匹配出来的结果会完全两样。比如版本号直接留空了、写的是内部的构建编号、或者前后多了一些多余的字符，这些情况都会干扰自动识别。遇到这种问题，先回到SBOM里面把组件的信息修正过来，然后再重新触发一次当前版本的风险分析，不要在漏洞页面里手工去改状态，那样治标不治本。

　　3、检查一下私有漏洞导入的那部分内容

　　不管是通过界面还是API导入内部漏洞，都要去检查一下漏洞编号、受影响的组件、版本范围、严重程度，还有状态这几个字段，看看它们是不是都填对了。如果是用API方式导的，那还要核对Token有没有过期、权限够不够、请求的格式对不对，以及服务器返回的结果有没有报错。文件上传成功不意味着里面的字段已经被正确地解析了，导入之后最好至少抽查一条记录，确认关键信息没有跑丢。

　　4、检查同步任务和网络的状态

　　平台要是已经很久都没有更新了，就要让管理员去查看后台任务的执行状态、服务的运行日志，还有网络代理和证书这些配置。企业的内网如果对外部数据源的访问做了限制，漏洞库的同步就可能一直卡在旧的某个时间点上不动。排查的时候，可以把最后更新时间、受影响的产品、漏洞编号，还有任务报出来的错误信息都记录下来，这样找人帮忙定位的时候也有依据。

　　三、情报同步之后怎么确认结果

　　情报更新完了以后，还要再确认一下风险结果是不是真的已经进到了产品的管理流程里面，不能光看着同步状态显示成功就觉得没问题了。

　　1、抽查一两条已知的漏洞

　　找一两条已经确认会影响到某个组件的漏洞，到对应的产品版本里去核对一下，看看它们到底有没有出现在列表里。同时再点开看看Sources里的情报来源、组件实际版本，还有影响范围这几处，确认平台匹配的逻辑是正常在工作的，没有因为误判而漏掉或搞错。

　　2、把分支和版本分开来核对

　　同一个产品，它的旧版本、新版本，还有开发分支，要分别点进去查看。已经修复过的版本，不应该还继续显示跟之前一模一样的受影响状态；旧版本的状态，也不能因为新版本上传了以后就被直接覆盖掉，这些情况如果不注意，可能会给后续的研判带来错误的判断。

　　3、导出VEX或CSAF结果

　　当完成一轮研判以后，可以通过VEX或者CSAF报告，把漏洞目前的影响和处理结论共享出去。Cybellum支持把漏洞的影响范围和对应的处理方式，通过报告的形式输出出来，方便拿去跟供应商沟通、交给客户查阅，也方便审计的时候留底存档。

　　总结

　　关于Cybellum漏洞情报怎么同步，以及更新失败以后该怎么排查，处理顺序可以这样来梳理：先把产品版本和SBOM确认清楚，再区分开来处理公共情报更新、私有漏洞导入和重新分析任务这三种情况。更新失败的时候，优先去查看Sources页签的内容、组件标识的完整度、版本范围有没有写对，还有API返回的结果和后台同步任务的状态。等到情报同步完了之后，再用抽查已知漏洞和分别核对不同版本分支的方式，确认一遍风险结果确实已经匹配到位，免得情报已经更新了，而产品风险却还停在老状态里。