今年對確保開源生態系統的完整性和安全性提出了更大的挑戰。開源對開發者來說有非常大的好處，因為幾乎任何人都可以免費地使用和定制它，并為社區做出貢獻。這種能夠確保更大透明度、安全性和促進開發人員跨項目協作的方式，也為對手從中獲利鋪平了道路。

 

作為一名安全研究人員，我在今年遇到并分析了700多個被植入了的RubyGems軟件包，除了挖掘比特幣之外沒有任何其他用途。還有一個很受歡迎的例子是章魚掃描儀，這是一種惡意軟件，它已經悄悄地把它的觸角注入到了至少26個GitHub項目當中。這些事件強調了這樣一個事實，即任何對公眾開放的系統也會對對手開放，并且容易被濫用。

 

上面的例子集中在惡意組件上面。那些沒有被注意到的擁有安全漏洞的合法開源包呢?

 

一個易受攻擊或惡意的軟件包進入流行的存儲庫，并最終進入你的軟件供應鏈，可能會對你的客戶造成嚴重破壞。在npm、PyPI、NuGet和Fedora等流行的開源存儲庫中，已經檢測到了脆弱的和惡意的組件。

 

“在過去的幾年里，我們已經看到了在整個生態系統的開源包中所發現的所有漏洞，傳統上，Node.js和Java每年都顯示出了最大數量的新漏洞，”Snyk開源安全報告2020的作者說。

 

該報告還表明，在軟件開發過程早期實施的安全措施是2019年報告的新漏洞比2018年少的原因。“如果這一趨勢持續下去，這可能是一個積極跡象，表明提高開源軟件安全性的努力正在開始取得成效，”報告繼續說道。

 

下面是一些提高開源代碼安全性的最佳實踐。

 

 

Sonatype進行的2020年DevSecOps社區調查顯示，大多數公司--即使是那些在其工作流程中內置了某種程度的DevSps實踐的公司，也缺乏對其軟件應用程序所使用的所有開源組件以及應用于它們的漏洞的全面了解。

 

“當一個開放源代碼的項目中發現一個漏洞時，你應該立即問兩個問題:我們是否曾經使用過該開源組件，以及(如果是的話)它在哪里?”報告作者說。

 

Sonatype對5000多名開發人員的調查顯示，只有45%擁有成熟DevOps實踐的組織為其應用程序保留了完整的軟件物料清單(SBOM)。“調查結果顯示，在有‘不成熟實踐’的組織中，多達74%的組織無法知道一個新披露的開源組件中的漏洞是否適用于他們的軟件，”該報告說。這意味著那些擁有完整SBOM的不成熟實踐的組織將無法知道他們是否使用了易受攻擊的開源代碼，也不知道在他們的環境中哪里可以找到新發布的漏洞。

 

考慮到每天在NVD、GitHub和其他托管網站上發布的大量漏洞，如果沒有一些自動化的解決方案，開發者和安全專家將很難跟上這些數據。歷史表明，大多數組織都是等到安全事件發生后才會加強他們的安全措施。然而，俗話說，一分預防勝于一分治療。

 

通過在軟件開發生命周期中采用“左移”的方法，在早期實現的安全性可以獲得十倍的回報，并提高開發人員的整體意識。

 

 

Veracode的2020年軟件安全狀態報告強調了一個常見的軟件安全問題。與開發人員本身不同，“相互關聯的依賴關系”會間接地在應用程序中引入潛在的風險，這些風險可能會被大多數開發人員所忽略。“我們的數據顯示，大多數有缺陷的庫都間接地變成了代碼。應用程序中有47%的缺陷庫是可傳遞的--換句話說，它們不是由開發人員直接引入的，而是由某個庫所引入的(42%是直接引入的，12%是兩者兼而有之)。這意味著開發人員引入的代碼會比他們預期的要多，而且往往是有缺陷的代碼。”

 

然而，根據Veracode的說法，糾正這個問題似乎并不是一項重大的任務:“解決這些庫中的安全缺陷通常不是一項重要的工作。應用程序中大多數庫所引入的缺陷(將近75%)都可以通過較小的版本更新來解決。通常不需要主要庫的升級!這一數據表明，問題的關鍵在于發現和跟蹤，而不是大規模的代碼重構。”

 

 

章魚掃描事件和其他形式的開源生態系統的濫用，如typosquatting，已經促使像GitHub這樣的庫維護者必須強制對他們所托管的開源項目進行自動掃描。正如今年所報道的那樣，GitHub現在已經集成了基于CodeQL的開源存儲庫的自動掃描。

 

GitHub高級產品經理Justin Hutchings告訴Register網站，“事實證明，這種能力在安全方面是非常有用的。大多數安全問題都只是錯誤的數據流或錯誤的數據使用。”

 

除了識別出隱藏的漏洞和bug之外，還可以定期掃描開放源碼的項目，以尋找出數據泄漏的跡象，比如貢獻者無意中公開的私鑰和憑證。從去年開始，一些供應商就已經在他們的產品中集成了自動掃描功能，以識別發布到合法開源存儲庫中的惡意軟件。這些技術會將行為分析與機器學習相結合，以主動搜尋“假冒部件”。

 

獨立開發人員在較小規模上發布的實驗性開源掃描器(npm-scan)也出現了，可以使用啟發式方法檢測易受攻擊的組件。

 

在組件進入供應鏈之前，使用自動化工具實現這種廣泛的安全審計可以幫助增加開源生態系統中的信任度和完整性問題。

 

 

使用開源軟件的關鍵好處是它的許可證所提供的自由。如果你在開源包中發現了一個尚未修復的bug，你可以選擇自己修復它，而不是等待供應商。你可以在你的項目中定制一個你認為合適的開源應用程序，并將定制的版本交付給你的客戶。

 

但是，要了解使用開源組件可能產生的任何潛在的許可沖突，就可能需要更多的技巧了。Synopsys發布的2020年開源安全與風險分析報告指出:

 

當一個代碼庫包含開源組件，而其許可證可能與代碼庫的總體許可證發生沖突時，聲明的許可證沖突就會出現。例如，GNU通用公共許可證v2.0(GPLv2)下的代碼在編譯成一個正常分布的商業軟件時通常就會引起沖突問題。但對于被認為是軟件即服務(SaaS)的軟件來說，相同的代碼就不是問題。”

 

對于在不同上下文中使用相同的開源應用程序的開發人員來說，這些相互沖突的術語可能會造成混淆。除了漏洞和惡意組件之外，一些自動化解決方案還可以識別出大量的許可證和由它們所引起的潛在沖突。

 

Black Duck的一份報告發現，2019年審計的代碼庫中有67%包含有許可證沖突的組件。對于某些行業，如互聯網和移動應用程序，這一比例還要高得多(93%)。“GPL是比較流行的開源許可之一，它的各種版本也可能會與代碼庫中的其他代碼產生許可沖突。事實上，前10個有沖突的許可證中有5個就是GPL及其變體，”該報告稱。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。