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

　　一、Cybellum固件报告怎么导出

　　这一段最关键的，不是先想着导什么格式，而是先把“这份报告是给谁看”的口径定住。因为Cybellum对外输出并不只有一种报告，它既能分享漏洞状态和缓解建议，也能生成VEX、CSAF这类面向供应链或客户沟通的报告，还支持SBOM与VEX的标准格式导入导出。你要是先把对象分清，后面选报告类型就不会乱。

　　1、先按固件对象把导出范围定住

　　Cybellum的底层对象不是一张静态表，而是从固件二进制里提取出来的Cyber Digital Twin，里面会带出SBOM、版本历史、硬件架构、OS配置等信息。所以在导出前，先把你要导的是单个固件版本、某个分支版本，还是某条产品线的结果定住，不要把不同版本混在一份报告里。这样后面研发回看和供应商对账才不会错位。

　　2、内部协同优先导自定义报告

　　如果这份材料主要给内部研发、PSIRT、供应链安全或管理层看，优先走Cybellum官方提到的custom reports这条线会更稳。因为这一类报告更适合把漏洞状态、风险分析和缓解建议一起带出去，适合做周报、评审材料和整改跟踪。相比只丢一份原始清单，自定义报告更接近团队真正会拿来开会和派单的内容。

　　3、对外沟通优先导VEX或CSAF

　　如果报告是发给客户、供应商、监管或合作伙伴看，重点通常不只是“有哪些CVE”，而是“哪些受影响、哪些不受影响、哪些已缓解”。Cybellum官方明确写到，它支持VEX、CSAF报告，并且自动化VEX生成功能就是为了让制造商更容易共享漏洞可利用性和处置状态。对外口径需要更标准化时，这一类导出比普通截图或表格更合适。

　　4、涉及成分清单时优先导SBOM标准格式

　　如果你这次导出的重点是固件组成、开源依赖、第三方组件或合规提交材料，就不要只导漏洞视图，而要把SBOM一起导出来。Cybellum官方资料明确提到它支持CycloneDX和SPDX这两类SBOM与VEX格式的导入导出，这类格式更适合跨系统流转，也更适合后面做客户交付、法务留档和外部工具复核。

　　5、导出前把版本标识和时间点写进报告口径

　　Cybellum会持续监控版本、分支和更新，所以同一款产品在不同日期导出的结果可能并不一样。比较稳的做法，是每次导出都固定带上产品名、固件版本号、分支名、导出日期和所对应的分析节点。这样后面就算同一CVE状态变化了，也能清楚区分这是“报告不同”还是“风险真的变化了”。这个做法是治理建议，但它和Cybellum官方强调按版本、分支持续管理的方式是一致的。

　　二、Cybellum固件结果如何归档

　　归档这件事，真正容易出问题的，不是有没有存文件，而是有没有把“报告、对象、时间点、证据”绑定在一起。Cybellum官方在合规模块里明确提到，要把所有相关监管数据保存在集中位置，保留历史和审计用记录，并且可以一键生成regulator-ready reports。换句话说，归档不是顺手把PDF存到网盘，而是要让每一份固件结果都能回到具体产品对象、具体版本和具体证据链上。

　　1、按产品线、版本、分支三级归档

　　Cybellum官方一再强调它支持across product lines、versions、branches的管理，所以归档目录也最好照这个维度来建。第一层放产品线，第二层放版本或分支，第三层再放具体导出物，比如自定义报告、VEX、CSAF、SBOM和问题清单。这样做的好处是，后面不管是查某个版本发版前状态，还是比较两个分支之间的差异，都能很快回到正确位置。

　　2、把原始对象和对外报告分开存

　　Cybellum的Cyber Digital Twin本身是固件分析的基础对象，而自定义报告、SBOM、VEX、CSAF更像是从对象上导出的沟通材料。归档时不要把它们混成一层，否则后面很容易只剩一堆文件，不知道对应哪一次分析。更稳的做法是先按固件对象归档，再在对象下面分内部报告、对外报告和合规材料。

　　3、把审计证据和漏洞状态一起留

　　Cybellum官方在合规页面里讲得很直接，平台适合把regulatory data和evidence集中保存，并用于历史和审计目的。所以真正归档时，不要只保留最终导出的PDF，也要把对应时间点的SBOM、漏洞状态、VEX状态、责任人结论和提交记录一并归进去。这样客户追问“当时为什么判定不受影响”时，才能拿得出成套证据。

　　4、把里程碑和归档节点绑在一起

　　Cybellum v3.7已经引入了Project Milestones，允许设置到期日、KPI、查看各版本完成情况，并在到期后锁定里程碑状态。对归档来说，这个能力非常适合拿来做“预发布前归档”“送审前归档”“客户交付前归档”这类固定节点。只要节点固定，归档就不会变成有人记得做、有人忘了做的手工活。

　　5、历史归档优先保留标准格式副本

　　长期留存时，最好不要只保留平台截图或临时导出的办公文件。Cybellum官方已经明确支持CycloneDX、SPDX、VEX、CSAF这类标准格式，对长期归档来说，标准格式的好处是后面更容易复核、复用和迁移。哪怕几年后换了流程或换了系统，这类标准化副本也更容易重新解释。

　　三、Cybellum导出与归档口径怎么收

　　前两段解决的是导什么和怎么存，真正要把事情做稳，还得把口径收住。Cybellum官方材料已经给了三个很实用的方向，一是报告不只看漏洞，还要看上下文状态，二是对象要按版本和分支管理，三是合规和审计证据最好集中管理。把这三件事定下来，后面你们的导出与归档就不会一会儿按人、一会儿按项目、一会儿又按文件名乱切。

　　1、固定三类导出包

　　比较稳的做法，是把导出结果固定成三类。第一类是内部治理包，包含自定义报告和整改视图；第二类是供应链沟通包，包含VEX或CSAF；第三类是成分留档包，包含SBOM标准格式文件。这样一来，每次固件分析结束后，团队都知道该导哪几份，不会临时再拼。这个分法是基于Cybellum官方支持的几种输出能力整理出来的。

　　2、固定一套文件命名规则

　　文件名里至少建议带上产品名、固件版本、分支、导出日期和报告类型。因为Cybellum的管理维度本来就覆盖产品线、版本、分支和里程碑，所以文件命名也最好顺着这套维度走。这样做不是平台强制要求，但它最符合Cybellum官方公开出来的对象管理方式。

　　3、固定一次分析对应一套证据包

　　不要今天导一份报告，明天又补一份SBOM，后天再单独补VEX，却不把它们绑到同一个分析时间点。更稳的做法，是每次分析完成后，把报告、SBOM、VEX、CSAF和结论记录打成同一套证据包。Cybellum官方强调持续监控和状态变化，这恰恰说明每个时间点都应该有一套完整快照，而不是零散文件。

　　4、固定谁能改谁能发

　　Cybellum平台强调跨团队、跨业务单元协同，但对外共享的报告如果没有口径控制，很容易一个团队发自定义报告，一个团队发原始表，一个团队又发未审阅的VEX。更稳的做法，是把内部导出、对外发布、历史归档三种动作分开授权，尤其是供应链和客户材料，最好固定由同一角色发出。这个建议属于治理层做法，但和Cybellum官方强调集中化平台管理是一致的。

　　总结

　　Cybellum固件报告怎么导出，关键不是先找某个按钮，而是先把导出对象和用途定住，再分别走自定义报告、VEX、CSAF或SBOM标准格式这几条线。Cybellum固件结果如何归档，核心也不是简单存文件，而是按产品线、版本、分支和里程碑把固件对象、对外报告和审计证据绑在一起长期留存。把这套口径固定下来以后，你们后面不管是做研发整改、客户答复，还是法规审计，都会顺很多。