Google 專家探索開源安全挑戰和修復

一個開源安全事件帶來了關于供應鏈安全和開源項目管理缺陷的討論。

隨著越來越多的組織在其軟件中依賴開源組件，保護這些組件的問題變得越來越緊迫。

這是谷歌今天舉辦的一場活動的前提，在此期間，開源專家討論了保護開源軟件的無數挑戰、公司應該優先考慮的事項以及行業可以采取的措施來改善開源安全的整體狀態。

Synopsys 的數據顯示，平均軟件應用程序依賴于至少 500 個開源庫和組件，比兩年內的 298 個依賴項增加了77%。開源庫和組件占平均軟件應用程序代碼的 75% 以上，84% 的應用程序至少有一個漏洞，典型應用程序有 158 個。

在一次關于開源供應鏈安全的演講中 ，谷歌軟件工程師 Dan Lorenc 建議組織了解他們在使用什么——他承認這一步看似顯而易見但并不容易，尤其是當開發人員開始構建和發布工件并組合工件時進入其他文物。當漏洞被報告時，無論是無意的還是惡意的，不知道正在運行什么都會給您帶來麻煩。

“在添加依賴項時進行控制，”他說。對新依賴項的治理和持續審計，無論是內部的還是開源的，都是保護軟件的好方法。

這種控制可以擴展到構建您使用的組件，Lorenc 繼續說道，并指出這對于大多數組織來說也是艱難的一步。大多數情況下，二進制包的內容很難驗證。他補充說，它不需要全部或全部，但部分開源代碼正在構建和編譯它。知道您可以在必要時構建它是成功的一半，并表明您可以控制進入應用程序的代碼。

“開源軟件就是軟件，”Lorenc 說。“它充滿了錯誤；充滿了可以被利用的 CVE。” 雖然其中一些錯誤不會造成太大損害，但有些可能證明是有害的。

Lorenc 強調，組織應該制定處理零日漏洞和已知缺陷的計劃。零日漏洞是通常成為頭條新聞的浮華、令人興奮的錯誤，企業應該有一個緊急手冊來快速修補它們，但較舊的漏洞可能沒有引起他們應有的重視。在運行大量環境和系統的大型組織中，這些缺陷很容易被忽視。

“僅僅因為你忘記了它并不意味著攻擊者不會找到它，”他繼續道。“這些東西從外面很容易找到。”

他說，組織必須跟蹤他們正在運行的開源軟件并不斷更新它，并指出這通常被認為是“蹩腳”和“無聊”的工作，通常不會得到回報。Lorenc 建議對流程進行自動化、監控和跟蹤，以使其盡可能簡單。

“這是每個人都應該擔心的事情，”他談到已知的漏洞時說。

更廣泛地說，該行業可以更好地查找和修復未知錯誤。

“在您使用的項目中規范上游工作，”洛倫茨說。

“上游”是指原始軟件作者或維護者的方向。有一種常見的誤解，認為因為代碼在 GitHub 上并且經過了良好的審查，所以沒有錯誤。他說，這不是真的，“修復上游的錯誤可以幫助建立重要的橋梁并改善公共利益。”

開源漏洞披露：流程提示

她說，對于初學者來說，發現漏洞的人聯系漏洞管理團隊 (VMT) 應該不難。Bertucio 說，該團隊可能會決定使用一種常用工具或他們已經使用過的工具，但電子郵件非常好，并且可以很好地用作備份選項。安全策略應該是可訪問的，并且包括在錯誤報告中要解釋的內容以及響應預期。如果確認提交需要三天時間，請直接說出來。

從那里，問題得到確認和驗證。項目所有者應該詢問報告者他們是否愿意幫助開發補丁，他們是否愿意被計入 CVE，以及他們是否同意他們的披露時間表。

貝爾圖西奧說：“記者真的很喜歡看到事情盡快被披露和記名。” 雖然 90 天是標準，但重要的是要弄清楚什么對雙方都有效。

她補充說，到了披露的時候，安全建議應該是事實和簡短的——直截了當地說明人們需要知道什么以及如何緩解它。如果您想分享發現錯誤的故事及其工作原理，請將其寫在單獨的博客文章中。

Bertucio 說，隱藏漏洞的細節沒有意義，并指出“通過默默無聞的安全根本不是真正的安全。” 同樣，她說，為一個特定的開源項目擁有大量 CVE 也沒有錯。她補充說，這意味著你對披露缺陷和強化項目有強烈的反應。