今天，OpenCloudOS开源操作系统社区安全SIG正式推出EARS V1（Exploitability and Attack Risk Scale，漏洞可利用性与攻击风险等级 V1），它并非是一个取代CVSS的新评分，而是一套实战化风险判断为核心的评级体系，通过综合分析漏洞利用条件、在野攻击态势与真实环境可达性，将动态威胁情报纳入评级体系，致力于反映漏洞对业务的真实影响与实时威胁。EARS V1旨在帮助用户与生态伙伴实现从“看分值”到“看风险”的漏洞治理进阶，让修复决策更精准、更及时。

你可能见过这样的情况：同一个漏洞，不同发行版，两个不同结论。

• 漏洞CVE-2025-24813，CVSS评分8.6（满分10分，高危），厂商A却把它定为“中”优先级。

• 漏洞CVE-2025-0237，CVSS评分5.4（中危），厂商B却给了“高”优先级。

为什么？因为厂商在用自己对产品配置、默认环境的理解，去校准CVSS这个通用评分——这是专业性的体现，也是行业共识。

但即便经过了这样的校准，再看另一个场景：两个漏洞都是7.5分，一个正在被大规模利用，另一个披露一年了却无人问津。面对这两个漏洞，厂商评级可能都是“高”，也可能都是“中”——但更加贴切的风险评级，应该关注这个漏洞此刻是否正在被利用。

问题的根源不在“谁评得准”，而在静态的评估框架，永远抓不住动态的威胁。

今天，OpenCloudOS社区正式发布国内首个面向真实业务风险的动态漏洞分类分级体系。它不是一个取代CVSS的新评分，而是一套将动态威胁纳入评估核心的机制——让漏洞优先级既能反映你业务面临的真实风险，也能反映漏洞实时的威胁态势。

一、漏洞的世界是怎么运转的？

要理解我们的新标准，得先知道漏洞是怎么来的。

当一个软件包（比如Linux内核）被发现有安全缺陷时，会给它发一个“身份证号”——CVE编号。同时给它打一个“技术分”——CVSS评分，0-10分，评分越高代表理论上的破坏力越大。这就是你经常看到的“漏洞CVSS评分8.8”的来源。

用静态评分去衡量动态风险，就像用一张照片判断一个人的健康状况——照片只能记录按下快门的那个瞬间，而人的状态随时在变化。

漏洞的技术评分（CVSS）就是那张照片：它在漏洞诞生的那一刻被定格。但真正的风险是动态的——一个CVSS评分原本是低危的漏洞，明天可能因为攻击工具的出现而变成致命威胁；而几个月后补丁普及，风险又降下去了。

照片不会变，但人一直在变。用静态的快照去管理动态的风险，注定会错判。

二、不止于评分：漏洞评分评级的困境

2.1 漏洞数量暴涨，但大多数只是“虚惊一场”

近几年，全球披露的漏洞数量持续攀升。

如果只看评分应修尽修，安全团队会陷入什么境地？每天面对几十个高危告警，分不清哪些是真威胁、哪些是理论风险。最后要么麻木不仁，要么把精力浪费在永远不会被攻击的问题上。

[图1：全球CVE总数与Linux内核CVE趋势图（2021-2025）]

数据来源：公开CVE数据库。

全球CVE总数从2021年的约2万增长到2025年的近5万，而Linux内核CVE占比从不足1%升至超过10%。漏洞数量的激增，很大程度上源于厂商的“防御性申报”——为了提升安全性，把极端条件下才可能触发的代码缺陷也标记为漏洞。

2.2 资源错配的代价

[图2：25年Kernel及其他软件包漏洞PoC/Exp分布]

据统计，每年披露的漏洞中，超过90%从未出现过公开的利用代码。如果把精力平均分配给所有高分漏洞，意味着你投入的100块钱，有90多块可能打了水漂。更糟的是，“过度修复”还可能引入系统稳定性风险——你在修复一个永远可能不会被攻击的漏洞时，反而可能把系统搞崩了。这也是我们在用户调研中，超过70%的OS使用者最担忧的问题。

2.3. 静态评分抓不住动态风险

以Apache Tomcat漏洞CVE-2025-24813为例：

2025年3月12日，漏洞刚披露时，CVSS评分5.5，被定为“中危”——有一定威胁，但利用难度较大，看起来并不紧急。

几天后安全机构首次观测到该漏洞的在野利用证据——意味着已经有攻击者开始用它真实入侵系统。随即鉴于威胁快速升级，CVSS评分从5.5紧急上调至9.8，进入“致命”级别。随后，该漏洞被列入“已知被利用漏洞清单”（KEV），成为全球公认的必须紧急处置的高危威胁。

短短一周内，同一个漏洞从“中危”演变为“致命”，从“理论风险”变为“真实攻击”。

如果只盯着它3月12日5.5分的CVSS评分不变化，你可能会把它归入“稍后处理”的队列——而一周后，攻击者已经找上门来。

用同一个评分管到底，显然不合理。

[图3：CVE-2025-24813漏洞风险演变趋势图]

2.4 厂商评级是可靠的，但通用评分仍有局限

不同厂商对同一漏洞给出不同评级，是因为我们会基于自己的产品配置和默认环境做二次判断——这是专业性的体现。OpenCloudOS的评级也正是基于这样的深入理解。

但即便最专业的评级，也无法覆盖所有可能的环境差异——有些组件可能并非默认安装，有些服务可能默认关闭，有些攻击路径可能依赖特定配置。这些差异，决定了同一个漏洞在不同场景下的实际风险可能截然不同。

这正是OpenCloudOS社区发布新标准要解决的问题：过去我们基于静态分数评级，现在我们用一套动态机制来评级。这套标准将组件默认状态、攻击门槛、威胁情报等因素纳入内部评估流程，最终输出的是一个更贴近真实风险的优先级结论。 

三、OpenCloudOS社区的新标准EARS V1：动态计算风险的评估机制

我们深知，一个漏洞的理论严重性（CVSS评分）与实际环境中的风险往往存在差距。因此，我们建立了一套 “四维动态评估矩阵” 。这套方法的核心理念是：充分尊重并利用CVSS作为科学基准，但绝不机械套用其分数，而是结合OpenCloudOS的服务器场景与实战威胁，进行二次深度研判。

你可以将其理解为一个精密的“风险筛子”，它包含四个层层递进的评估维度：

第一层：技术严重性——底层的参考系

我们全面采纳CVSS v3/v4的基础指标（攻击向量、复杂度、影响等）作为客观、可比较的技术基准。这如同体检的生化指标，至关重要。但我们更清楚，同一份“体检报告”在不同个体（不同操作系统发行版）身上的临床意义可能天差地别。因此，CVSS评分是我们的起点和重要参考，而非直接决定修复优先级的最终判决。

第二层：利用前提条件——评估漏洞的利用可行性

在这一层，我们超越CVSS的通用描述，深入OpenCloudOS的具体环境，评估漏洞的实际利用可行性。关键问题包括：

• 漏洞涉及的服务或组件，在OpenCloudOS的默认安装和配置中是否启用？

• 攻击路径是否被OpenCloudOS默认的安全策略（如沙箱、访问控制）所缓解？

• 利用所需的权限和交互条件，在典型的服务器生产环境中是否容易达成？

经过这层筛选，许多理论评分很高的漏洞，因其在实际场景中极高的利用门槛，其紧急程度会被合理下调。

第三层：业务影响研判——明确漏洞的实际危害

我们区分不同的实际危害类型：是能让恶意利用者远程控制你的机器？还是只能窃取点不重要的信息？是能瘫痪整个系统？还是只能搞点小破坏？

这一层帮你看清：即使漏洞存在、也能被利用，它到底会造成多大损失。

第四层：威胁情报驱动——AI Agent动态感知在野利用态势

[图4：漏洞可利用性趋势示意图]

这是我们将静态评分转化为动态风险管理的关键。得益于AI Agent的飞速发展，我们得以广泛感知多元的威胁情报。不仅涵盖了国际公开漏洞情报、主流商业威胁情报、腾讯自研安全情报在内的多方信源，同时也能盯住互联网上与每个漏洞相关的博客文章、讨论和目击事件，做到风险持续监控：

• 该漏洞是否已被列入权威的“已知被利用漏洞”清单？

• 漏洞利用代码（PoC/Exp）是否已在公开或地下论坛出现？

• 是否已监测到针对该漏洞的真实攻击活动？

如果一个漏洞理论评分很高，但披露半年后仍未观察到公开的利用行为或活跃的攻击活动，那么它的修复优先级就应该动态下调。反之，如果一个漏洞在披露后短期内即出现公开的利用代码或在野攻击证据，它的优先级就需要及时上调。

这4个维度不是简单的加权平均，而是相互校验的动态模型。技术严重性提供基础参考，利用前提条件衡量攻击门槛，利用结果区分危害类型，在野利用可能性反映实时威胁——4个维度综合研判，最终输出一个更贴近真实风险的结论。

五、实践验证：新标准的效果与价值

我们在2025年的全量漏洞数据上对EARS V1做了验证，结果如下：

• 高危漏洞“水分”挤出率超过90%。经过新标准重新评估，真正需要紧急修复的漏洞数量大幅下降。以前可能盯着100个“高危”告警，现在优先关注不到10个。社区应对漏洞的精力，从“疲于奔命”变成了“精准制导”。

• 重大威胁无一漏网。2025年业界多个具有重大影响的、正在被恶意利用的漏洞，新标准全部精准识别、正确定级，实现了应修尽修、无一遗漏。

  六、未来规划：AI赋能风险分析

上述四维动态评估矩阵，是当前EARS V1落地应用的核心。而面向未来，我们正在探索如何让标准的执行更及时、更可靠。

我们规划未来引入更多AI能力辅助风险分析：

辅助特征分析：对于新曝光的漏洞，AI可以深入解读公告，背靠背阅读组件源代码，理解技术细节，分析潜在利用路径和业务影响，给出更加专业化的判断。

动态优先级演算：结合多源情报，AI可以实时更新每个漏洞的在野利用概率，让优先级始终反映最新威胁态势。

结语：让漏洞分级，真正反映你的真实风险

OpenCloudOS社区今天发布的这套EARS V1（漏洞可利用性与攻击风险等级），是我们对行业痛点的回应，也是我们在自身业务场景中验证过的实践沉淀。帮助用户不再被静态评分困扰，不再被海量告警淹没，而是能聚焦于那些真正威胁到业务的漏洞。

我们期待OpenCloudOS社区及业界同仁携手，不断完善这一基于真实风险与动态证据的治理框架，推动基础软件安全迈入更智能、更高效的新阶段。

如您对本标准有任何建议或希望进一步交流，欢迎联系我们：

• 邮箱：security@opencloudos.tech

您的每一条反馈，都是我们共同前行的动力。

（本文引用的案例、数据均来自公开资料及OpenCloudOS社区测试，已做脱敏处理。）

转发有礼福利来啦～

为了“EARS V1”能让更多操作系统用户及开发者看到，从现在起截至3月31日，转发本文至朋友圈并收集 10 个以上的点赞，截图上传至下方二维码的收集表里，即有机会获得OC社区准备的精美礼品：小Q鹅毛绒挂件/长鹅毛绒公仔。

此外，欢迎在收集表里填写对“EARS V1”的想法和建议，就有机会与安全SIG的专家一起探讨，并获得一份限量专属礼品：QQfamily夏季礼盒。

OpenCloudOS 开源社区是由操作系统、云平台、软硬件厂商与个人携手打造中立开放、安全稳定且高性能的 Linux 操作系统及生态。目前已实现从源社区、商业版、到社区稳定版全链路覆盖，旨在输出经海量业务验证的企业级稳定操作系统版本，为行业解决国产操作系统上下游供应问题，促进基础软件可持续发展。