2019 開源安全報告：開發者安全技能短板明顯，熱門項目成漏洞重災區！

近年來，開源軟體的使用範圍正在不斷擴大，「擁抱開源」似乎也成了一種企業間的普遍趨勢。特別是在 2018 年，科技巨頭紛紛加註——微軟以 75 億美元收購了 GitHub；IBM 以 340 億美元拿下 RedHat，開源軟體正在成為現代企業的基礎。

與此同時，暴露於安全漏洞的風險也在逐步增長，開源環境的安全問題開始受到越來越多的關注。而漏洞數量的增幅與開發者自身技能與安全意識提升速度間的斷層，也成了一大不容忽視的問題。

作者 | 仲培藝

出品 | CSDN（ID：CSDNnews）

為了更好地了解開源的安全現狀，以及相對應的改進手段，針對開源項目提供安全服務的公司 Snyk 對一系列數據進行了統計分析，並於近日發布了《2019 年度開源安全現狀調查報告》，其數據來源包括：

由 Snyk 發起的一項調查，該調查覆蓋了 500 多名開源項目的維護者和用戶；

Snyk 漏洞資料庫的內部數據，以及由 Snyk 監控和保護的數十萬個項目；

通過研究各供應商發布的外部資源，以及通過掃描數百萬個公開的 GitHub 倉庫和包收集到的數據。

開源項目採用率和漏洞數量「比翼」齊增

Java 包翻番，npm 約增 25 萬新包

回顧 2018，我們不難發現在各語言生態系統中，越來越多的開源庫被編入索引，且呈現出爆炸式增長。2017-2018 年，索引包增長情況如下：

Maven Central：102%

PyPI：40%

npm：37%

NuGet：26%

RubyGems：5.6%

據報告顯示，開源項目的採用率正在加速增長。僅 2018 年間，Java 包便翻了一番，npm 亦增加了大約 25 萬個新包。

Python 下載翻倍，JavaScript 包下載量高達3170 億個

開源軟體的消費也在飛速發展。從 PyPI 下載的 Python 包是以前的兩倍，從 npm 下載的 JavaScript 包更是達到了驚人的 3170 億個。

PyPI 在 2018 年擁有超過 140 億的下載量，較之 2017 年的 63 億次已然翻了一番。

PyPI 包在 2018 年的下載次數

註：如上圖所示，年中下載數量的激增是由於 PyPI 統計數據收集服務 linehaul 的一個故障，因此漏掉了8 月之前了大約一半的下載記錄。據推測，2018 年的下載量為 140 億次，但實際數量可能要更多。

npm 註冊表是整個 JavaScript 生態系統的核心。在過去的幾年裡，其下載數量和軟體包數量一直在穩步增長。僅 2018 年 12 月一個月的下載量就超過了 300 億次，而 2018 年全年的下載量更是驚破 3170 億次。

npm 包在 2018 年的下載次數

隨著軟體包數量的增長，它們的漏洞也在增加。Linux 基金會在去年報告稱，開源貢獻者已經提交了超過 310 億行代碼。然而，隨著大量採用，隨之而來的是巨大的壓力和風險，任何擁有、維護或使用此代碼的人都需要承擔起降低風險的責任。2017 年，CVE 報告了超過 14000 個漏洞，打破了單年內的最高記錄。而這一數據在去年再創新高，披露了超過 16000 個漏洞。

已知漏洞數增幅明顯，處理任務日趨緊迫

漏洞就是漏洞，不管是否已知。兩者之間的關鍵區別在於攻擊者意識到這個漏洞並試圖利用它的「可能性」。因此，對漏洞的認識越深入，對其處理的需求就越迫切。

已知的漏洞可能具有與之關聯的 CVE ID，也可能只是在網上披露或存儲在開放資料庫中。這些都是應該優先消除的已知漏洞類型，因為它們受到攻擊的幾率更高。再之後就應該考慮在封閉的漏洞資料庫中捕獲的漏洞，甚至是在暗網中共享的漏洞。

應用程序庫漏洞在兩年內增加了 88%，npm及Maven Central數據突出

兩年內應用程序的漏洞數量增長了 88％；

2018 年，npm 的漏洞數量增長了 47％；據 Maven Central 和 PHP Packagist 披露的數據顯示，其漏洞數量漲幅分別為 27％ 和 56％；

較之 2017 年，2018 年在 RHEL、Debian 和 Ubuntu 中追蹤發現的漏洞數量增加了 4 倍多

值得特別關注的是，自 2014 年以來，Synk 的 npm 資料庫和 Maven Central 資料庫中的漏洞數量分別增長了 954% 和 346%。

高危漏洞有所減少，但在整體漏洞中仍占最大份額

對比查看了過去三年在所有語言生態系統中公開的應用程序庫的漏洞嚴重程度時發現，與前一年相比，2018 年的高危漏洞數量有所減少。

此外，還有一個有趣的發現，那就是與 2016 年相比，2017 年和 2018 年的一個共同點是，高危漏洞多於中危漏洞或低危漏洞。

Zip Slip 漏洞

Zip Slip是一個廣泛存在的關鍵存檔提取（critical archive extraction）漏洞，該漏洞允許攻擊者在系統中任意寫文件，尤其是會導致遠程命令執行。Snyk安全團隊的研究人員6月5日發現並公布了該漏洞的細節，該漏洞影響上千個工程項目，其中一些工程來自HP、亞馬遜、Apache、Pivotal等。

沒有 CVE 編號的漏洞

當新的漏洞通過國家漏洞資料庫（National vulnerability Database, NVD)）或其他公共 CVE 存儲庫公開時，安全團隊通常會跟蹤並應對這些漏洞。然而，很多安全漏洞是在非官方渠道中發現和修復的，比如通過問題跟蹤器中維護人員和用戶之間的非正式通信。

安全現狀與開發者專業技能不對等，漏洞解決難度升級

誰該對開源軟體的安全性負責？據報告顯示：

81％ 的用戶認為開發者負責開源軟體的安全性

68％ 的用戶認為開發者應該對他們提供的 Docker 容器鏡像負安全責任

只有 30% 的開源軟體維護者認為自己具有高安全性意識

誰該對開源軟體的安全性負責

開發人員總被賦予安全保障的重任，但事實上他們並未準備好。

開源維護者想要安全，但是他們當中有七成表示自身缺乏相應技能。

開源維護者表示，他們的安全知識正在提高，但還不夠高。據調查顯示，大多數用戶將他們的安全知識列為中等水平，平均 6.6 分（滿分 10 分） 63%，而去年這一檔的比例為 56%。

開發者對自身安全意識的認知情況

此外，還有四分之一的開源維護者表示不會去審計他們的代碼庫。去年，44% 的受訪者表示他們從未進行過安全審計，而今年，這個數字倒是降了很多，26% 的用戶表示他們沒有審計源代碼的習慣。

同時報告中還談到了安全測試環節的缺失：

37％ 的開源開發者在持續集成（CI）期間沒有實施任何類型的安全測試；54％ 的開發者沒有對 Docker 鏡像進行任何安全測試

從漏洞添加至開源軟體包到修復漏洞的時間中位數超過 2 年

持續集成期間的安全測試情況

Docker 鏡像成漏洞重災區，Node 環境下數量最多

Docker 鏡像幾乎總是在帶來巨大價值的同時帶來已知漏洞：

十大最流行的默認 Docker 鏡像中，每一個都包含至少 30 個易受攻擊的系統庫

20% 的鏡像可以通過簡單地重建 Docker 鏡像來修復漏洞；44%經過掃描的 Docker 鏡像可以通過更新其基本鏡像標記（image tag）來修復已知漏洞。如果你意識到這一點，修復起來會很容易。

十大流行 Docker 鏡像的漏洞數量

Linux 操作系統的漏洞數量在持續增長

系統庫中的緊急漏洞和高危漏洞數量對比

npm 中的 ReDoS 漏洞激增 143%，XSS 繼續增長

正則表達式拒絕服務（ReDoS）

眾所周知，Node.js 運行時有許多優點，但有一點需要注意的就是「單線程事件循環」，如果沒有正確使用，就極有可能成為其最薄弱的環節。這一情況發生的頻率比大家想像的要高。

ReDoS 攻擊利用了一些正則表達式模式可能導致的非線性最壞情況的複雜性漏洞。對於單線程 runtime 而言，這可能是毀滅性的，這就是為什麼 Node.js 會受到這種漏洞的嚴重影響。

調查發現，在過去三年里，ReDoS 漏洞暴露的數量越來越多，僅 2018 年就激增了 143%：

XSS 漏洞

跨站點腳本攻擊（XSS）已經成為 Web 應用程序日益增長的痛點，2018 年，在 Snyk 一直監控的所有生態系統中，XSS 漏洞呈增長趨勢。

開源庫中的 XSS 漏洞仍然在增加，儘管它已經成為 OWASP（一個組織，全稱開放式 Web 應用程序安全項目）這 15 多年來關注的首要問題。

在這些生態系統中，我們發現 npm 中的 XSS 漏洞最多，總共暴露了 225 個；其次是 Maven 中央存儲庫，有 167 個；PyPI 共 163 個跨站點腳本漏洞。2018 年，PHP Packagist 生態系統披露的 XSS 漏洞最多，共 56 個，其次是 npm（54 個）和 Maven Central（29 個）。

78% 的漏洞是在間接依賴中發現的，這使得修復非常複雜

很難想像在沒有任何開源依賴的情況下編寫軟體的日子。管理項目的依賴關係是一項重要的任務，需要盡職調查來正確跟蹤所依賴的庫。畢竟，你正在部署的應用程序捆綁了你的代碼和依賴項。

npm、Maven 和 Ruby 中的大多數依賴項都是間接依賴項，間接依賴項中的漏洞佔總體漏洞的 78%。

風險和影響

只有三分之一的開發人員能夠在一天或更短的時間內解決高危或關鍵漏洞。

在 GitHub 今年發布的 GitHub Octoverse 報告中，安全性是最受歡迎的項目集成應用程序類別。這裡引用下 Gartner 在最近一份應用程序安全報告中的一段話，該報告講到了組織在應用程序生命周期中儘早展開安全測試的必要性：

企業應定期使用 SCA 工具對包含軟體資產（例如版本控制和配置管理系統）的存儲庫進行審計，以確保企業開發和/或使用的軟體符合安全和法律標準、規則和法規。應用程序開發人員應該能夠訪問 SCA 工具來檢查他們計劃使用的組件。——Mark Horvath, Hype Cycle For Application Security 2018, Gartner

據此次報告顯示，將近一半（43%）的受訪者至少有 20 個直接依賴項，這增加了監視通過這些庫引入的開源漏洞的必要性。

我們使用開源軟體的次數越多，就會積累越多的風險，因為我們包含了其他人的代碼，這些代碼現在或將來可能包含漏洞。此外，風險不僅和代碼的安全性有關，還關乎所採用代碼的許可遵從，以及該代碼是否違反了開源許可本身。

為了更好的開源環境

應用程序組合非常複雜。作為操作系統維護者和開發人員，可以採取一些行動來提高您所擁有和參與的項目的安全性。

開源維護者

提供安全的代碼版本，並向使用者提供一種通信策略，以便積極地影響其他項目和應用程序，最終使自己的項目也很可能受益；

如果可能的話，與同行一起進行安全代碼評審，並遵循安全代碼最佳實踐。將安全性考慮作為代碼評審檢查指標的一部分，並對評審人員進行培訓，以便他們知道應該留意什麼；

定期檢查代碼庫中的漏洞；

明確定義一個簡單的流程，用於負責任的漏洞披露；

為團隊提供對開發、CI，甚至創建 pull 請求時的安全問題的洞察力，以消除所有進入項目漏洞代碼的機會。

開源開發者

作為開源組件的使用者，您有責任充分理解項目使用的直接和間接依賴項，包括依賴項樹中可能存在的任何安全缺陷：

定期使用一種工具來審計代碼庫，該工具可以自動檢測第三方依賴項中的漏洞，為團隊提供修復建議，並監控項目的依賴項（即使在項目部署之後）；

如果您正在報告安全漏洞，請遵循負責任的披露策略，以確保您不會將用戶置於危險境地。如果你不確定如何做到這一點，可以考慮向一家與你合作的安全公司披露；

訂閱開源依賴項的安全通信通道（如果有的話），這樣就可以在報告時了解任何潛在的漏洞。

另附完整報告下載地址：https://bit.ly/SoOSS2019

其他參考鏈接：https://snyk.io/opensourcesecurity-2019/

【完】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！