供应商说漏洞不影响交付，扫描报告里却仍标着高危，这张单该不该退回？车载项目中，争议常出在双方拿的依据不同：一方看组件版本，另一方看编译配置，还有人拿开发环境的测试结果解释量产软件。Cybellum可以把组件、漏洞和产品关联起来，不过，要据此安排修复，仍得确认这些信息说的是同一份软件。

　　一、Cybellum如何评估车载软件漏洞的实际风险

　　以下操作参照Cybellum官方公开界面，栏目名称和功能位置可能随部署版本变化。

　　1、选准软件版本，再看漏洞命中

　　①打开【Assets】，选择目标产品及待评估版本，进入【SBOM】，选择漏洞关联的组件。

　　②切换到【Vulnerabilities】，打开对应CVE记录，查看关联组件和漏洞详情。

　　③在详情中打开【Affected products】，选择需要核查的产品。

　　先核对扫描包与交付包的构建标识。开发镜像里存在、量产时删除的组件，与已经装车的易受攻击组件，处理方式会不同。若当前资产对应的是旧包，后面再详细的分析也可能用错对象。

　　组件版本落入漏洞范围，说明需要调查；是否影响整车，还要继续检查相关功能是否存在、输入能否到达，以及利用所需条件是否满足。

　　2、沿着漏洞条件核对产品配置

　　①打开漏洞详情的【Description】，阅读受影响范围、触发条件和参考信息。

　　②切换到【Analysis】，查看已有评估；部署中已启用相应功能时，打开【Virtual analyst】，阅读自动分析理由。

　　③返回【SBOM】，选择关联组件，查看可用的文件及组件信息。

　　例如某漏洞要求启用特定内核功能，就要拿量产构建配置来核对。另一个漏洞需要处理外部输入，则应查清输入来自哪个接口、经过哪个进程，是否调用相关解析功能。这些属于人工复核内容，不能假定平台已经自动验证了整条车辆通信路径。

　　二、Cybellum漏洞优先级与产品暴露情况不一致如何判断

　　遇到排序争议，可以选一条具体漏洞，把列表依据和现场证据放在一起核对，避免笼统讨论“评分准不准”。

　　1、确认列表按什么依据排列

　　①进入【Risks】→【Vulnerabilities】，打开目标记录，查看【CVSS】信息。

　　②打开【Virtual analyst】，检查当前分析规则；界面提供【Security policy】时，查看相应策略。

　　CVSS基础分描述漏洞本身的严重性，无法单独代表产品风险。企业策略还可能考虑受影响产品数量、发布计划等因素。若一个漏洞被多个待发布项目共用，提前修复可能更有价值，但这与某个ECU是否容易受到攻击是两项判断，应分别说明。

　　2、检查“暴露低”的证据有没有缺口

　　①进入漏洞的【Analysis】，阅读降低优先级或判定不相关的具体理由。

　　②打开【Affected products】，逐个选择相关产品，检查各自的分析记录。

　　“没有公网地址”不足以说明入口不可达。数据还可能经车机、诊断设备或其他控制器转入目标组件；相反，服务对外开放，也不代表攻击输入一定满足漏洞条件。需要查的是接口、进程、权限与易受攻击功能之间的关系。

　　如果理由只是“测试未复现”，应保留测试环境、输入和覆盖范围。一次没有触发，不能替代对利用条件的核查。

　　3、查看状态是否沿用了旧结论

　　①在【Vulnerabilities】中切换【Under review】、【Understood】和【Resolved】，查找相关漏洞。

　　②打开详情中的【Activity】，查看状态变更时间和已有说明。

　　③切换到【Analysis】，核对结论对应的软件版本。

　　平台处理状态与产品受影响结论不能混用。开发分支完成修复，量产包尚未更新，装车产品仍需跟踪；旧版本关闭的入口若在新版本启用，原先的暂缓理由也应重新审查。

　　三、Cybellum风险评估有分歧时如何补充核查

　　同一条漏洞出现不同结论时，可以从受影响产品列表入手，选取具体版本逐项对照。

　　1、查清不同产品为什么采用不同结论

　　①在漏洞详情中打开【Affected products】，选择存在争议的产品。

　　②进入各产品的【Analysis】，对照分析理由。

　　③返回相应资产的【SBOM】，选择关联组件，核对版本和文件信息。

　　例如两个控制器都包含同一网络库，一个启用了相关协议，另一个裁掉了该功能，评估结果可以不同。如果两边配置相同，结论却相反，就应继续查分析时间、补丁状态和供应商说明，找到差异出处。

　　2、检查暂缓理由是否仍然有效

　　①打开漏洞详情的【Activity】，查看结论形成时间和变更记录。

　　②切换到【Analysis】，核对暂缓处理所依赖的条件。

　　过去因远程服务关闭而暂缓的漏洞，在新版本开放服务后需要重新评估。若记录只写“风险较低”，没有对应配置和验证材料，这条理由还不足以支持继续暂缓。缺的是哪份配置、哪项测试，应明确记下来。

　　3、从发布版本复查处理结果

　　①在【Assets】中选择准备交付的版本，打开【Vulnerabilities】，查找原漏洞。

　　②打开该记录的【Analysis】和【Activity】，对照已有修复说明。

　　③切换到【SBOM】，检查关联组件是否与修复对象一致。

　　扫描后仍有命中，可能需要核实补丁回移；条目消失，也要确认扫描范围没有缩小。对照对象应是准备交付的那份软件，避免拿开发分支的处理结果替代发布检查。

　　总结

　　开发人员说已经修复，安全人员仍看到漏洞命中，双方可能都没说错：补丁已经回移，组件版本号却没有改变。把交付包、补丁记录和扫描对象对上，这类争议才有机会解释清楚。Cybellum中的评估结论也应留下这些依据，方便下一次更新时判断哪些内容还能沿用、哪些需要重查。希望这些核查思路能帮到大家，减少漏洞排期和版本交接中的反复确认。如有相关需求，也欢迎联系咨询。