已有22年历史的通用漏洞披露（CVE）系统存在巨大短板，无法有效解决数百万应用程序和后端服务的云服务中存在的危险缺陷。云提供商通过不共享在其平台上发现的错误的详细信息往往会让客户承受一定的风险。

因此必须存在类似于CVE的云错误管理方法，以帮助客户权衡暴露、影响和降低风险。这是越来越多的安全公司在推动更好的云漏洞和风险管理的观点。他们争辩说，由于按照CVE识别规则，仅有最终用户和网络管理员可以通过分配的CVE跟踪号码直接管理的漏洞，因此当前模型需要被打破了。

CVE系统背后的非营利组织MITRE不为被视为云提供商负责的安全问题指定CVE ID。假设是，云提供商拥有这个问题，那么分配非客户控制或由管理员修补的CVE不属于CVE系统的权限范围。

Summit Route的云安全研究员Scott Piper在最近的一篇博客中写道：这是一个错误的假设，即所有问题都可以由云提供商解决，因此不需要跟踪号码。这种观点有时是不正确的，因为即使云提供商可以解决这个问题，相关人士仍然认为它值得被记录。

Piper的批评是他介绍数十个记录在案的云服务提供商错误实例的精选列表的一部分，他通过如下的真实案例来进行了验证。例如，在过去的一年里，亚马逊网络服务扼杀了一系列跨帐户漏洞。此外，微软最近修补了两个讨厌的Azure错误（ChaosDB和OMIGOD）。而且在去年，Alphabet的谷歌云平台处理了一些错误，包括政策旁路缺陷。

云安全公司Wiz的云研究人员Alon Schindel和Shir Tamari在一篇帖子中写道：随着技术人员不断地发现新型漏洞，专家们发现了越来越多的问题不符合当前[MITRE CVE报告]模型。因此安全行业呼吁采取行动：需要一个集中式的云漏洞数据库。

研究人员承认，云服务提供商确实能够对云错误够做出快速反应，并迅速解决问题。然而，识别、跟踪和帮助受影响者评估风险的过程依然需要简化。例如：当研究人员在8月份发现一系列跨帐户AWS漏洞时，亚马逊通过更改AWS（亚马逊WEB服务）默认值和更新用户设置指南迅速采取行动来解决该漏洞。接下来，AWS又及时向受影响的客户发送了电子邮件，邮件中敦促他们更新任何易受攻击的配置。

但是上述的做法也存在一定的问题，即许多用户不知道脆弱的配置以及他们在面临漏洞时应该采取何种响应行动。要么这封电子邮件从未发送给合适的人，要么迷失在其他问题的海洋中。Schindel和Tamari写道。研究人员表示，在云方面，受影响的用户应该能够轻松跟踪漏洞，以及其组织中是否已经解决，以及哪些云资源已经范围和修复。

云错误的CVE方法还得到了云安全联盟（CSA）的支持，该联盟将谷歌、微软和甲骨文视为执行成员。

Cloud Bug CVE方法：共享行业目标

这些努力有许多相同的目标，包括：

所有云服务提供商使用的标准化通知渠道

标准化的错误或问题跟踪

力度评分，以帮助确定缓解工作的优先级

漏洞及其检测的透明度

8月，Brian Martin在他的博客Curmudgeonly Ways上指出，MITRE涵盖云漏洞的历史好坏参半。有时，一些CVE（编辑）委员会主张将CVE扩展到云漏洞，而另一些则反对。至少有一名倡导CVE覆盖的人表示，他们应该获得CVE ID，[与]其他支持和不同意这样的想法，即如果云被覆盖，[这些错误]应该获得自己的ID计划。他写道。

Martin还指出，即使创建了类似CVE的系统，问题仍然存在：谁来运行它？他认为：唯一比这样一个项目没有启动更糟糕的是，它确实启动，成为安全计划的重要组成部分，然后因为各种原因无法进行下去直到消失。

7月，在CSA的主持下，全球安全数据库工作组被特许将扩大CVE跟踪的想法更进一步。其目标是提供CVE的替代方案，以及该小组提出的所谓一刀切的漏洞识别方法。工作组认为，云迁移带来的IT基础设施的“按需”性质和持续增长要求网络安全的相应成熟。

CSA联合创始人兼首席执行官Jim Reavis在介绍工作组时说：我们可以看到的是，我们需要弄清楚如何为软件、服务和其他IT基础设施中的漏洞创建与现有的技术数量成正比的标识符。共同的设计目标是使漏洞标识符易于发现、快速分配、可更新和公开可用——不仅在云端，同时也在跨IT基础设施中。

本文来源于：https://threatpost.com/cve-cloud-bug-system/179394/如若转载，请注明原文地址