做Cybellum固件分析时，很多团队前面能把扫描和识别跑起来，后面却容易卡在两件事上，一是结果怎么导出来给研发、供应商、客户或审计人员看，二是导出来以后怎么按版本、分支、产品线长期留存。Cybellum官方公开资料已经把主线说得比较清楚：平台会从固件二进制中自动提取SBOM、版本历史、硬件架构、OS配置等信息，支持自定义报告和VEX、CSAF报告，也支持SBOM与VEX的CycloneDX、SPDX导入导出；同时还能按版本、分支和里程碑跟踪安全状态，并为历史审计保留监管证据。公开页面没有展开到每一个按钮级路径，但导出和归档的工作方式已经足够明确。

很多团队用Cybellum做漏洞管理时，真正难的往往不是把漏洞找出来，而是把状态流转做成可追溯、可复核、可交付。Cybellum官方现在把这条线说得很清楚，平台不只是做发现和分级，还支持revision management、scenario exploration、mitigation recommendations、持续监控，以及通过custom reports或VEX/CSAF报告共享漏洞状态；官方也直接把目标写成从detection走到management和mitigation，并且全程保留traceability。

做ISO/SAE 21434时，最容易出问题的往往不是有没有做TARA，而是工件之间能不能一路追溯到版本、风险与验证证据。审计或型式批准需要看到的不是一堆文件，而是一条能闭环的证据链，即从需求与风险出发，能追到设计实现、验证确认，再回到量产后的监测与响应，并且每一步都能指向对应的工件与版本。Cybellum强调把SBOM与资产、漏洞与风险、威胁模型与安全测试、合规证据放到同一平台集中管理并自动化生成证据，这正是用来修复追溯链路断点的方向。

很多团队第一次在Cybellum里导出VEX，会遇到一个直观问题：报表里只有一部分漏洞有结论，或者字段缺失导致下游系统无法解析。VEX本质上要把“某个漏洞在某个产品版本里到底有没有影响”讲清楚，而且要能被机器稳定消费，一旦SBOM关联、漏洞标识、产品版本命名、状态语义这几件事没对齐，最终就会表现为生成不完整或导出后不可用。