龙蜥社区漏洞管理治理策略与实践
内容分析：
1.龙蜥社区
2.龙蜥操作系统
3.针对漏洞的治理策略
今天简要地向大家介绍一下龙蜥社区在漏洞治理方面的大致策略，以及目前的一些实践成果。在座的既有老朋友，也有新面孔，因此还是先简单回顾并介绍一下龙蜥社区。或许有些新朋友对龙蜥社区还不太了解。今天是龙蜥社区“走进中心”的活动，接下来先简单了解一下龙蜥社区。
01.龙蜥社区
龙蜥社区的建立，主要是为了应对 CentOS 停服的问题。在 2020年， CentOS 宣布将停止后续服务，相当于红帽公司不再提供免费使用。而国内有大量用户正在使用 CentOS ，因此需要做一个安全替代。另外由于国际形势和各种美国制裁的影响，国产化操作系统也在国家层面得到了大力推广。
所以我们也在顺应国家号召，积极参与了相关工作。龙蜥社区，主要是一个面向云原生和服务器操作系统的社区，这是社区大致发展到现在的状况。大家可以简单浏览一下展示的内容，具体的数字就不一一念出了。既然是操作系统社区，那社区主要做什么呢？它主要做的是基于 Linux 内核的操作系统。这个操作系统使用了社区提供的内核，并基于此进行了开发。其实操作系统与普通应用软件的区别在于，操作系统是一个庞大的开源组件集合。刚才高总提到，一个现代的操作系统可能包含好几千个组件。
龙蜥社区目前定位为一个中游社区。即我们作为操作系统的提供者，是开源组件的一个集合体，而上游则是每个组件的原生社区，即根社区。这也涉及到了刚才高总提到的如何确定选型的系统和组件的问题，即要确保选用的是原生官方的组件。至于下游，则是社区整个生态的延伸部分。从龙蜥操作系统的下游来看，我们拥有众多下游的商业发行版。比如中心的新产品，以及通信领域的应用等。此外还有下游的企业发行版，涵盖了操作系统的产品。
02.龙蜥操作系统
刚开始的目标是构建一个健康的社区生态，简而言之就是要做CentOS 的替代。因此龙蜥操作系统的 7 和 8 这两个版本是对标 CentOS 7 和 8 的，并且 API 都是兼容的。所以在应用生态的兼容以及应用程序的适配上，都做得非常平滑，能够很好地利用现有的生态资源。
而社区的目标是在兼容生态并打造这一能力的基础上，后续开发自己的操作系统。由于深度测试已不再继续提供技术支持，必须自主研发操作系统，即国产化操作系统。下一步鉴于当前的 AI 浪潮，我们正面向下一代计算操作系统进行布局。目前已经发布了版本 23 ，这个版本在选型上与其他 CentOS 有所不同，是自主选型的操作系统。目前该系列已迭代至 23.1 版本，下一步将是 23.2 版本，而预计在 25 年发布的 LTS 版本则是基于这一系列的延伸。届时社区下游将基于此版本开发下一代的操作系统。
操作系统包含了大量的开源组件，这些组件的漏洞无疑是安全领域首要关注的问题。刚才高总展示的图片中也提到了面临的漏洞问题。首先组件体系非常庞大，操作系统中大约包含四千多个组件，而目前维护的整个组件库估计已上万。另外情报的来源渠道多样且质量不一。这意味着有时接收到的漏洞情报可能来源于不同的官方渠道，有的是来自第三方的漏洞收集平台，有的则直接来自官网发布的漏洞信息。而且这些情报的格式也各不相同。
关于漏洞治理，这一直是社区治理中的一个难题，对此一直也没有一个完美的解决方案。刚才提到，漏洞治理仿佛是一场“魔高一尺，道高一丈”的较量。漏洞可能永远存在，它是一个动态的过程，而我们只能持续跟进，无法在某一时间内静态地解决所有漏洞，这是不太可能的。
因为软件本身都不可避免地存在漏洞，这也是信通院发布的 2024年趋势中所明确指出的。漏洞出现的速度日益加快，同时随着各种 AI 工具的接入，即魔高一丈，他们利用 AI 技术来增强漏洞挖掘和利用的水平。此外国际形势的变化，特别是美国的制裁政策，也对获取漏洞情报造成了影响。例如前段时间，美国的 NAD 停止了其部分活动，这导致获取漏洞情报的渠道受到限制，给漏洞评估工作带来了更大的压力。
龙蜥社区也是基于整个业界目前比较领先的漏洞治理流程，该流程大致分为三部分。首先需要感知漏洞，即做到“知己知彼，百战不殆”。必须清楚面临漏洞是哪些，这包括已经发掘并公开的漏洞，以及潜在的、尚未被发现的漏洞。我们会通过白帽子合作挖掘以及客户上报等方式来获取这些信息。在获取到漏洞信息后需要进行评估。下面会基于风险评估来确定漏洞的优先级，包括评分和定级。之后会制定相应的修复方案或者缓解方案。如果暂时无法修复，会提供一个缓解方案来帮助客户避免漏洞带来的风险。
最后要进行漏洞披露。共有两种披露方式。假设发现了潜在的漏洞，在自行修复之后不会立即向公众披露。因为一旦漏洞被公开，若客户修复不及时，就可能会被攻击者利用。因此会首先向下游厂商进行有限披露。在确认下游厂商修复完成后，会再次评估线上用户的修复完成率，然后才会考虑进行公开披露。这是大致的流程，针对这一流程，社区也开发了一些漏洞治理平台，致力于将整个漏洞治理流程自动化，这包括漏洞治理中心。该中心负责整个漏洞情报的收集，以及工单的流转。此外还涉及到工单平台和代码平台。这张图大致描述了目前社区在漏洞治理方面的平台化工作，关于平台的具体细节就不再进行赘述了。
03.针对漏洞的治理策略
这个策略是基于漏洞所带来的风险进行评估的，假设这个风险可能导致 300 万元的损失。那么首先需要明确资产，即哪些组件，对于超系统而言，就是哪些具体的组件受到了漏洞的威胁。接着要分析这个漏洞所带来的具体威胁，比如它是会提前泄露文件的机密，还是会造成系统的破坏，比如引发 DDoS 攻击，或者是导致系统崩溃。基于这些方面首要任务是搞清楚漏洞的具体情况，包括它影响的资产以及所带来的威胁。
目前发现很多漏洞实际上并没有 POC 。正如高总刚才提到的，有些漏洞虽然在理论上被认为是漏洞，但还需要进一步分析它的利用方式，以及确定是否有公开的利用。此外美国记录了哪些漏洞已经被实际利用过，这些被利用的漏洞通常被认为是高危漏洞。另外还有一些与漏洞相关的舆情信息，比如之前提到的 Logo 设计漏洞等。为了评估漏洞的风险等级，采用了 CVSS 的评分机制，将漏洞分为大约四个级别，以识别出哪些漏洞的风险较大。
接下来对整个系统的资产进行分类，以确定哪些资产属于核心资产。这些核心资产可能包括核心组件，例如内核或核心库等。这些组件由于其重要性，一旦受到漏洞攻击，可能会给整个系统带来严重的风险。因此在漏洞治理策略上，基于风险管理的原则，采用漏洞优先级管理技术。这意味着会优先将人力投入到处理高危且涉及核心组件的漏洞上，以确保这些关键部分的安全。
在漏洞感知方面目前主要依赖于商业开源情报。由于漏洞情报的来源和语言多种多样，而我们有专业的合作伙伴，如中科未来，利用他们的 Open Brain 系统来关注并获取容器操作系统所依赖组件的漏洞信息。此外也会自主收集一些开源情报，例如从 MAD 的官方网站上抓取漏洞情报。同时还使用工具进行扫描，目前与七彩公司合作的 ForceI 就是用来对整个产品进行扫描的工具。
在社区贡献方面，有些社区的爱好者会主动发现一些漏洞并报告给我们。为了进一步提升漏洞的发现能力，还与高校进行了合作，并推出了社区的漏洞激励计划，以鼓励更多人主动挖掘我们自研组件中的漏洞。
前面可能提到开源组件的漏洞相对较多，在漏洞评估方面，最初是基于漏洞优先级的方法来评估整个系统中的漏洞。由于漏洞数量庞大，即使拥有足够的人力，也无法将所有漏洞全部修复。因此采取了“好钢用在刀刃上”的策略，集中精力处理高危漏洞。具体来说会结合漏洞的评分、是否已被利用、 POC 是否已公开、风险大小、是否涉及核心组件以及是否引发重大舆情，因为重大舆情还可能带来合规压力等因素，从简单的 CVSS 评分扩展到全面的风险等级评估。基于这一评估体系，可以优先治理核心组件中的高危漏洞。
在漏洞评估与修复方面，由于操作系统主要包含开源组件，因此可以充分利用开源社区的力量，尽量复用开源社区的补丁进行漏洞修复。针对操作系统的维护版本主要采用以下几种修复方式：
首先，如果某个组件没有兼容性和稳定性的问题，会尽量采用release 的方式进行修复。这种方式的好处在于能够与社区版本保持一致，从而使得漏洞扫描软件的适配工作更为简单。
其次，考虑到有些组件因涉及稳定性和兼容性问题而不便于直接升级版本，就会采用补丁集合的方式进行修复。对于这类组件会确保补丁与原有版本兼容，并按照之前的补丁管理流程进行操作。
最后，对于内核这一核心组件也开发了热补丁技术，即 Live Patch 。这项技术允许在不重启系统的情况下，修复内核中的高危漏洞。这是修复策略中的重要组成部分。
在漏洞披露方面，区分了公开披露与私下披露两种情况。对于那些已经公开的漏洞，由于社区已经发布了相关信息，则会通过发布安全公告的形式，来告知龙蜥社区用户已完成的修复情况。而对于那些影响严重的、自行挖掘的漏洞，会经过委员会的审核后，优先私下披露给下游的厂商。
这是龙蜥社区当前的工作平台。在这个平台上可以看到他有安全补丁的维度，并展示了已经修复了哪些漏洞；同时漏洞库的维度展示了采集了哪些漏洞信息。
在社区中与操作系统相关的漏洞信息可以通过查询漏洞状态来了解其是否不受影响或已修复完成。为此提供了一系列记录接口，包括面向个人的实时查询接口以及面向第三方的季度汇总接口，以便对接三方应用时更加便捷。而我们采用标准的接口规范，既支持 OVO 数据格式，也提供 VEX 接口的数据。此外还支持订阅服务，确保用户可以第一时间获取我们发布的漏洞信息。截至目前社区已采集的漏洞数量超过 18800 个，发布的公告超过 1000 个，这是社区至今取得的成果。另外在 2022 年社区已成功申请成为 CNA 的成员。
CNA ，即 CVE 的国际化组织，负责为漏洞分配唯一的编号。当一个漏洞被发现时，为了确保数据的统一交流与识别，需要一个独一无二的编号来标记这个漏洞。 CNA 成员单位作为漏洞编号的授权机构，有权对与其相关的漏洞进行编号申请。龙蜥社区作为 CNA 的成员，有权对其自身挖掘的漏洞进行 CVE 编号的申请，即 CVID 。这一编号的唯一性确保了漏洞的准确识别与追踪。
在漏洞修复过程中可能会先进行内部修复，并在漏洞编号正式公布前，优先将漏洞信息披露给下游的合作伙伴。这样做的目的是在漏洞信息尚未广泛传播之前，尽可能减少潜在的安全风险。
到目前为止，在 2022 年上报了 7 个 CVE 漏洞，而在 2024 年，由于与高校的合作，上报了 CVE 漏洞数量达到了 16 个。未来将继续推进社区的漏洞维护工作，并计划推出龙蜥漏洞岛的激励计划，以进一步激励和推动社区的漏洞研究与防护工作。
之前一直在考虑如何界定漏洞挖掘的范围，特别是针对龙蜥自研组件这一部分。因为对于科研组件，大家都在积极挖掘漏洞，而对于龙蜥社区发布的自研组件，如何管理和处理其漏洞问题，这是一个重要的议题。我们计划按照业界标准给予漏洞挖掘者相应的奖励，以激励大家参与漏洞治理。一旦漏洞奖励机制上线，大家将会看到其设计细节。考虑到社区面临的漏洞数量众多，同时也深知“众人拾柴火焰高”的道理，需要大家共同努力来加强漏洞治理。这里展示的是历史数据，反映了之前在 8 和 23 上面做的协作工作。之后将持续优化和改进，探索如何使社区更好地合作，共同治理龙蜥社区自研组件的漏洞问题。
关于漏洞治理的未来方向，大家刚才提到了很多，其中目前最热门的话题之一就是 AI 。接下来从四个方面来谈谈如何借助 AI 进行漏洞治理。首先是自动化，即如何尽量将漏洞处理流程实现自动化。其次是智能化，即 AI 在漏洞治理中的应用场景。一方面可以利用 AI 技术对漏洞进行更快速、更准确的识别和分析；另一方面也需要关注 AI 系统本身可能存在的漏洞，并对其进行有效的治理。接着是情景化，即结合整个业务场景来区分漏洞治理的优先级。最后是生态化，即如何基于龙蜥社区来构建一个更加完善的漏洞治理生态。
