21條最佳實踐，全面保障 GitHub 使用安全

• 2022 年 7 月 20 日
• 筆記

GitHub 是開發人員工作流程中不可或缺的一部分。無論你去哪個企業或開發團隊，GitHub 都以某種形式存在。它被超過8300萬開發人員，400萬個組織和託管超過2億個存儲庫使用。GitHub 是世界上最大的源程式碼託管服務平台。
​ 

GitHub 的使用便利與強大支援鞏固了其在市場中的主導地位。GitHub 用戶群體包羅萬象，從業餘小白到專業人士，從個人用戶到大型企業組織，都在使用 GitHub。
​ 
​ 

使用 GitHub 就無需考慮安全嗎？

GitHub 提供了許多工具和存儲庫設置防止數據泄露。但產生安全問題的根本原因往往在於疏於監管和安全知識匱乏。根據2019年發布的一項研究，在對公共 GitHub 存儲庫進行全面掃描後，該平台上共發現了超過57萬個敏感數據實例，例如 API 密鑰，私有密鑰，OAuth ID，AWS 訪問密鑰 ID 和各種訪問 token。這些暴露的主要風險包括但不限於經濟損失、隱私泄露、數據完整性受損以及不同程度的濫用。為提高程式碼倉庫的穩健性，和幫助開發團隊實施安全優先，我們將一同探討 GitHub 安全實踐。
​ 
​ 

為什麼需要加強 GitHub 安全實踐？

安全是所有軟體開發團隊都知道且需要落實的事情，但往往被放在了最後一步，而草率的做法和例行程式會降低基礎架構和數據完整性的成本。GitHub 的市場地位、社區支援和普及率遠超其他競爭對手，GitHub 也順理成章地成為程式碼版本控制和應用開發流程的最強參照。但根據北卡羅來納州立大學的一項研究，對超過一百萬個 GitHub 帳戶進行為期六個月的連續掃描顯示，包含用戶名、密碼、API 令牌、資料庫快照、加密密鑰和配置文件的文本字元串，是可以通過 GitHub 公開訪問的。其中包括超過 21萬 個 Google API 密鑰、超過 26000 個 AWS 訪問密鑰，以及總計超過 28000 個社交媒體訪問 token。
​ 

更令人擔憂的是，GitHub 上有542個 Stripe Standard API 密鑰公開可用。這些資訊足以讓惡意攻擊者直接訪問具有真實客戶詳細資訊的帳戶，一旦形成攻擊，將對企業的經濟、名譽、數據完整性造成毀滅性打擊。
​ 
 

GitHub 最佳安全實踐

1. 切勿在 GitHub 上存儲憑據和敏感數據

GitHub 的目的是託管程式碼存儲庫。除了在帳戶上設置的許可權之外，沒有其他安全方法可以確保您的密鑰、私鑰和敏感數據保留在受控且受保護的環境中。
​ 

Git code commit 保存了已添加和刪除內容的歷史記錄，從而使敏感數據永久保留在分支上。當分支合併和 Fork 時，潛在的數據或基礎架構安全風險可能會呈指數級增長。降低此風險的最簡單方法是，在提交到分支之前不要在程式碼中存儲憑據和敏感數據。可以在 CI/CD 流水線中使用 git-secreits 等工具。另一個方法是使用機密和身份管理工具，如 Vault 和 Keycloak。
​ 

2. 禁用 Fork

分叉（fork）是一種 git 技術，它允許開發人員在不涉及原始程式碼的情況下創建程式碼倉庫的副本。雖然 fork 非常適合實驗和沙箱，但它也可能導致無法跟蹤敏感數據和私有憑據的最終位置。程式碼倉庫最初可能是私有的，但 fork 可以快速將所有內容暴露到公共空間中。風險隨著每次分叉的發生呈指數級增加，通過暴露的敏感數據創建樹狀的安全漏洞鏈。為了防止這種情況發生，請禁用 Fork 存儲庫以幫助降低敏感數據進入程式碼的風險。
​ 

3. 禁用可見性更改

有時開發人員擁有的許可權和許可權比其角色範圍所需的許可權更多。對於沒有安全概念的開發人員來說，很容易不小心更改程式碼庫的可見性。如果程式碼存儲庫中存在敏感數據，有權訪問此更改可見性功能的人員越多，則潛在的風險就越高。要防止此類情況，可以將更改存儲庫可見性的功能設置為僅對組織所有者開放，或允許管理員特權成員使用許可權。
​ 

4. 驗證 GitHub 應用程式

現在的開發團隊有時由外部和第三方團隊組成，因此驗證 GitHub 應用程式涉及跟蹤第三方開發人員及其可訪問性級別。這也意味著，一旦他們離開項目，或者不再處理程式碼，就需要撤銷他們的訪問許可權。不同程度的可訪問性也應與他們在項目中的作用和參與程度掛鉤。比如，程式碼審核只需要提取程式碼的能力，而不需要創建提交。只有在具有相應許可權的人進行一系列檢查和程式碼驗證之後，才應進行拉取和合併請求。
​ 

5. 執行雙重認證

雙重身份驗證（2FA）現在是帳戶安全的行業標準。它也應當成為組織的標準安全要求，來防止通過不安全的帳戶泄漏程式碼。2FA 在登錄 GitHub 時增加了一層額外的安全保護，並且可以通過組織的設置在組織級彆強制執行。
​ 

當保存設置後，系統可能會提示有關未激活 2FA 的個人詳細資訊。這些資訊將從組織中刪除，並且只有在其帳戶上實施 2FA 後才能重新添加。可以在組織的審核日誌中查看已刪除的成員。
​ 

6. 實行單節點登陸（僅限 GitHub Enterprise）

SAML 單點登錄 （Single Sign-On, SSO）是一項僅適用於 GitHub Enterprise 的功能。藉助此功能，GitHub 上的組織可以通過顯示授予對特定資源（如單個程式碼倉庫、拉取請求和引發的問題）的訪問許可權來控制可訪問性。這允許組織對程式碼推送、拉取和審閱過程的不同部分的可訪問性進行分段。SAML SSO 還允許企業設置已批准的身份提供商。這意味著，企業可以限制用戶僅使用組織的帳戶登錄，而不是使用個人 GitHub 帳戶。這能夠有效緩解在向 GitHub 帳戶授予可訪問性時可能發生的潛在安全風險。
​ 

7. 限制訪問允許的 IP 地址

對於大型企業而言，跟蹤訪問用戶既困難又耗時。防止不必要的訪問的方法是限制通過IP地址的訪問。這意味著只有內部部署的成員或有權訪問公司維護的靜態 IP 遠程網路的成員才能進入企業的程式碼存儲庫和相關程式碼工作。要限制、管理和將 IP 地址列入白名單，在這裡可以以 CIDR 表示法配置特定 IP 地址或範圍的列表。
​ 

8. 嚴格管理外部參與者許可權

企業可能通過外包來加快項目的進展，或者引入外部專業知識來幫助填補團隊空白。外部成員的參與越多，相應的安全風險就越高。通過嚴格管理外部協作者和參與者，企業可以減少冗餘用戶數量及其對程式碼存儲庫的可訪問性。管理外部協作者的一種方法是將訪問許可權和許可權授予許可權集中給管理員。這樣做還可以降低由於 GitHub 的長期訪問成本。
​ 

9. 及時撤銷許可權

一個好的安全策略，需要考慮到團隊成員離開企業或項目時，對應的許可權進行怎樣的修改和調整。這包括撤銷不同類型帳戶的可訪問性的時間。有時團隊成員可能仍需要訪問程式碼，但不需要參與，因此撤銷更改許可權或將其切換為維護者角色可能更適合。此方法遵循最小特權原則，即授予執行特定任務所需的許可權。這樣做將確保每個有權訪問程式碼的人都只在其許可權範圍內工作。
​ 

10. 要求提交簽名

提交簽名是對程式碼合併進行加密簽名以進行驗證和可跟蹤性的過程。這對於程式碼審核跟蹤非常重要，因為惡意攻擊者偽裝成其他人並不難，只需在 git 配置中更改其用戶名和電子郵件地址並推送剝削性程式碼合併。可以將 Git 設置為通過 GPG（GNU Privacy Guard）對提交進行簽名，並在 git 配置中使用私有密鑰配置提交。完成此操作後，您可以將 GPG key 添加到 GitHub。在提交時，提交旁邊會顯示一個「已驗證」標誌。
​ 

11. 執行提交前程式碼審查

強制執行程式碼審查可以防止惡意程式碼正式合併到分支中。程式碼審查也是檢測程式碼異常的良好做法，能夠幫助企業避免導致未來的漏洞和長期的安全風險問題。GitHub 有一個拉取請求工具，允許授權的團隊成員在合併到基本分支之前討論和查看潛在的更改。發出拉取請求時，可以將工作負責人附加到拉取請求，來通知他們查看待處理的審核。
​ 

12. 添加 security.md 文件

security.md 文件是存儲庫的安全策略。此文件的目的是正式記錄與安全相關的流程和程式，包括漏洞報告、機密性要求、加密標準、令牌可訪問性、電子郵件地址的使用、HTTPS 要求、雲的使用、CDN、備份、身份驗證要求的過程以及數據完整性維護過程。 security.md 文件可以作為開發人員的寶貴指南。
​ 

13. 輪換 SSH 密鑰和個人訪問令牌

SSH (Secure Shell) 密鑰輪換可用作定期清除可能泄露的訪問密鑰。最好在安全要求策略中對所有 SSH 密鑰和個人訪問令牌設置到期日期。需要注意，雖然可以通過 GitHub 的 API 自動進行 SSH 密鑰輪換，但更改個人訪問令牌是手動過程，只能由用戶完成。要在 GitHub 上手動刪除 SSH 密鑰，在 「SSH and GPG keys」 下，可以找到當前所有訪問密鑰的列表。
​ 

14. 審核上傳到 GitHub 的所有程式碼

在應用程式構建過程中添加外部程式碼存儲庫很容易。除此之外，企業也會導入以往開發的軟體中的舊程式碼。導入舊程式碼的問題是其安全性無法保障。審核上傳到 GitHub 的所有程式碼的要求可能非常耗時，但有利於應用程式和軟體體系結構完整性的長期運行狀況。
​ 

15. 查看 Github 審核日誌中是否存在可疑活動

GitHub 有審核日誌工具，可讓企業的管理員快速查看團隊其他成員執行的操作。誰做了什麼的詳細資訊可以幫助標記可疑活動，並根據用戶的操作、操作的基於國家/地區的位置以及發生的日期和時間創建快速跟蹤配置文件。這三條資訊可以幫助管理員檢測異常並快速查明其來源。
​ 

16. 為易受攻擊的依賴關係啟用警報

隨著軟體項目規模的增長，依賴關係也變得更加錯綜複雜。而易受攻擊的依賴項（尤其是組織外部的第三方依賴項）的風險最大，因為它們的狀態以及對包或模組的更新方式缺乏控制。對於小型項目跟蹤難度可控，但隨著項目變得越來越大，這些依賴項很容易丟失。GitHub 具有檢測公共程式碼倉庫中易受攻擊的依賴項的功能，可以通過組織設置中的 「Security & analysis」 選項來啟用警報。
​ 

17. 在預提交時採用自動密鑰掃描

在許多人的印象里，如果源程式碼是私有的，那麼硬編碼憑據也應該保持安全。但是私有倉庫不提供相同級別的保護和加密的保管庫，也不提供對可訪問性輪換的相同程度的控制。複製和分發源程式碼也不難。在 CI/CD 流水線中，速度是傳輸程式碼的關鍵。這可能會導致意外提交敏感數據。自動機密掃描可以降低此類憑據意外暴露的風險。
​ 

18. 清除 GitHub 歷史記錄

GitHub 保存了每個已提交更改的日誌。但是，如果敏感數據進入程式碼存儲庫可能會帶來麻煩。清理 GitHub 歷史記錄的過程分為兩個步驟。首先使程式碼中的任何令牌和密鑰失效。第二步是使用 git filter-branch 命令清除和重寫存儲庫的歷史記錄。進一步向上游更改提交很重要，因為它會影響所有已經完成的後續提交。最好在運行 GitHub 歷史記錄之前合併並關閉所有拉取請求。
​ 

19. 啟用 git 分支保護

分支誤刪或 git squash 合併可能會導致數據丟失，或者通過引入漏洞在程式碼中造成數據泄露。分支保護是一項 GitHub 功能，允許保護特定的 git 分支免受未經授權的修改。這項功能的目的是為了確保協作者不會通過刪除和強制推送等過程對分支進行永久更改。其他分支保護方法包括要求籤名提交以確保真實性、可追溯性和拉取請求以防止未經授權的程式碼合併。
​ 

20. 將敏感文件添加到.gitignore

隨著項目規模和複雜性的增長，本地機正常工作所需的敏感數據也在增加。這些文件往往是唯一的，並且位於部署的伺服器上，不對公眾進行公開。在開發模式和本地主機中，軟體開發需要訪問這些令牌和密鑰。.gitignore將確保您的敏感數據不會意外合併並推送到 GitHub 存儲庫。
​ 

21. 使用 「Secrets Vault」 服務

隨著項目的增長，加密密鑰、令牌、密碼、證書和 API 密鑰等的數量也會增加。與其將這些資訊放在 GitHub 上，不如使用「密碼保險庫」服務。Vault 是一種用於保護高度敏感數據的工具，同時提供統一的訪問介面。除此之外，Vault 還提供更嚴格的訪問控制和審核跟蹤，使管理員能夠輕鬆檢測漏洞和違規行為。

​ 

參考鏈接：
Where the world builds software
//github.com/about
​ 
How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
//www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/