開源:使用開放代碼實現企業級安全性?
組織越來越依賴開原始程式碼解決方案,即使他們沒有意識到這一點。但是開原始程式碼安全處理可靠嗎?大型組織正確地高度重視利用可靠、安全的軟體解決方案。通常,功能最強大,實際上最安全的軟體解決方案是免費的開源軟體。
即使組織總是為軟體付費,商業許可的軟體也經常依賴於開源庫來實現某些功能——這本 XKCD 漫畫是這些依賴項如何工作的有力總結。
但是,對開源軟體的安全性存在合理的擔憂,尤其是因為通常沒有一方最終負責開源解決方案的安全性。
因此,2020 年 Linux 基金會的一項調查努力檢查開源軟體安全性也就不足為奇了。在本文中,我們將介紹該調查的一些結果。我們將在一個重要問題的上下文中檢查這些結果:開源解決方案是否可以在企業環境中提供安全的操作。
內容:
1. 是什麼推動了開源開發?
2. 開源開發背後的商業要求
3. 激勵 很重要,但可能沒有人可以激勵......
4. 開源對企業重要嗎?
5. 企業環境中的開源盛行
6. 安全性不是由源模型決定的
7. 填補開源安全漏洞
8. 提高軟體安全性的實用方法
9. 考慮即時、自動修補以提高開源安全性
10. 像處理 任何其他代碼一樣處理開原始程式碼
是什麼推動了開源開發?
我們知道是什麼推動了商業閉源軟體的開發。這是利潤,純粹而簡單。從理論上講,商業軟體供應商將投入時間和精力來保護他們的軟體發佈。
供應商通常還會快速響應代碼發佈后發現的IT安全問題。同樣,動機很簡單。安全軟體是有利可圖的軟體,沒有商業供應商願意在軟體安全方面自由,因為它會很快導致聲譽受損和利潤下降。
當涉及到開源軟體時,事情要複雜一些。開源軟體開發通常不是由協調的商業要求驅動的,向開源存儲庫提交通常不會導致直接支付提交費用。
貢獻背後的動機很重要,因為它指出了圍繞軟體安全的關注程度。Linux基金會的報告提出了開發人員為開原始程式碼做出貢獻的三個典型原因:
- 開發人員在他們依賴的開源解決方案中發現了他們需要修復的問題。或者開發人員需要向他們使用的開源解決方案添加特定功能。
- 作為一種學習練習,開發人員為開原始程式碼做出貢獻,以實踐他們的能力並瞭解有關開源專案的更多資訊。
- 對於一些開發人員來說,為開源專案做出貢獻具有挑戰性、充實的程式設計工作的簡單誘惑。
為開源軟體安全做出貢獻並不在清單中佔據突出地位。事實上,貢獻者表示,他們發現處理開原始程式碼安全問題是一項累人且吃力不討好的任務。
開源開發背後的商業要求
Linux基金會的調查還強調了開源開發的另一個重要驅動因素:商業需求。根據調查,為開原始程式碼做出貢獻的開發人員通常會獲得報酬;52%的開發人員表示,他們被支付給開源項目的貢獻。
換句話說,大約一半的受訪者表示,某種性質的雇主 - 無論是機構還是商業企業 - 正在為要完成的工作付費。這在受訪者中佔很大比例,這反映了這樣一個事實,即有時推動開源貢獻的是商業需求。
這種需求可能是一項新功能 - 但也可能發生商業組織注意到開原始程式碼中的缺陷並付錢給開發人員來修復它。
這對開源安全來說是個好兆頭,但它也表明,除非商業運營商發現缺陷並有動力修復它,否則該缺陷可能永遠不會被修復 - 因為開源開發人員沒有動力致力於開源軟體安全。
激勵很重要,但可能沒有人可以激勵......
我們並不是要急於作出判斷。有數十億行開原始程式碼,其中大部分是在沒有任何報酬的情況下編寫的,因為許多開發人員純粹出於對開源模型的熱愛而分析、編碼和修復。
儘管如此,很明顯,激勵措施(商業或其他方式)有助於加速安全漏洞的檢測和修復。但即使是激勵措施也可能不夠。
我們知道在非常舊的代碼中可以找到一些開源缺陷 - 例如最近在libcurl中發現的錯誤 已有幾十年的歷史。問題在於,即使有正確的激勵措施來修復代碼,找到開發人員來修復代碼也可能具有挑戰性。
隨著時間的推移,開源專案會成熟並淡出背景,即使專案背後的代碼仍在日常使用中。它給尋找開發人員帶來了問題,因為原始開發人員已經轉移到其他專案——留下了有限數量的開發人員,他們仍然能夠衡量專案貢獻的代碼的正確性和價值。
對於許多備受矚目的項目來說,這是一個常見問題,他們都在努力尋找具有可以做出貢獻的資格的開發人員——當涉及到 Linux 內核時,這也是一個問題。這意味著一些項目越來越依賴付費開發人員來推進專案的關鍵方面——包括安全問題。
開源對企業重要嗎?
顯然,開源軟體安全存在相當程度的細微差別,但這對企業用戶來說真的重要嗎?畢竟,大型組織有能力為安全軟體付費。
同樣,這很複雜。對於初學者來說,開源軟體的功能可能超過商業軟體的能力,因此企業可以選擇開源解決方案,即使該解決方案是按商業條款提供的。
商業軟體通常包含開源軟體的元素,例如在庫中,這也是事實。想想PuTTy,一個常用的工具,通常包含在商業解決方案中,但它本身就是最近發現的錯誤的受害者。
或者OpenSSL,一種開放的SSL解決方案,當發現安全漏洞時引起了巨大的波瀾 - 一個拒絕消失的安全漏洞。
企業環境中的開源盛行
關鍵是,即使是純粹依賴商業許可軟體的公司也更有可能依賴某個地方的開原始程式碼。
這不僅僅是一個斷言。Gartner的一項廣泛引用的研究表明,95%的企業運營將開源軟體用於其關鍵運營的某些部分。造成這種情況的原因多種多樣,但很少歸結為省錢的努力。
是的,開源軟體原則上是免費的,但企業級解決方案很少是免費的,因為大型組織通常依賴開源解決方案作為密集開發工作的一部分 - 並且經常將開源軟體與昂貴的支援合同捆綁在一起。
企業有時明確選擇「免費」開源軟體的原因是,在許多情況下,開原始程式碼可以提供最強大的解決方案。
最後,正如我們在上一節中概述的那樣,即使在商業閉源解決方案中,開原始程式碼也是根深蒂固的。事實上,可以說開原始程式碼非常普遍,以至於組織基本上可以假設開放代碼用於解決方案,無論部署的解決方案的來源如何。
安全性不是由源模型確定的
開原始程式碼是公開的,所以從理論上講,更多的人可以而且將會查看這些代碼,因此有更多的機會發現缺陷。然而,現實情況可能會有所不同,因為我們上面指出的OpenSSL錯誤等缺陷需要數年時間才能被發現。
而且,正如我們所解釋的,開源開發人員尋找和發現開原始程式碼缺陷的動機可能有限。
同時,僅僅因為閉源商業軟體是由利潤動機驅動的,並不意味著它比開原始程式碼更安全。不能保證供應商會部署安全研究人員來檢查代碼中的缺陷,並且始終存在項目團隊會匆忙完成編碼以嘗試在截止日期前完成項目的風險。此外,一旦完成,代碼可能永遠不會被審查。
因此,雖然開原始程式碼在理論上更容易受到審查,因此更安全,但不能保證合適的人正在查看它。另一方面,不能保證商業軟體供應商認真對待他們的安全責任。
最重要的是,開發人員總是忽略事情並總是犯錯誤,無論他們是否獲得報酬,也無論向開發人員付款的一方。
填補開源安全空白
您的組織認為開源安全性是否比商業許可軟體的安全性更差或更好並不重要。事實是,開源軟體安全性存在差距,大多數組織都以某種方式依賴於開源軟體。因此,開源軟體安全問題,時期。
是的,軟體安全是您組織的責任,我們將在下一節中介紹一些久經考驗的方法。但是開源社區和開源軟體的用戶必須邁出開源安全的第一步。Linux基金會的報告在這方面提出了一些重要的建議:
- 應該優先考慮資金,以便開發人員有動力從事開源軟體安全工作,包括對最關鍵的開原始程式碼進行定期審計。
- Linux基金會還建議,應該從頭開始重寫一再被證明易受攻擊的開原始程式碼。例如,通過將代碼從記憶體不安全語言(考慮 C 或 C++)轉換為記憶體安全語言 - 想想 Python 或 JavaScript。
- 除了資金之外,開發人員還應該通過徽章計劃和指導來激勵開發人員,以説明提高軟體安全在開源社區中的重要性。
- 最後,Linux基金會建議商業供應商在僱用開源開發人員時應將軟體安全知識作為先決條件,同時還提供持續教育以培訓其開發人員,為安全軟體開發提供支持的基礎。
從長遠來看,開源軟體比目前更安全的唯一途徑是各方重新關注安全性,同時為從事代碼工作的開發人員提供正確的激勵。就目前而言,僅有激勵措施是不夠的。
提高軟體安全性的實用方法
開源軟體安全性存在差距,但有許多工具可以幫助解決這些差距。此外,歸根結底,軟體安全是您組織的責任。我們建議以下幾點:
- 始終如一地應用良好做法,包括多重身份驗證 (MFA) 和強大的密碼安全性。憑據管理和嚴格的許可權管理也至關重要。
- 監控和測試將有助於識別安全配置檔中的入侵者和缺陷,以便您可以在入侵導致嚴重後果之前阻止入侵。
- 瞭解您依賴哪些工具 - 並嘗試掌握底層構建塊,包括庫和依賴項,因為真正的風險往往是看不見的。
但是,可以說軟體安全最重要的元素是修補。持久、全面的修補可保護您的解決方案免受已知漏洞的影響,無論您使用的是自由軟體還是商業許可軟體,它都同樣有效。
也就是說,始終如一地修補並不容易。修補可能非常耗時,團隊通常只是修補優先順序最高的漏洞 - 暴露許多其他缺陷。修補通常需要重新啟動或重新啟動這一事實無濟於事,為了可用性團隊的利益,團隊通常決定不按計劃進行修補 - 僅在存在嚴重漏洞時才進行修補。
考慮即時、自動修補以提高開源安全性
修補至關重要,但通常不如應有的效果。TuxCare的即時自動內核修補將填補開源安全的巨大空白,確保您的伺服器始終針對漏洞進行修補,而不會對服務造成相關中斷。
開源開發團隊和個人貢獻缺乏動力和動力來完全保護他們所貢獻的軟體。而且,正如我們所知,犯錯是人之常情——錯誤總是會犯的。
Linux基金會提出了一些可靠的建議,這些建議可能會改善開源安全,但在可預見的未來,缺陷將繼續寫入代碼中 - 只能被發現並修補。修補很重要。
像處理任何其他代碼一樣處理開原始程式碼
總而言之,企業用戶幾乎總是依賴於開原始程式碼,無論是直接或間接通過庫。雖然開原始程式碼並非本質上不安全,但對於開原始程式碼,存在獨特的安全注意事項。
意識是第一步 - 實時修補可能是一種有用的支持行動。換句話說,開原始程式碼可以高度安全 - 與商業供應商的閉原始程式碼一樣安全。這完全取決於組織的安全狀況。