已有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/如若轉載，請注明原文地址。