源兮SCA从漏洞发现到SRP上报

一次常规检测之后，告警列表里出现了一条超危记录：CVE-2021-39144，XStream 远程代码执行漏洞。这不是演练数据，很多企业的代码仓库里确实带着这个版本的 XStream，而且它正在被真实利用。这篇文章从这条漏洞的详情页开始，一路走到向 ENISA 单一报告平台（SRP）提交报告。文中的截图来自源兮的真实系统实操和一套私有演练沙箱。

一、漏洞详情页：EPSS 和 CVSS 两个分数

点开这条告警，详情页顶部有一排标签，其中两个是分数。EPSS 是在野利用概率评分，回答的问题是“这个漏洞现在被真实利用的可能性有多大”。源兮把多源在野情报放到一起做量化评估，这条 XStream 漏洞的 EPSS 很高，说明攻击已经在真实环境里发生。

CVSS 8.8 是严重性评分，量化的是“被利用之后有多严重”。XStream 反序列化漏洞在这项上接近满分：利用成功可以执行任意代码，等于把服务器交出去。CISA 在野利用清单（KEV）里也有这条，风险等级是超危。这四个标签合起来看，这条漏洞正在被利用，而且能远程拿到权限。对欧盟 CRA 第 14 条来说，它已经很接近“被积极利用的漏洞（AEV）”的定义，从知悉那一刻起，24 小时的 Early Warning 时钟开始走。

二、AI 漏洞助手：对着这条超危漏洞直接提问

源兮系统里自带 AI 漏洞助手。对着这条超危漏洞直接提问，它会结合漏洞情报和项目上下文给出一份分析，漏洞机理、影响范围、利用条件、该升到哪一版都列在里面。工程师在写报告之前不需要再去翻五六个情报源。

另外，研判过程留了痕。AI 助手整理出来的结论可以直接填进 72 小时通知的初步评估一栏，写报告的人不需要另起一份文档重述一遍。

三、修复方案：受影响组件和目标版本逐项列出

判定之后进入处置。修复方案把受影响组件、当前版本、目标版本逐项列清楚，哪个依赖要动、目标版本是多少，工程侧拿去就能排迭代。

CRA 的 72 小时通知要求提交方说明“已采取或拟采取的措施”。修复方案页上列的内容可以直接填进缓解措施字段（v22），处置做到哪一步，表里就填到哪一步。

四、填进 SRP 表单：39 个字段，24 小时、72 小时、14 天

判定成疑似 AEV 之后，报告分三步：知悉起 24 小时内提交 Early Warning；72 小时内提交 Notification，含初步评估和已采取的措施；缓解措施可用起 14 天内提交终报。SRP 表单有 39 个字段，按这三个阶段标注必填和选填。

把表单字段和前面的详情页对了一遍，出处基本都能找到：漏洞标识（v25）对应 CVE 编号；严重性（v26）对应 CVSS 评分；被利用状态（v27）对应 EPSS 和 KEV 判定；受影响产品与组件（Nr5/6）对应 SBOM 里的 XStream 条目和版本；缓解措施（v22）对应修复方案。检测报告和上报表单写的是同一份技术事实。

五、检测数据要能直接作为举证材料

这条链路走完，检测数据这一段最花时间。组件和版本识别要准，否则受影响范围是错的。在野情报要多源，EPSS、KEV 之外还有 CNVD、CNNVD，少一路判定就会慢。可达性和利用条件都得有，没有这两项，每次 KEV 命中都得当 AEV 处理，24 小时的时钟会被反复误触发。SBOM 要能按 SPDX 和 CycloneDX 两个标准导出，附在上报里就是现成的组件证据。

源兮 SCA 是按这个前提做的：每一条检测记录，像这条 XStream RCE 一样，都要能直接作为可提交的合规证据。只给出 CVE 编号的检测报告，填不进这 39 个字段。