在进行车载软件、医疗设备软件或者工业设备固件的安全管理期间，经常需要面对“Cybellum SBOM怎么导入，Cybellum SBOM组件识别不完整怎么办”这两个让人头疼的问题，因为SBOM管理并不只是上传一个清单文件那么简单，它还牵扯到组件名称、版本、供应商、依赖关系、漏洞匹配和审批状态等一大堆零碎的内容，而Cybellum这个产品安全平台比较看重把二进制、源代码和上传的SBOM文件合在一起，用来做出更完整的资产与组件视图，所以导入前的数据准备、导入时的版本归属，还有导入后的校验工作都挺重要的。

　　一、Cybellum SBOM怎么导入

　　因为Cybellum不同的部署版本、权限配置还有每个企业的流程不一样，可能会导致菜单的名字有点差别，所以大家在操作的时候不用死记硬背某一个按钮叫什么，只要围着“产品或资产对象、SBOM文件、导入校验、合并审批”这条线来做就行，只要这几步理顺了，导入的过程一般不会出什么大错。

　　1、先选择对应产品和版本

　　进到Cybellum系统之后，先去找到自己需要维护的产品、项目或者资产对象，然后再确认好软件版本、发布版本或者是分支。

操作的时候可以先去【Products】或者【Assets】页面，看到目标产品之后，再点进跟【SBOM】、【Components】或者【Software Inventory】相关的入口，要是企业内部已经弄好了产品线、BU、供应商门户这些流程，还得确认一下自己现在的账号有没有导入和审批的权限。

　　2、上传SBOM文件并查看校验结果

　　找到导入的地方以后，点击【Import】或者【Upload SBOM】，把准备好的CycloneDX或者SPDX文件传上去。

传完之后别急着走开，要看看页面上有没有弹出来格式错误、字段丢了、组件重复、关系不对或者自动修正的建议。

　　3、完成合并、确认和审批

　　等到导入通过了，通常还需要把这份SBOM和已经有的资产、二进制分析结果、供应商组件清单合在一起。

合并的时候要多盯着新加的组件、已经有的组件、冲突的组件还有没法确认的组件，要是遇到版本不一样但是名字一样的组件，别图省事直接合并，要是名字差了一点但是purl、CPE或者hash是一样的，可以配合规则确认一下，弄完之后再进到验证或者审批流程里，让安全、研发、供应商管理这些人员一起看看，省得SBOM只是显示“上传了”，却没变成真正能用的产品安全资产。

　　二、Cybellum SBOM组件识别不完整怎么办

　　遇到组件识别不全的时候，先别急着觉得是平台出了问题，因为SBOM的识别本来就很容易受到文件质量、组件标识、依赖的深度、二进制特征还有供应商给的内容的影响，而且现在也有研究发现，一些隐藏的依赖和组件的变体会让SBOM分析出来的结果变得不一样，组件身份搞不清楚的话，后面去对漏洞和处理VEX也会受影响。

　　1、先检查SBOM文件本身是否缺字段

　　最常见的事就是文件里确实写了这个组件，但是给的字段太少了，比如光写了component name却没写version，或者光有包名但没有purl。

碰到这种情况可以把平台的识别结果导出来，跟原始的SBOM做个对照表，看看漏掉的组件是不是都集中在某一种语言包、某个供应商的SDK、某个中间件目录或者某个静态库里，要是集中出现的话，就得回到生成工具或者供应商给的文件里去补数据，光在平台里一条一条硬改是改不完的。

　　2、检查组件名称和版本是否存在歧义

　　有很多组件之所以识别不全，其实是因为名字写得不统一。

尽量用purl、CPE、hash这些标识来帮着确认，要是遇到企业自己写的包、商业闭源组件、或者是供应商裁剪过的组件，可以在Cybellum里面用自定义组件或者自定义包的方式来管，把供应商、版本、用途、来源和责任人都补上，这样后面再导入差不多一样的SBOM时，识别起来就会稳当得多。

　　3、补充二进制、源码和供应商侧信息

　　Cybellum是把二进制、源码和上传的SBOM文件合在一起看，并不是只指望某一个来源。遇到实在认不出来的组件，可以手动把原始的文件路径、hash、编译信息、供应商声明和许可证文件补进去，然后再重新导入或者修正一下。

三、Cybellum SBOM导入前要先整理哪些内容

在SBOM导入之前，大家最好不要拿到文件就直接上传，因为很多后面遇到的识别不完整的问题，其实在文件刚生成的时候就已经留下了隐患，比如组件没有写版本号、供应商名称写得不统一、依赖关系没导出来，或者是在同一个产品版本里面混进了好多个构建批次的东西。

1、确认SBOM文件格式和版本

在导入之前，要先看看这个SBOM文件是不是属于CycloneDX或者SPDX这些常用的格式，还要检查一下文件到底是JSON、XML还是平台现在能支持的其他形式。如果是从供应商那里拿到的文件，建议让对方把生成工具、生成时间、产品版本、构建分支和覆盖范围都说清楚，要是只给一个孤零零的文件名，根本没办法看出来这份SBOM到底是设计阶段的清单、构建阶段的清单，还是某个发布包的最终清单，后面要是发现组件数量对不上，想去追溯原因也很困难。

2、补齐组件识别字段

对于SBOM里面的内容，至少要多注意组件名称、组件版本、供应商、唯一标识、依赖关系、SBOM作者和时间戳这些基础的字段，因为在NTIA对SBOM最小元素的定义里，也把这些当成了最基本的内容，在实际处理的时候，还可以顺便检查一下purl、CPE、hash、license、download location这些字段。

3、区分供应商SBOM、源码扫描和二进制分析结果

把文件放进Cybellum之前，建议先把它的来源理清楚，得搞明白哪一份是供应商给的SBOM，哪一份是源码依赖扫描出来的，哪一份又是固件或者二进制分析出来的，因为Cybellum的SBOM管理能力本来就挺强调把不同来源的东西合并，然后再进行修正、验证和审批。比较稳妥的办法是按照产品、版本、供应商、构建批次来定一个文件命名规则，这样导入以后要是看到少了什么组件，就能很快看出来到底是供应商的SBOM没给全，还是二进制分析的时候没覆盖到。

　　总结

　　Cybellum SBOM导入这件事，核心不在于“上传文件”这一个动作，而是要先费心把产品版本、SBOM格式、组件字段还有来源关系理理顺，然后再用平台去完成上传流程，要是碰到组件识别不全，也别光盯着页面上的数量差了多少，还是得回到SBOM原始的字段、组件标识、源码依赖、二进制内容和供应商给的文件里去一项一项查，只要把文件质量跟多来源合并这两件事做好了，“Cybellum SBOM怎么导入，Cybellum SBOM组件识别不完整怎么办”这两个问题，就能从每次都要折腾一次的麻烦事，变成可以一直维护下去的产品安全管理流程了。