如何利用 CVECenter 高效修复 CVE？

编者按： 操作系统开源社区承载着整个信息产业底座的位置，因此其地位举足轻重。今天，龙蜥安全 SIG Contributor 陈宇翱为大家介绍了龙蜥社区漏洞响应自动化平台 CVECenter 的前世今生，以及如何通过 CVECenter 的能力提升社区漏洞的处理效率。 本文整理自龙蜥大讲堂 89 期，以下为本次分享内容：  

01

背景介绍：龙蜥安全漏洞的响应流程

操作系统开源社区承载着整个信息产业底座的位置，因此其地位举足轻重。根据学术界的统计，平均每 1w 行代码产生 2.03 个漏洞，而且操作系统涵盖的软件数量众多，代码规模也很庞大。根据统计 Linux Kernel 目前已经超过了 3000w 行代码；Anolis OS 的代码量也达到了 4 亿+，这个代码量也会导致每天产生多个 CVE。随着 CVE 数量连年增长，2022 年披露的 CVE 达到了 34,553 个。因此，安全漏洞给操作系统社区的安全保护工作也造成了很大的影响。

另外，在开源软件供应链安全风险加剧的场景里，由于开源不断吞噬着软件生态，大量应用使用到开源组件。根据统计，有超过 35,863 个开源软件 Java 组件依赖于 Log4j，这意味着超过 8% 的软件包里至少有一个版本会受此漏洞影响。

针对以上两点问题，龙蜥操作系统社区建立了一个安全漏洞响应体系，这个响应体系也是大多数社区通用的一个流程。整体流程分四个阶段：

第一阶段，漏洞感知 。抓取或挖掘 CVE 的数据，并将安全漏洞的信息总结出来。

第二阶段，漏洞评估 。组织安全人员、安全专家对 CVE 的严重等级、影响面进行评估。

第三阶段，漏洞修复 。安全人员将已经评估完成的 CVE 交到对应的研发人员手中进行漏洞修复。

第四阶段，漏洞披露&版本发布。

可以看出，漏洞修复流程贯穿了整个研发流程，同时还会有更多的前置处理。如此对冗长的流程如何进行有效的跟踪和管理，成为了操作系统社区需要面对的一个难题。

对于一些新兴社区来说，他们会依赖于自动化手段， 自动感知 CVE。然后通过自动化的机器人派发工单，同时在整个修复流程中有一些研发工具的支持。

对于一些比较传统的操作系统社区，他们可能会将 CVE 视作 BUG 的一种，然后直接提到工单上，交给对应的社区研发人员修复。在信息同步方面，会采用传统的 Maillist 去开展信息同步的操作。

但这些传统的解决方案并不一定适用于我们的龙蜥社区，因为龙蜥社区有一个独特的安全漏洞响应 SLA（服务等级协议）。

对于不同严重等级的漏洞，龙蜥的修复策略以及实现要求也有所不同，因此就会对漏洞处理的效率提出了比较高的要求。那么对于龙蜥社区来说的解决方案是，建立起一个 自动化、流程化的漏洞管理平台 ，实时跟踪漏洞处理进度、取代重复劳动，提升漏洞处理效率，达到保障用户产品安全的目的。

02

认识 CVECenter

CVECenter 存储了所有相关漏洞的数据。因为漏洞数据的流程比较长，所以龙蜥通过漏洞分库的设计拆分整体流程，便于不同角色的访问控制和管理操作。龙蜥将整个漏洞库分成了三个部分，分别是来源库、评估库、正式库。

从名称上可以看出，来源库主要包含漏洞的一些原始数据，它是最初 CVE 信息汇总的地方。在这里安全人员或者项目管理人员可能会对漏洞进行一些基础的漏洞分拣，然后漏洞可能会进入到评估库里去。

评估库里主要进行一些漏洞的评级、定级、影响范围的评定以及软件包的界定等操作，需要用到评估库的安全人员。在漏洞评估之后是修复环节，对应的是漏洞的正式库，在这个阶段会有一个 pipeline，然后分别交给不同阶段的社区研发人员做一些修复，比如源码仓库的修复等等。整个流程完成后，CVE 就已经被修复好了。

接下来介绍 CVECenter 的页面，上图展示的是漏洞来源库。可以看到很多漏洞的数据，包括一些数据表单，对应的操作，漏洞的高级搜索的选项，以及快速过滤的视图。

在进入到漏洞的详情页之后，可以在这里查看到一些更详细的信息。比如描述、评分、相应的软件包以及漏洞的更新动态等等。

在评估库页面也是类似的设计，在列表页也是将所有正在评估中、审核中的 CVE 展示出来，然后会有一些评估流程阶段的数字，比如当前已经参与评估、审核的人数。点击右边的“去评估”按钮，可以进入到相应漏洞的评估页面。

评估页面上面有介绍到，是对漏洞的严重等级评分以及影响范围去做初步的界定。安全人员可以在页面上填写数据完成评估流程。

后面是正式库环节，它主要包括整个漏洞流程的 pipeline，披露、修复工单、修复流程等等。

另外，CVECenter 还会提供一些数据统计的功能。比如 CVE 上报、处理流程的统计等等。

03

系统目标与整体设计

如上图右下角所示，每一个漏洞库都对应着一个阶段，分别对应着漏洞处理流程的角色协作以及转交等等。

整个流程是，CVE 将漏洞上报到来源库，然后 CVECenter 会发送一个漏洞预警给安全值班人员，安全值班人员完成漏洞分拣后，将工作交接给评估人员，评估人员会进入到系统，在评估后的页面对漏洞进行评估。同时，还会有一些安全专家对所有已提交的评估记录进行审核。当审核通过后，工作会被转移到相关的研发人员手中，研发人员会根据开出的工单以及一些其他的信息进行漏洞的修复。最终工作会被转交到发布人员手中，然后将对应的软件包发布出去。

因此，漏洞管理平台的目标可以概括为：

• 完全自动化的漏洞感知。
• 可分级、可定制的漏洞预警推送。
• 一体化漏洞评估与审核流程。
• 高度自动化的漏洞修复机制。
• 一键式漏洞披露公告。

• 漏洞处理全流程跟踪。

针对以上系统目标，系统设计与开发大概可以分成以下三个步骤：

Step1：可定制的漏洞预警&分级化的处理策略，这是为了提高接收信息的效率。

Step 2：打通响应流程，支撑团队协作。让参与 CVE 修复的不同人员，他们之间的信息更加畅通。

Step 3：提升流程中的自动化能力。将流程中一些重复的、无意义的劳动用自动化的能力取代掉，从而提升漏洞处理效率。

接下来将对刚刚介绍的流程进行简单的展示。

上图左侧是数据统计的列表，右侧是来源库，来源库的漏洞会有一些基础的状态，比如 ordered 现在是待处理的状态，我们可以更改它的状态。Rejected 代表我们不会对这个 CVE 进行处理，Taken 代表我们接受这个 CVE，并将被加入到评估库里。

点击 CVE ID 可以查阅一些相关的信息，以及上报上来的原始字符串。

当漏洞进入到评估库后，可以点击右边的“去评估”对漏洞进行一些评估操作，填写错完一些基础信息后，点击“提交”。当它的状态满足了一定数量的评估记录后，会进入到审核中的状态。龙蜥社区的安全人员就可以从“详情”进入到审核的页面去进行一些操作。

当审核通过后，CVE 就会来到正式库。正式库就会走 pipeline 的流程。每个流程都对应着不同的信息，比如修复工单对应的是社区的 Bugzilla，漏洞修复我们可能会利用一些自动化的能力完成 Patch 的自动合入，此外还有构建打包和发布。这就是整个系统的页面上的使用。

那么我们是如何达成刚刚所提到的系统目标的？

第一点，可定制的漏洞预警&分级化的修复策略。

• CVE 数量相对较多，如果对所有的 CVE 都进行消息推送，过多的预警推送可能会导致用户的“麻木”。因此 CVECenter 在配置页面，基于预警配置了分频告警（即时、每日、每周）。用户可以基于自己自定义的条件过滤掉不关心的 CVE，只将自己关心的 CVE 信息推送到自己的邮件或者钉钉。
• 支持分级化的修复策略，通过不同的分级化的修复策略提高修复的优先级。
• 由于所有的数据都会爬取到一起，因此会导致CVE数据的准确性不高。CVECenter 会基于置信度过滤无效数据，减少工单数量。目前我们在自研一些 CVE 的分类算法。

• 通过数据源的划分或者其他一些条件定制，可以将一些数据设置成高优先级的数据，这部分数据可以跳过一部分的流程卡点，从而加速整个处理流程。

第二点，漏洞处理全流程跟踪，漏洞处理会通过一个 pipeline 进行跟踪。

• 实时跟踪漏洞处理进度：查看当前责任人、时长等。
• 对于外部的研发动作：webhook 监听研发动作，及时流转状态。

• 漏洞逾期自动提醒、转交自动提醒。

第三个，自动化修复能力。我们希望它能取代过程中一些重复且无意义的劳动，比如源码仓库的自动修复，会依托于已经沉淀下来的一些底层的系统能力，来完成 patch 的自动回合，目前这个能力已经完全支持了 Cloud-Kernel 仓库。此外，Rpm 仓库的自动修复还也在我们的规划之中。Hotfix 自动制作已经支持了 Kernel 漏洞的 hotfix 构建。

从上图下侧可以看出，Kernel 的整个流程的比 BaseOS 的更领先一点，它的自动化能力已经达到了比较高的程度。在我们后续的规划中也会不断提升 BaseOS 自动化的修复能力。

在 CVECenter 的整体架构方面，通过单一职责的原则，将后端的逻辑通过业务逻辑拆分成了两个不同的应用，CVECenter Backend 和 CVEController：

• CVECenter Backend 主要负责的是 Web 的后端逻辑接口。

• CVEController 主要负责封装一些底层系统的调用。另外，还把控着整个自动化的流程。

因为整个流程比较长，所以涉及到的外部系统也比较多，包括 Gitee、社区的 Bugzilla、龙蜥的安全公告的平台等等。

04

总结规划

上图展示了一些比较简单的数据统计。

在 CVECenter 之前，因为缺乏一些比较系统化、自动化的手段，所以并不能对处理时长进行比较精确的统计。过去一个 CVE 被处理完的时间大概是五天，而在 CVECenter 上，不仅能加速整个 CVE 的处理流程，还能对每个阶段进行精确的统计。在 CVECenter 上，平均每个 CVE 被处理完的时间大概是 1.5 天。当然也会由于 CVE 处理策略的不同存在一些差异。

其次，在自动化成果的统计方面，从 CVECenter 上线至今，自动化合入率达到了40%+，后续我们还会针对这指标不断的进行优化来提升自动化率。

未来系统建设的目标主要有以下四点：

• 自动化能力：提高平台自动化水平，以尽量减少人力的投入和重复工作，提高处理效率。

• 智能化水平：通过智能化的手段，达成 CVE 可信度、影响域等指标的分析