供应商通知某个组件已经升级，开发人员也完成了替换，Cybellum里却仍然显示旧版本漏洞。此时不能仅凭风险数量没有下降，就判断升级失败。平台可能仍在分析旧的软件清单，也可能在其他位置识别到了同名组件，或者漏洞情报尚未反映供应商的修复说明。追踪风险变化，需要把实际交付文件、组件清单和漏洞记录对应起来。以下按Cybellum英文界面的常见操作对象说明，具体入口随部署版本有所区别。

　　一、Cybellum如何追踪软件供应链中的风险变化

　　持续监测能够发现既有组件新出现的风险，但组件升级后，还需要让平台获得对应版本的资产数据。监测漏洞情报和更新组件清单，是两个需要分别核对的环节。

　　1、建立与产品版本对应的组件清单

　　组件清单应反映实际交付内容。只修改组件名称或版本文字，不能证明安装包、固件中已经没有旧文件，升级核验仍应保留原始材料作为依据。

　　①打开目标产品版本的【SBOM】，核对所属产品、版本和分支。

　　②提交对应构建的软件材料，或导入供应商提供的【SPDX】、【CycloneDX】清单，确认关联到正确版本。

　　③在组件列表中检查【Version】，记录升级前后的组件信息。

　　④核对【SBOM】验证及审批记录，保留升级前版本的数据。

　　2、比较版本变化并检查风险记录

　　①使用版本比较功能，选择升级前后的【SBOM】，检查新增、移除及版本变化的组件。

　　②打开相关漏洞记录，按【CVE】编号核对受影响组件及产品版本。

　　③检查风险监测配置，确认需要维护的产品版本和分支已纳入监测。

　　版本比较能帮助区分“组件变了”和“情报变了”。同一组件没有升级，也可能因为新披露漏洞而增加风险；组件已经升级，也可能引入其他问题。记录变化时应保留具体漏洞编号及关联对象，避免仅比较两个版本的风险总数。

　　二、Cybellum组件升级后风险记录未及时更新如何排查

　　发现记录未变时，可以选一条本应受到升级影响的漏洞向下检查。先确定它对应哪份材料、哪个组件实例，再检查分析结果和漏洞依据。

　　1、确认平台处理的是升级后的材料

　　①打开新版本的【SBOM】，核对目标组件的【Version】。

　　②对照导入或分析任务记录，检查材料名称、提交时间和处理结果。

　　③核对交付包中的实际组件版本，检查是否仍包含旧库、插件或备用文件。

　　④材料不一致时，重新提交正确构建或【SBOM】，处理完成后再次查看组件列表。

　　2、检查组件标识和重复实例

　　①在【SBOM】中查找同名组件，逐项核对【Version】及其所属位置。

　　②检查组件的【CPE】、【PURL】等已有标识，与供应商清单中的组件身份对应。

　　③从目标【CVE】记录返回关联资产，确认它指向升级后的实例，还是仍然存在的旧实例。

　　产品中可能同时带有多个版本的同一组件。某个模块完成升级，另一个模块仍使用旧库时，相关漏洞继续存在有其依据。组件标识不准确也可能影响漏洞匹配，修正时应保留版本、来源等证据，避免只为了减少告警而改动识别信息。

　　3、核对漏洞情报与供应商修复依据

　　供应商所说的“已修复”，有时表示在原版本基础上回补补丁，版本字符串未必发生明显变化。这种情况需要结合修复说明判断，不能只看版本号是否升高。

　　①打开目标【CVE】的详情，核对描述、受影响范围和修复信息。

　　②部署版本提供相关页面时，查看【Sources】和【Resources】，对照情报来源及供应商公告。

　　③将补丁说明、构建标识和实际文件与【SBOM】中的组件对应，记录差异。

　　④情报尚不明确时，保留核验依据，通过现有漏洞评审流程处理该记录。

　　4、检查审批范围、监测对象及页面筛选

　　①核对当前页面所选产品版本，再查看对应【SBOM】的【Approved】状态及审批记录。

　　②检查风险监测范围，确认新版本没有遗漏，同时记录仍需维护的旧版本。

　　③取消可能隐藏变化的筛选条件，再按同一【CVE】编号查看风险详情与汇总结果。

　　④对照漏洞数据源的同步记录和评估任务结果，定位尚未完成的处理环节。

　　审批完成说明清单经过了相应流程，并不等于其中的漏洞已经修复。当前产品视图也可能同时汇总多个版本的风险，因此新版本风险减少后，产品总数仍可能保持不变。对比时应统一版本和筛选范围，不宜反复提交相同材料代替定位问题。

　　三、Cybellum风险变化核实后怎样维护处理记录

　　风险记录的变化需要能够解释。确认修复、仍受影响和暂时无法判断，应分别保留依据，避免在后续版本复查时丢失判断背景。

　　1、让处置结论对应具体版本

　　①在目标【CVE】记录中，核对关联的组件版本和产品版本。

　　②附上升级材料、供应商说明及验证结果，按实际结论更新处置记录。

　　③需要共享判断时，生成【VEX】或【CSAF】报告，核对受影响产品范围。

　　新版本完成修复，不代表旧版本中的同一漏洞也已消除。处置记录应说明结论适用于哪些版本；风险接受或补偿措施，也应与修复事实区分，避免后续人员把管理决定当成组件已经变化的证据。

　　2、复查其他产品是否使用同一组件

　　同一供应商组件可能被多个产品复用。处理某个版本之后，沿组件身份检查其他关联资产，可以发现仍未升级的分支，也能减少重复调查。

　　①在资产与【SBOM】中查找相同组件，分别核对版本和关联产品。

　　②对仍使用旧组件的产品，按相同【CVE】编号检查风险及处置进度。

　　③保留前后两版【SBOM】、风险报告与核验记录，注明各自适用的构建。

　　④后续收到新修复说明时，返回关联【CVE】记录复查原结论。

　　总结

　　Cybellum把组件、产品版本和漏洞信息联系起来，能够帮助团队看清软件交付之后的风险变化。这项工作的价值，在于让升级是否到位、哪些产品仍受影响、已有结论依据什么，都有可复查的记录。风险数量只是观察入口，准确的资产数据和清楚的版本关系，才方便后续维护人员接着处理。希望这些排查思路能帮助大家核清记录未更新的原因。如需了解Cybellum相关产品信息，欢迎沟通咨询。