從工具到實踐:如何在GitHub上保障開源專案安全?

SEAL安全發表於2022-12-27

1998年,Christine Peterson創造了 “開源軟體”這個詞。她解釋道:“這是刻意為之,為了讓其他人更容易理解這個領域”。同年,O’Reilly組織了首屆“開源峰會”。

開源軟體受到更多人青睞原因在於,使用者對軟體擁有更多的控制權因為他們可以檢查程式碼。對於長期專案來說,開源軟體被認為是穩定的,因為這些專案遵循開放的標準,即便維護者停止工作,也不會憑空消失。活躍的開發者社群十分重要。

比起閉源軟體,開源需要更多地考慮安全問題,因為任何人都可以檢視並修改程式碼。貢獻者可以發現錯誤並提交一個PR對程式碼進行變更。與此同時,這也伴隨著一系列的安全問題。

什麼是軟體供應鏈攻擊?

當有人利用外部供應商或能夠訪問你的企業的資料和系統的第三方元件來滲透你的數字基礎設施時,就會發生軟體供應鏈攻擊。供應鏈攻擊的型別多種多樣,本文將聚焦於開源供應鏈。

任何人都可以透過開源舉措為專案的開發做出貢獻。利用這個切入點,駭客可以將漏洞編入開源專案中,當企業將該專案引入其軟體中時也引入了新的威脅,而且往往是在不知情的情況下,透過遍歷依賴或間接依賴引入。

Web 應用安全的重要性

Web 應用安全是一個概念,它涵蓋了一系列嵌入Web應用程式的安全管控,以保護其資產免受潛在的惡意行為的影響。它涉及安全開發實踐,在整個軟體開發生命週期(SDLC)中實施安全措施,以發現專案及其配置中的安全漏洞。

好訊息是你可以透過使用不同的應用程式及 action 在 GitHub 內實現安全保護,不管是一個簡單的demo專案,還是大型開源專案。基於此,開源專案可以擁有與閉源軟體相同的安全水平。

Section 1:GitHub Marketplace 及 GitGuardian 應用

什麼是 GitHub Marketplace?

2016年的GitHub Universe上,首次引入GitHub Marketplace。它是一個開發者可以找到整合外掛並將其落實到工作流程中的地方。

如何利用安全工具建立基礎流水線並實現防護?

你可以利用GitHub Marketplace中的安全應用和action來保護你的流水線每個開發階段的安全。

一個基礎的流水線包括:

  • 軟體成分分析工具,專注於識別程式碼庫中的開放原始碼,以便維護者和貢獻者能夠管理它們的安全和許可證合規問題

  • 防止金鑰洩露的工具

  • 程式碼分析工具,它是一種在程式執行之前透過檢查原始碼進行除錯的方法,一般根據一組編碼規則分許一組程式碼

如何為你的專案選擇相關應用?你需要考慮些什麼?

選擇工具、應用或是action 主要取決於你的專案或團隊的工作流程。你們使用的是什麼型別的技術棧?你們是部署到Docker還是使用K8S?在你們的流水線中有多少個步驟?你能在每個步驟都實施防護嗎?

然後,你將會找到許多滿足你需求的工具和應用。而對於開放原始碼軟體的維護者來說,好訊息是這些應用程式通常對公開的程式碼庫或開源軟體專案是免費的。

你可以在一個階段中採用2個工具,比如 Synk 和 Mend 掃描你的依賴項。這兩種工具在覆蓋率方面都會有其優點和缺點,並會幫助你更好地瞭解你的專案的依賴項。如果你認為一個工具比另一個好,你仍然可以刪除你不需要的那個。

讓我們來看看OWASP Zap基線掃描這個GitHub action,它會掃描目標URL的漏洞,並在你提交PR時將其反饋給你的專案。

當你打算在專案中採用一個action或一個應用時,你應該在專案頁上看到各種資訊——GitHub是否驗證該action?上圖中顯示為已驗證,你可以在右側看到一個藍色的小勾。有多少貢獻者在為這個專案工作?該專案獲得了多少顆星?有多少issue和PR?

再導航到 GitHub 倉庫,看看維護者和貢獻者是如何積極推動這個專案的。它的文件是否完善?他們是否提供了基本的使用範例?(比如一個簡單的YAML檔案)是否容易實現?是否能與你專案的程式語言相容?

接下來,我們來看看 GitGuardian 的實際用例。你可以直接在 Marketplace 中搜尋到它。

點選產品頁,你將獲得更多資訊。作為專案的維護者,你將會用 OWASP Action 檢查我們前面提到的要求是否達標。我們可以看到 GitHub 是否驗證了該應用、應用安裝數量以及更多關於該組織的其他資訊。

劃到頁面底部,你將看到價格及安裝資訊。GitGuardian為公開的程式碼庫提供免費的監控。選擇你想要安裝的賬號,並點選“Install it for free”。

你可以在所有程式碼庫上都安裝 GitGuardian 或者選擇其中幾個。你可以為需要安全防護的每個階段重複這一過程。

Section 2:管理開源專案

當貢獻者提交PR時,它將觸發流水線中整合的所有應用和action。理想狀況下,就GitGuardian而言,你希望憑證不被推送到原始碼中,並且在貢獻者提交PR之前停止這一行為。你可以在你的CLI上採用 GitGuardian Shield(ggsheild),並與預提交的 git hook整合以增強防護,確保憑證沒有被推送到原始碼中。

如果沒有設定 ggshield,在程式碼庫上推送金鑰的貢獻者會在提交PR時收到告警。下圖虛擬PR提交的過程中,你可以看到一些工具被觸發。

你可以讓其中一些工具在主幹分支上是必須觸發的。要做到這一點,需要進入專案設定,在【Code and automation】中點選【Branches】。在這裡,你可以新增分支保護規則,要求在合併PR前必須透過狀態檢查。

如何從ChatOps中獲取價值?

ChatOps 是一個協作模型,將人、工具、流程和自動化連線到一個透明的工作流程中。使用Slack進行討論,併為特定的工具設定專門的頻道,這將有助於你瞭解專案中發生的事情。監控和設定告警是重要的一環,可以幫助開發人員獲得正確的資訊。

GitHub 專案:如何利用皮膚追蹤安全任務

在開發開源專案時,你可以利用GitHub projects來列出你為某一特定功能所要做的所有任務。你可以建立標籤和epics(milestones)來跟蹤進度或用於提出問題。還可以建立一個安全標籤來追蹤你專案中的漏洞。

你可以使用自動化專案或皮膚,其中的卡片會根據PR的狀態相應地移動。這個方式可以很好地展示功能開發進度以及你可能需要幫助的地方。

在 README 檔案中展示專案的健康狀態

如果你想為你的專案吸引更多的貢獻者,不要忘記使用應用及action工作流程提供的標籤或tag來展示專案的健康狀態,並將其新增到專案的README檔案頂部。你透過GitHub文件瞭解更多徽章設定:

https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge

Section 3:安全加固開源專案

除了在流水線各環節新增安全防護外,你還可以透過採用以下最佳實踐加固開源專案:

  • 採用最小許可權: 在成員許可權部分將基本許可權設定為無許可權,這樣成員只能克隆和提取公共程式碼庫。如果要給貢獻者更多的許可權,維護者需要把他們加入團隊或讓他們成為單個程式碼庫的協作者。建立團隊、新增使用者,並將他們分配到具有特定許可權的特定程式碼庫中。

  • 讓所有維護者和貢獻者都必須使用2FA。 到2023年底,GitHub將要求所有貢獻程式碼的使用者啟用一種或多種形式的雙因素認證。

  • 保護主分支: 如上所述,一定要保護主分支,以免被維護者意外刪除。

  • 啟用提醒和告警: 更新email地址以保證你能收到來自專案的提醒資訊

  • 新增正確的許可證: OSS許可證可以保護貢獻者和使用者。如果你不確定應該選擇哪個許可證,可以檢視這篇文章進行簡單的入門,並且確保在你的程式碼庫中有 LICENSE.md 或 LICENSE.txt 檔案。

  • 審查應用程式、工具和Webhooks的列表: 如果你在流水線中的一個步驟中使用了多個應用程式、工具或webhooks,請review 它們是否仍然適用,並刪除任何陳舊過時的或未使用的元件。

  • 如果你依賴 GitHub Actions 來構建、測試和部署你的專案,一定要檢查你的工作流程配置。訪問下方連結可以檢視 GitHub Actions 安全最佳實踐:

https://blog.gitguardian.com/github-actions-security-cheat-sheet/

總 結

開源元件可以成為大規模網路攻擊的一個載體。去年我們已經看到了Apache Log4j 的漏洞,這是一個開源的Java包,用於支援許多Java應用程式的活動記錄。雖然不是所有用Java編寫的軟體都有漏洞,但受影響的軟體包被開發人員廣泛使用,有許多應用程式和服務都使用這個庫。大型科技公司,如微軟、VMWare、亞馬遜、IBM等都受到影響。

使用不同的工具和防護在整個流水線中擁有可見性對於減少攻擊面至關重要,在本文中我們已經看到藉助 GitHub Marketplace 的應用和Action可以幫助達成這一目標。軟體供應鏈安全管理平臺SEAL 也可以幫助使用者獲取專案的全域性安全可見性,目前已開放免費試用:seal.io/trial。

作為維護者和貢獻者,可以先建立一個小型流水線,並嘗試試用其中一些工具,為每個貢獻者安全加固GitHub專案。

不停地實踐是保證安全的關鍵一環,但更重要的是,不要在GitHub上push你的金鑰!

相關文章