当拿到固件包、镜像文件或者供应商交付的成品之后，光靠看文件名，其实是很难搞清楚里面到底用到了哪些组件的，也不太容易快速判断，那些已经公开的漏洞里面，到底有哪些是真正会影响到当前产品的。要说清楚Cybellum的二进制扫描是怎么做的，以及扫描出来的结果又要怎么去核对，整个操作的重点，就是先把产品、组件和版本之间的关系给理清楚，然后再把这一次发布真正用到的那份制品给传上去。Cybellum会从固件这类二进制文件里面，把SBOM、版本的信息、许可证、硬件的架构，还有操作系统的配置这些数据给提取出来，然后再用它们去做后面的风险识别。

　　一、Cybellum二进制扫描怎么做

　　在做二进制扫描的时候，不能只是传一个压缩包上去就丢在那里不管了。在正式开始扫描以前，应当先确认好这次制品的来源、产品的版本，还有交付的批次到底是哪一批，免得把旧固件和新版本的结果给弄混在一起。

　　1、先把产品和组件的层级给建好

　　可以按照实际的物理结构，把产品、控制器、模块，还有固件的版本，一层一层地整理出来。比如说整车、ECU、域控制器、通信模块这些，就可以分开来分层去维护。Cybellum的Cyber Digital Twin功能，既能够针对单独的一个组件，也能够针对一整个完整的产品系统去执行分析。

　　2、把真正要发布的那份制品给传上去

　　在对应的那个产品或者组件版本的下面，把固件包、镜像文件、可执行文件，或者是供应商交付过来的那些文件给上传上去。如果是要做正式的检查，那最好就用准备真正发布出去的那一个版本，别把开发过程中产生的那些中间产物拿来顶替，因为编译、链接、打包，还有部署时候的配置，都会影响到二进制里的内容。Cybellum也强调过，依靠二进制分析，是可以把那些源码扫描不容易覆盖到的打包组件和部署配置问题给认出来的。

　　3、等着平台把分析的结果给算出来

　　等分析跑完之后，先去看一看资产的清单，还有生成出来的SBOM。平台识别出来的东西会包括软件的组件、版本、许可证、硬件架构、操作系统的配置这些内容，同时它还可以结合API、加密的信息，还有产品身上其他的那些属性，去做更进一步的分析。

　　4、按版本把扫描的记录给留好

　　固件每一次升完级以后，都要另外新建一条版本的记录，别把旧的结果给覆盖掉。这样做的好处就是，后面万一又爆出来什么新的漏洞，就能很快地判断出来，到底哪些还在生产的版本、哪些历史的版本，还有哪些供应商的组件，是会受到影响的。

　　二、Cybellum二进制扫描结果怎么核对

　　等到扫描的结果出来以后，不要直接就把漏洞的数量当成是最后的结论。真正要仔细去核对的东西，其实是这次上传的制品完不完整、对组件的识别合不合理，还有找出来的漏洞，它跟当前这个产品的实际上下文到底有没有关系。

　　1、先去核对一下制品本身的信息

　　去检查一下上传的那个文件的名字、版本号、生成的时间、文件的大小，还有内部的目录结构。如果同一个组件的扫描结果，突然之间少掉了很多依赖项，那就先要去看一看，是不是这一回不小心把精简包、增量包，或者是一个弄错了的版本给传上去了。

　　2、接着去检查SBOM里面的组件和版本

　　重点去看操作系统、开源的那些库、第三方提供的库、自己团队开发的模块，还有那些传递进来的依赖项。Cybellum这个平台是支持把从二进制里拿到的、从源码里拿到的，还有从外部的SBOM文件里拿到的这些资产信息给合并起来的，这个方法很适合用来补齐那种光靠单一来源很容易漏掉的组件。

　　3、核对一下漏洞所处的上下文

　　在发现CVE之后，不能光去看它的严重级别，还要去看那个受影响的组件是不是真的存在在这个产品里，版本号是不是真的命中了，接口到底有没有暴露出去，相关的配置有没有被打开，还有在产品当中，究竟存不存在一条可以被利用的攻击路径。SBOM只能说明组件之间的关系，它背后实际的风险，还是得结合具体的上下文继续往下判断才行。

　　4、顺带查看一下许可证和配置方面的风险

　　二进制扫描这个东西，它的用处并不只是拿来挖漏洞的。那些开源许可证、加密相关的组件、操作系统的配置，还有接口的暴露情况，这些也应该一起拿来核对，尤其是在面对供应商交过来的东西时，源码不一定给得全，这个时候，用二进制的结果来作为交付复核的依据就会更合适一些。

　　三、Cybellum二进制扫描结果为什么会出现偏差

　　当扫描出来的结果跟一开始预想的对不上的时候，先别急着用人工去一条一条地删那些告警。造成这些偏差的原因，很多都是因为制品不全、版本号不对，或者上下文的信息给得不够完整。

　　1、上传的那个文件本身不够全

　　要是只传了一个主程序上去，却没有把文件系统、动态库，或者配置文件一起带着，那么识别出来的结果自然就会有缺失。在条件允许的情况下，还是应当尽量去用完整的发布包。

　　2、组件版本的识别信息不够多

　　有一部分二进制文件，在裁剪的时候把版本字符串给拿掉了，或者是供应商动手改过组件的内容，但是没有去更新它的版本号，碰到这种情况，就需要去结合供应商给的SBOM、构建的历史记录，还有人工的说明来做复核。

　　3、同一个组件在固件里还留着不止一份副本

　　固件的内部有可能同时还保留着旧版的库和新版的库，扫描工具确实能把两个版本都给识别出来，可到底真正跑起来的是哪一个，那还要去结合加载的路径，还有产品上的实际配置来判断。

　　4、风险的状态没有跟着持续去更新

　　一条漏洞到底现在还适不适用于当前的产品，是被团队明确接受掉了，还是已经通过别的手段缓解了，这些全部都要把审计的记录给留下来。Cybellum平台是支持把漏洞状态的变化，还有用户做过的处置决策都给保留下来的，这样后面再想往回追查的时候，就会方便很多。

　　总结

　　Cybellum的二进制扫描到底是怎么去做的，以及扫出来的结果又要怎么去核对，实际上的操作顺序，就是先把产品和版本之间的关系给建好，再去上传真正拿来发布的那份制品，然后接着去检查SBOM、依赖项、许可证、操作系统的配置，还有漏洞所处的上下文。一旦碰到结果有异常，优先应该去核对上传的包、版本的信息、重复了的组件，还有审计的状态。只要把这些基础的信息都给梳理清楚了，二进制扫描的结果，才比较适合拿去做供应链的复核、版本的评审，还有后面持续的漏洞跟踪。