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

　　一、Cybellum VEX报告生成不完整是什么原因

　　1、SBOM与产品版本没有稳定对齐导致产品范围被截断

　　在Cybellum进入【SBOM】找到目标资产，打开组件清单后重点看组件是否缺少供应商名、版本号或唯一标识，如果同一组件在不同镜像或固件里被归并成一条但版本为空，VEX在生成product_id时很容易无法按版本落到“受影响的那一段”，最终就会看起来只出了一半。VEX对product_id与subcomponent_id的基本要求是可识别且能关联到SBOM标识，建议把命名统一到供应商加产品加版本的结构后再导出。

　　2、漏洞标识不规范或缺少描述导致声明被跳过

　　在【Vulnerabilities】或【Findings】视图里抽查几条“缺失VEX结论”的记录，确认每条漏洞是否有明确的vul_id，优先使用CVE或组织内部统一编号，同时要能提供对应描述或可访问的引用地址；当漏洞只剩一个内部临时标题、且没有可追溯的标识或描述时，很多VEX管道会把它当作不可发布条目处理，从而让报表出现空洞。

　　3、处置流程未闭环，状态仍停在待研判

　　如果团队在Cybellum里只做了扫描导入，但没有在漏洞处置界面完成“影响判定”，那么VEX层面就只能落到Under Investigation这一类状态，甚至被默认过滤掉。实操上可以在漏洞列表里按状态筛选，先把目标产品线里高优先级漏洞逐条补齐状态，再重新生成一次VEX。VEX的四类状态本来就是为了解决“是否相关、如何处置、是否已修复、是否还在调查”的闭环表达。

　　4、导出范围或可见性被标签与排除规则裁剪

　　如果你的实例启用了包标签、共享可见性控制或导出排除选项，报表“不完整”有时其实是“被刻意隐藏”。在导出VEX前，检查资产或组件是否被打了排除类标签，或在报告设置里启用了排除未识别包、排除特定类别组件等规则；这些能力会直接影响SBOM与VEX对外共享的覆盖面。

　　5、上下文可利用性要素不足，自动研判无法给出结论

　　Cybellum的自动VEX生成强调基于多属性做可利用性分析与聚合评估，如果组件运行环境、调用路径、配置特征、内置缓解措施等上下文信息没有被采集或无法映射，系统往往只能给出部分结论，剩余项需要人工补充影响说明或处置动作后才能形成可发布声明。

　　二、Cybellum VEX报告字段与状态应怎样填写

　　1、先按“每条声明只对应一个漏洞状态”来组织数据

　　无论你是通过界面导出还是通过接口拼装，建议把VEX拆成一条条statement，每条statement只承载一个vul_id与一个status，可覆盖一个或多个product_id，但不要在同一条里混写多个漏洞或多个相互矛盾的状态，这样最利于被下游系统稳定解析，也符合VEX最小要求的组织方式。

　　2、statement_id与statement_version要可追溯且可递增

　　在生成或编辑时给每条statement设置唯一statement_id，并在内容有任何变化时递增statement_version，同时维护首次发布时间与最后更新时间字段；如果你的流程是“每周定期更新VEX”，就把版本递增与更新时间当成硬规则执行，否则客户侧很难判断手里的VEX是不是最新。

　　3、product_id与subcomponent_id优先引用SBOM里已有标识

　　填写product_id时建议直接沿用SBOM里产品或组件的既有标识，并明确到版本或版本范围；当需要说明“子组件有漏洞但整机不受影响”时，再补subcomponent_id去指向具体依赖项或库版本，这种表达正是VEX常见用法。实际操作可以在【SBOM】里定位组件条目，复制其供应商与版本信息，回填到VEX的产品与子组件标识字段，避免手写造成不一致。

　　4、status建议使用四类标准值，并与界面状态一一映射

　　VEX通行的四类状态是Not affected、Affected、Fixed、Under Investigation，对应机器可读常见写法是not_affected、affected、fixed、under_investigation；在Cybellum界面里通常也能找到等价选项，关键是导出时保持一致，避免同一含义出现两种拼写让下游规则失效。([First.org][2])

　　5、Not affected必须补齐justification或impact_statement

　　当你判断为not_affected时，优先填写justification，值要从约定集合里选，比如component_not_present、vulnerable_code_not_present、vulnerable_code_not_in_execute_path、vulnerable_code_cannot_be_controlled_by_adversary、inline_mitigations_already_exist；如果客观上无法给出明确justification，就必须写impact_statement，把“不受影响”的原因用可验证的工程事实讲清楚，并记录impact_statement_time便于审计。

　　6、Affected必须写action_statement并落到可执行动作

　　当状态为affected时，action_statement是必填项，内容不要停留在“尽快修复”这种口号，而要写清楚动作路径：例如升级到哪个已修复版本、采用哪个补丁包、是否需要临时缓解配置、验证方式是什么；在Cybellum里可以先在漏洞处置页完成整改计划或缓解措施记录，再在导出VEX前把该信息汇总进action_statement并打上action_statement_time。

　　三、Cybellum VEX报告应怎样校验与对外交付

　　1、导出前用“缺字段清单”做一次完整性预检

　　在【Reports】或【VEX】导出入口之前，先在漏洞列表按缺失字段筛选，重点抓三类：缺vul_id或描述、缺product_id版本信息、状态为not_affected但缺justification与impact_statement；把这三类清零后再导出，通常能把“不完整”问题一次性消掉。

　　2、按产品线与版本范围分批生成，避免一份VEX装下过多语义

　　如果你把多个产品线、多个固件分支、多个客户定制配置一次性塞进同一份VEX，生成端很容易出现范围映射模糊。更稳妥的做法是在导出界面按产品线或版本范围分批生成，让每份VEX的product_id集合可解释、可复核，后续更新也更容易对齐statement_version。

　　3、把VEX当作“持续更新的在线工件”来运营

　　很多组织会把VEX做成一次性交付文档，但更贴合实践的方式是维护一个持续更新的VEX发布点，漏洞新结论出来就递增版本并更新statement_time_last_updated，让客户侧的资产管理系统能够自动拉取与比对，而不是靠人工反复邮件传文件。

　　4、对外共享前复核可见性与排除规则，确保覆盖面符合承诺

　　在交付给客户或供应链伙伴前，回到资产与组件视图核对标签与排除规则是否会隐藏关键包与关键漏洞，并把“为何未覆盖”留在内部审计记录里；如果业务上必须隐藏部分信息，也建议在impact_statement或交付说明中明确披露范围边界，避免对方误以为你漏报。

　　总结

　　Cybellum里VEX生成不完整，最常见的根因不是工具失效，而是SBOM标识、漏洞标识、状态语义与字段必填规则没有对齐。把statement按单漏洞单状态拆清楚，统一product_id与subcomponent_id的命名与SBOM引用，严格按状态补齐justification、impact_statement、action_statement，再配合导出前缺字段预检与版本化发布，VEX报表的完整性与可用性一般都能稳定下来。