GitHub 是開發人員工作流程中不可或缺的一部分。無論你去哪個企業或開發團隊，GitHub 都以某種形式存在。它被超過8300萬開發人員，400萬個組織和託管超過2億個儲存庫使用。GitHub 是世界上最大的原始碼託管服務平臺。
GitHub 的使用便利與強大支援鞏固了其在市場中的主導地位。GitHub 使用者群體包羅萬象，從業餘小白到專業人士，從個人使用者到大型企業組織，都在使用 GitHub。
GitHub 提供了許多工具和儲存庫設定防止資料洩露。但產生安全問題的根本原因往往在於疏於監管和安全知識匱乏。根據2019年釋出的一項研究，在對公共 GitHub 儲存庫進行全面掃描後，該平臺上共發現了超過57萬個敏感資料範例，例如 API 金鑰，私有金鑰，OAuth ID，AWS 存取金鑰 ID 和各種存取 token。這些暴露的主要風險包括但不限於經濟損失、隱私洩露、資料完整性受損以及不同程度的濫用。為提高程式碼倉庫的穩健性，和幫助開發團隊實施安全優先，我們將一同探討 GitHub 安全實踐。
安全是所有軟體開發團隊都知道且需要落實的事情，但往往被放在了最後一步，而草率的做法和例行程式會降低基礎架構和資料完整性的成本。GitHub 的市場地位、社群支援和普及率遠超其他競爭對手，GitHub 也順理成章地成為程式碼版本控制和應用開發流程的最強參照。但根據北卡羅來納州立大學的一項研究，對超過一百萬個 GitHub 帳戶進行為期六個月的連續掃描顯示，包含使用者名稱、密碼、API 令牌、資料庫快照、加密金鑰和組態檔的文字字串，是可以通過 GitHub 公開存取的。其中包括超過 21萬 個 Google API 金鑰、超過 26000 個 AWS 存取金鑰，以及總計超過 28000 個社交媒體存取 token。
更令人擔憂的是，GitHub 上有542個 Stripe Standard API 金鑰公開可用。這些資訊足以讓惡意攻擊者直接存取具有真實客戶詳細資訊的帳戶，一旦形成攻擊，將對企業的經濟、名譽、資料完整性造成毀滅性打擊。
GitHub 的目的是受控程式碼儲存庫。除了在帳戶上設定的許可權之外，沒有其他安全方法可以確保您的金鑰、私鑰和敏感資料保留在受控且受保護的環境中。
Git code commit 儲存了已新增和刪除內容的歷史記錄，從而使敏感資料永久保留在分支上。當分支合併和 Fork 時，潛在的資料或基礎架構安全風險可能會呈指數級增長。降低此風險的最簡單方法是，在提交到分支之前不要在程式碼中儲存憑據和敏感資料。可以在 CI/CD 流水線中使用 git-secreits 等工具。另一個方法是使用機密和身份管理工具，如 Vault 和 Keycloak。
分叉（fork）是一種 git 技術，它允許開發人員在不涉及原始程式碼的情況下建立程式碼倉庫的副本。雖然 fork 非常適合實驗和沙箱，但它也可能導致無法跟蹤敏感資料和私有憑據的最終位置。程式碼倉庫最初可能是私有的，但 fork 可以快速將所有內容暴露到公共空間中。風險隨著每次分叉的發生呈指數級增加，通過暴露的敏感資料建立樹狀的安全漏洞鏈。為了防止這種情況發生，請禁用 Fork 儲存庫以幫助降低敏感資料進入程式碼的風險。
有時開發人員擁有的許可權和許可權比其角色範圍所需的許可權更多。對於沒有安全概念的開發人員來說，很容易不小心更改程式碼庫的可見性。如果程式碼儲存庫中存在敏感資料，有權存取此更改可見性功能的人員越多，則潛在的風險就越高。要防止此類情況，可以將更改儲存庫可見性的功能設定為僅對組織所有者開放，或允許管理員特權成員使用許可權。
現在的開發團隊有時由外部和第三方團隊組成，因此驗證 GitHub 應用程式涉及跟蹤第三方開發人員及其可存取性級別。這也意味著，一旦他們離開專案，或者不再處理程式碼，就需要復原他們的存取許可權。不同程度的可存取性也應與他們在專案中的作用和參與程度掛鉤。比如，程式碼稽核只需要提取程式碼的能力，而不需要建立提交。只有在具有相應許可權的人進行一系列檢查和程式碼驗證之後，才應進行拉取和合並請求。
雙重身份驗證（2FA）現在是帳戶安全的行業標準。它也應當成為組織的標準安全要求，來防止通過不安全的帳戶洩漏程式碼。2FA 在登入 GitHub 時增加了一層額外的安全保護，並且可以通過組織的設定在組織級別強制執行。
當儲存設定後，系統可能會提示有關未啟用 2FA 的個人詳細資訊。這些資訊將從組織中刪除，並且只有在其帳戶上實施 2FA 後才能重新新增。可以在組織的稽核紀錄檔中檢視已刪除的成員。
SAML 單點登入 （Single Sign-On, SSO）是一項僅適用於 GitHub Enterprise 的功能。藉助此功能，GitHub 上的組織可以通過顯示授予對特定資源（如單個程式碼倉庫、拉取請求和引發的問題）的存取許可權來控制可存取性。這允許組織對程式碼推播、拉取和審閱過程的不同部分的可存取性進行分段。SAML SSO 還允許企業設定已批准的身份提供商。這意味著，企業可以限制使用者僅使用組織的帳戶登入，而不是使用個人 GitHub 帳戶。這能夠有效緩解在向 GitHub 帳戶授予可存取性時可能發生的潛在安全風險。
對於大型企業而言，跟蹤存取使用者既困難又耗時。防止不必要的存取的方法是限制通過IP地址的存取。這意味著只有內部部署的成員或有權存取公司維護的靜態 IP 遠端網路的成員才能進入企業的程式碼儲存庫和相關程式碼工作。要限制、管理和將 IP 地址列入白名單，在這裡可以以 CIDR 表示法設定特定 IP 地址或範圍的列表。
企業可能通過外包來加快專案的進展，或者引入外部專業知識來幫助填補團隊空白。外部成員的參與越多，相應的安全風險就越高。通過嚴格管理外部共同作業者和參與者，企業可以減少冗餘使用者數量及其對程式碼儲存庫的可存取性。管理外部共同作業者的一種方法是將存取許可權和許可權授予許可權集中給管理員。這樣做還可以降低由於 GitHub 的長期存取成本。
一個好的安全策略，需要考慮到團隊成員離開企業或專案時，對應的許可權進行怎樣的修改和調整。這包括復原不同型別帳戶的可存取性的時間。有時團隊成員可能仍需要存取程式碼，但不需要參與，因此復原更改許可權或將其切換為維護者角色可能更適合。此方法遵循最小特權原則，即授予執行特定任務所需的許可權。這樣做將確保每個有權存取程式碼的人都只在其許可權範圍內工作。
提交簽名是對程式碼合併進行加密簽名以進行驗證和可跟蹤性的過程。這對於程式碼稽核跟蹤非常重要，因為惡意攻擊者偽裝成其他人並不難，只需在 git 設定中更改其使用者名稱和電子郵件地址並推播剝削性程式碼合併。可以將 Git 設定為通過 GPG（GNU Privacy Guard）對提交進行簽名，並在 git 設定中使用私有金鑰設定提交。完成此操作後，您可以將 GPG key 新增到 GitHub。在提交時，提交旁邊會顯示一個「已驗證」標誌。
強制執行程式碼審查可以防止惡意程式碼正式合併到分支中。程式碼審查也是檢測程式碼異常的良好做法，能夠幫助企業避免導致未來的漏洞和長期的安全風險問題。GitHub 有一個拉取請求工具，允許授權的團隊成員在合併到基本分支之前討論和檢視潛在的更改。發出拉取請求時，可以將工作負責人附加到拉取請求，來通知他們檢視待處理的稽核。
security.md 檔案security.md 檔案是儲存庫的安全策略。此檔案的目的是正式記錄與安全相關的流程和程式，包括漏洞報告、機密性要求、加密標準、令牌可存取性、電子郵件地址的使用、HTTPS 要求、雲的使用、CDN、備份、身份驗證要求的過程以及資料完整性維護過程。 security.md 檔案可以作為開發人員的寶貴指南。
SSH (Secure Shell) 金鑰輪換可用作定期清除可能洩露的存取金鑰。最好在安全要求策略中對所有 SSH 金鑰和個人存取令牌設定到期日期。需要注意，雖然可以通過 GitHub 的 API 自動進行 SSH 金鑰輪換，但更改個人存取令牌是手動過程，只能由使用者完成。要在 GitHub 上手動刪除 SSH 金鑰，在 「SSH and GPG keys」 下，可以找到當前所有存取金鑰的列表。
在應用程式構建過程中新增外部程式碼儲存庫很容易。除此之外，企業也會匯入以往開發的軟體中的舊程式碼。匯入舊程式碼的問題是其安全性無法保障。稽核上傳到 GitHub 的所有程式碼的要求可能非常耗時，但有利於應用程式和軟體體系結構完整性的長期執行狀況。
GitHub 有稽核紀錄檔工具，可讓企業的管理員快速檢視團隊其他成員執行的操作。誰做了什麼的詳細資訊可以幫助標記可疑活動，並根據使用者的操作、操作的基於國家/地區的位置以及發生的日期和時間建立快速跟蹤組態檔。這三條資訊可以幫助管理員檢測異常並快速查明其來源。
隨著軟體專案規模的增長，依賴關係也變得更加錯綜複雜。而易受攻擊的依賴項（尤其是組織外部的第三方依賴項）的風險最大，因為它們的狀態以及對包或模組的更新方式缺乏控制。對於小型專案跟蹤難度可控，但隨著專案變得越來越大，這些依賴項很容易丟失。GitHub 具有檢測公共程式碼倉庫中易受攻擊的依賴項的功能，可以通過組織設定中的 「Security & analysis」 選項來啟用警報。
在許多人的印象裡，如果原始碼是私有的，那麼寫死憑據也應該保持安全。但是私有倉庫不提供相同級別的保護和加密的保管庫，也不提供對可存取性輪換的相同程度的控制。複製和分發原始碼也不難。在 CI/CD 流水線中，速度是傳輸程式碼的關鍵。這可能會導致意外提交敏感資料。自動機密掃描可以降低此類憑據意外暴露的風險。
GitHub 儲存了每個已提交更改的紀錄檔。但是，如果敏感資料進入程式碼儲存庫可能會帶來麻煩。清理 GitHub 歷史記錄的過程分為兩個步驟。首先使程式碼中的任何令牌和金鑰失效。第二步是使用 git filter-branch 命令清除和重寫儲存庫的歷史記錄。進一步向上游更改提交很重要，因為它會影響所有已經完成的後續提交。最好在執行 GitHub 歷史記錄之前合併並關閉所有拉取請求。
分支誤刪或 git squash 合併可能會導致資料丟失，或者通過引入漏洞在程式碼中造成資料洩露。分支保護是一項 GitHub 功能，允許保護特定的 git 分支免受未經授權的修改。這項功能的目的是為了確保共同作業者不會通過刪除和強制推播等過程對分支進行永久更改。其他分支保護方法包括要求籤名提交以確保真實性、可追溯性和拉取請求以防止未經授權的程式碼合併。
.gitignore隨著專案規模和複雜性的增長，本地機正常工作所需的敏感資料也在增加。這些檔案往往是唯一的，並且位於部署的伺服器上，不對公眾進行公開。在開發模式和本地主機中，軟體開發需要存取這些令牌和金鑰。.gitignore將確保您的敏感資料不會意外合併並推播到 GitHub 儲存庫。
隨著專案的增長，加密金鑰、令牌、密碼、證書和 API 金鑰等的數量也會增加。與其將這些資訊放在 GitHub 上，不如使用「密碼保險庫」服務。Vault 是一種用於保護高度敏感資料的工具，同時提供統一的存取介面。除此之外，Vault 還提供更嚴格的存取控制和稽核跟蹤，使管理員能夠輕鬆檢測漏洞和違規行為。
參考連結：
Where the world builds software
https://github.com/about
How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/