2018 年開源狀況：程式碼貢獻超 310 億行，而漏洞超 16000 個

摘要： 幾年前，“開源”還是點點星火，如今已成燎原之勢。在過去的 2018 年，企業都在積極加強自己在開源方面的實力，IBM 大手筆 340 億美元收購了 RedHat，微軟 75 億美元收購了 GitHub。 開源軟體蓬勃發展的同時，安全漏洞風險也在增加。SNYK 不僅向 500 多名開源使用者...

幾年前，“開源”還是點點星火，如今已成燎原之勢。在過去的 2018 年，企業都在積極加強自己在開源方面的實力，IBM 大手筆 340 億美元收購了 RedHat，微軟 75 億美元收購了 GitHub。

開源軟體蓬勃發展的同時，安全漏洞風險也在增加。SNYK 不僅向 500 多名開源使用者和維護人員分發了調查報告，同時也監控了 SNYK 內部監控和保護的數十萬個專案的漏洞資料，並結合外部研究，釋出了 2019 年開源安全狀況報告。

首先，我們先來看幾個關鍵性結論：

• 2017 年到 2018 年，包管理工具索引的開源包數量呈爆炸式增長，其中 Maven Central 增長了 102%，PyPI 增長了 40%，NPM 增長了 37%，NuGet 增長了 26%，RubyGems 增長了 5.6%。

• 應用程式的漏洞在短短兩年的時間內增加了 88%，其中 SNYK 跟蹤的 Rhel、Debian 和 Ubuntu 的漏洞數量，2018 年是 2017 年的四倍多。

• 最受歡迎的預設 Docker 映像 Top 10 中的每一個都至少包含 30 個易受攻擊的系統庫，其中 44% 可以通過更新 Docker 映像來修復已知漏洞。

• 調查顯示，37% 的開源開發人員在 CI 期間不會進行任何的安全測試，54% 的開發人員不會進行 Docker 映像的安全測試，而從漏洞出現在開源包中到漏洞修復的時間可能會超過兩年。

* 調查顯示，81% 的調查者認為開發人員應該負責開源安全，68% 的調查者認為開發人員應承擔 Docker 容器映象的安全；但只有十分之三的開源維護人員認為自己應該具備較高的安全知識。

開源應用

開源軟體對現代軟體開發產生了深遠的影響，並且這種影響力還在每年遞增。據 GitHub 報告稱，2018 年新使用者的註冊量超過了之前六年的總和，且平臺上建立的新組織和新儲存庫增加了 40%。另外，開源軟體同時也推動了語言和平臺的發展，影響了行業增長，Forrester 報告稱，開源軟體是業務技術戰略的重要組成部分。

前文我們曾提到，科技公司都在大量使用開源，每個程式語言生態系統中都有越來越多的開源庫被索引，且有的增長率實現了兩位數，甚至是三位數的增長（Maven Central 實現了 102% 的三位數增長。）

開源的使用正走在高速路上，2018 年 Java 包增加了一倍，NPM 增加了大約 250000 個新包。

據 Linux 基金會報告稱，2018 年開源貢獻者提交了超過 310 億行的程式碼，這些程式碼一旦要在實際的生產環境中使用，那麼擁有、維護和使用此程式碼的人就必須承擔一定的責任，規避風險。

據 CVE 列表報告顯示，2017 年總共有 14000+ 個漏洞，打破了 CVE 一年內報告的漏洞記錄，而 2018 年，漏洞數量繼續上升，超過了 16000 個。

我們在調查中關注了不同生態中不同軟體包的下載數量，同時也關注了這些開源軟體包如何轉化為使用者採用。

根據 Python 登錄檔顯示，PYPI 在 2018 年的下載量超過 140 億，相比於 2017 年報告中的 63 億，下載量增加了一倍。從下表中我們可以看到在 8 月份的時候，下載量出現了激增的情況，這是由於 LineHaul（PYPI 的統計收集服務）出現故障造成的，該故障導致在 8 月之前大半的下載量丟失。

另外，開源軟體消費也取得了巨大的飛躍，從 PYPI 中下載 python 包的數量是原來的兩倍，從 NPM 下載 javascript 包的數量更是驚人，達到 3170 億個。

NPM 登錄檔是整個 JavaScript 生態系統的核心。在過去的幾年中，無論是新增還是下載的軟體包數量都穩步增，僅 2018 年 12 月的一個月時間就有 300 多億次。

而 Docker 的採用也促進了開源軟體的增長，據悉，Docker 公司在 2018 年每兩週就有超過 10 億個容器下載，截止到目前，數量約有 500 億個。僅 2018 年一年就有超過 100 萬個新的應用程式新增到 Docker Hub 中。

風險和影響

而伴隨著軟體包數量的增加，是漏洞的增加，前文我們提到了 2018 年新漏洞數量再創新高，超過 16000 個。

在 GitHub 釋出的 Octoverse 報告中，Security 成為了最受歡迎的專案整合應用程式。而 Gartner 的行業分析師在最近的一份應用程式安全報告中也表示企業應該在應用程式生命週期中儘早測試安全性。

開源軟體使用的越多，程式碼中自然就包含了更多其他人的程式碼，累積的風險就會越大，因為這些程式碼目前或者是將來可能會包含漏洞。當然，這裡的風險並不單單是指程式碼的安全性，同時也包括了所採用程式碼的許可以及該程式碼是否違反了許可證本身。

在接受調查的受訪者中，43% 至少有 20 個直接依賴關係，這無疑就需要增強對這些引入庫的原始碼的監控。而事實上，只有三分之一的開發人員可以在一天或更少的時間內解決嚴重性漏洞。

“企業應定期使用 SCA 工具來審計包含軟體資產（如版本控制和配置管理系統）的儲存庫，以確保企業開發和使用的軟體符合安全和法律標準、規則和法規。另外，應用程式開發人員也可以使用 SCA 工具來檢查他們計劃使用的元件。

如今，沒有開源依賴的情況下寫程式碼幾乎是不可能完成的任務，所以正確跟蹤所依賴的庫就成為了一個難題。採取何種措施才能既消除漏洞，同時還能保持依賴項之間的相容性？

NPM、Maven 和 Ruby 中的大多數依賴項都是間接依賴項，由少數明確定義的庫請求。在調查中，Snyk 掃描了 100 多萬個快照專案，發現間接依賴項中的漏洞佔整個漏洞的 78%，這說明我們需要進一步增強對依賴樹的洞察，並突出脆弱路徑的細微差別。

開源維護者的安全狀況

雖然在大多數開發人員和維護人員都認同在構建產品和編寫程式碼時，安全性是非常重要的，但是對他們而言，在構建開源專案時沒有“教科書式”的規則可供他們參考，因此安全標準可能有很大的不同。

在今年的調查中，大部分使用者（平均每 10 個使用者中就有 6.6 個）都將他們的安全技術選擇在中等水平，7% 的受訪者認為目前的安全技術水平較低。

相應的專業知識排名，2019 年的排名發生了一些變化，尤其是 High 和 Low，其中 High 佔據了 30%，Medium 佔據了 63%，而 low 佔據了 7%，而在 2017 年，High 只佔了 17%，low 佔了 26%。

在調查過程中，我們還發現了維護人員通常都會將時間和經歷放在專案的功能性方面，而往往忽視了安全性。

安全審計

安全審計作為程式碼審查的一部分，其中需要雙方確保遵循安全程式碼最佳實踐，或者採取另一種方式，即通過執行不同的安全審計變體，如靜態或動態應用程式安全測試。