幾年前，“開源”還是點點星火，如今已成燎原之勢。在過去的 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%。
在調查過程中，我們還發現了維護人員通常都會將時間和經歷放在項目的功能性方面，而往往忽視了安全性。
安全審計
安全審計作為代碼審查的一部分，其中需要雙方確保遵循安全代碼最佳實踐，或者採取另一種方式，即通過運行不同的安全審計變體，如靜態或動態應用程序安全測試。
無論是手動審計還是自動審計，它們都是檢測和減少應用程序中漏洞的重要組成部分，並且應該在開發階段儘可能早地定期執行，以降低後期暴露和數據洩露的風險。
去年，有 44% 的受訪者表示他們從未進行過安全審計，而今年，這一數字要低得多，只有 26% 的用戶表示他們沒有審計源碼。與去年的報告相比，今年重複審計也呈現出了積極的趨勢，以季度和年度為單位，有 10% 的用戶會經常的審計代碼。
閱讀更多 InfoQ 的文章
