【51CTO.com快譯】GitHub可謂世界上最大、最受歡迎的社交開發平臺。根據其《2019年Octoverse的態勢報告》(請參見-- https://octoverse.github.com/)：GitHub當時擁有超過4000萬名用戶，而且該社區每天都在不斷地壯大。

由于各類開發人員頻繁地使用由該平臺所提供的開源代碼去構建軟件，那么大量可以被重復使用的代碼往往會增加漏洞從一個依賴項或存儲庫，遷移到另一個依賴項或存儲庫的潛在風險。可見，基于此類高度互連性，Github平臺及內容的安全性顯得尤為重要。每個貢獻者和用戶都應當專注于創建安全可靠的開發環境。

下面，我將和您討論針對代碼安全防護的八項實踐。GitHub用戶可以根據實際情況進行對標和實現。

加強訪問控制

實施適當的訪問控制是增強安全性的最佳實踐之一。這不僅僅體現在GitHub上，對于任何需要保障代碼安全性的環境皆是如此。

目前，GitHub提供了多種選項，讓用戶減少不當的泄漏風險。其中，我們最常用的當屬最小特權(least privilege)模型。該模型僅向用戶授予基本必要的權限。如下是我們在使用過程中，需要遵循的各種基本訪問控制準則：

• 限制存儲庫的創建，以防止用戶在公共存儲庫中公開其組織的相關信息。
• 啟用分支保護和狀態檢查，以確保用戶可以合并各種提交或安全地操作分支。
• 禁用或有條件地允許fork私有存儲庫，以確保用戶不會暴露或向未經授權方共享所在組織的代碼。
• 撤消那些不再屬于貢獻者的、所有非活動用戶的訪問權限。
• 定期檢查對GitHub項目的訪問權限。
• 確保用戶不會共享GitHub帳戶或密碼。
• 確保每個貢獻者在其帳戶上啟用雙因素身份驗證。
• 定期更換個人訪問的令牌和SSH密鑰。

永遠不要在您的GitHub文件中存儲密鑰

您是否注意到：代碼、配置文件或提交的消息，都可能成為被攻擊的網關，向其他GitHub存儲庫泄露機密信息。

為了防止敏感數據被添加到存儲庫中，請考慮使用諸如git-secrets(請參見--https://github.com/awslabs/git-secrets)或vault(請參見--https://www.vaultproject.io/)之類的密鑰管理工具。這些工具會掃描您的代碼庫，并在代碼或配置文件中檢測到敏感信息時，立即終止構建。

您也許會在意識到GitHub存儲庫里有敏感信息泄漏時，立即將其刪除。但是，GitHub會在您的存儲庫中保留所有提交的歷史記錄。因此僅刪除數據是遠遠不夠的，您需要從GitHub存儲庫的歷史記錄中清除掉相應的文件(請參見--https://help.github.com/articles/removing-sensitive-data-from-a-repository/)。

同時，為了提高安全性，您也需要將那些已經泄露出去的密鑰(包括：密碼和令牌)，及時設置為失效狀態。

為脆弱的依賴項啟用安全警報

隨著從事的項目越來越多，GitHub用戶會發現他們越來越難管理好紛繁復雜的依賴關系。不過幸運的是，GitHub為您提供了自動化安全警報的機制，可以幫助您檢測到存儲庫中脆弱的依賴項。

Github安全實踐

(源自https://github.blog/2019-12-11-behind-the-scenes-github-vulnerability-alerts/)

如上圖所述，GitHub安全警報源自(美國)國家漏洞數據庫(NVD，https://nvd.nist.gov/)，GitHub安全公告(GitHub Security Advisories，https://github.com/advisories)和WhiteSource漏洞數據庫。它們提供了200多種語言的漏洞數據。通過GitHub上提供的實時安全警報服務，用戶可以更加安全地使用各種開源庫。

驗證GitHub應用程序

GitHub的市場里包含了豐富的由第三方開發人員和組織所編寫的應用程序。我們往往需要仔細驗證那些被添加到GitHub存儲庫中的每個應用程序。也就是說，在安裝GitHub應用程序時，請注意遵循以下規范：

• 強制執行最小特權原則。切勿向應用程序授予超出其要求的訪問權限。
• 對應用請求的訪問權限始終保持謹慎的態度，要及時考慮到授予某項訪問權限可能帶來的損害。
• 在給GitHub的訪問主體授權時，請進行背景檢查，以確保應用程序背后的組織或開發人員合法且可信。
• 需要驗證應用程序的安全狀態是否可靠，以避免整體的安全態勢遭受破壞。

根據木桶原理，應用程序的安全性取決于其最薄弱的鏈接，而GitHub存儲庫也是如此。因此，在授予應用程序對存儲庫的恰當訪問權限之前，請務必驗證它的來源，以確保其真實可信。

審核所有導入GitHub的代碼

開發人員往往需要將外部代碼導入GitHub中。那么，請在每次導入項目時，務必考慮對源代碼執行完整性審核。這看上去非常繁瑣，甚至對于一些較小的項目來說有些吹毛求疵，但是這是一種非常好的安全實踐，可以在源頭上避免向存儲庫中引入潛在的安全漏洞。

向GitHub導入代碼可能帶來的另一個風險是：代碼中可能包含諸如密碼之類的敏感信息。而如果將其存儲到GitHub文件中，那么就會提高應用的整體風險值。可見，我們在將代碼推送到GitHub之前，必須進行安全態勢的審核與評估，以便發現其中的安全風險點。

值得一提的是：在被導入的過程中，代碼實際上是從一種封閉的環境，轉換到了一種可以被相互調用和影響的環境中。因此，環境的變化也會促使我們重新進行安全關系和執行層面上的審查。

對存儲庫使用自動靜態源代碼分析

您可以使用多種第三方工具，來分析存儲庫中的安全漏洞。其中最為常用的一種工具是WhiteSource Bolt(請參見--https://bolt.whitesourcesoftware.com/)，該工具可以在GitHub市場中免費獲取到。

WhiteSource Bolt為GitHub檢測到的漏洞

WhiteSource Bolt通過掃描您的存儲庫，以檢測出所有開源組件中的漏洞。與此同時，它還能提供詳細的漏洞信息，以及對應的修復建議。

當然，您也可以使用其他開源的分析工具，對目標GitHub存儲庫開展自動化的，源代碼級的安全分析。

根據組織的需求，選擇合適的GitHub產品

大多數組織，特別是政府部門和金融機構，都會通過規定來限制其開發團隊使用GitHub之類的社交開發平臺，以防止其他方通過平臺訪問到本組織的源代碼。

如果貴組織確有此項嚴格的規定，那么請考慮使用GitHub Enterprise(請參見--https://enterprise.github.com/home)。它允許用戶在內部托管的GitHub存儲庫環境中執行各項操作。此舉既允許內部開發團隊訪問到手頭所有的項目，又不必擔心被GitHub上的其他用戶所“剽竊”到，因此，企業軟件開發包會得到更加安全的保護。

為您的項目采用全面的安全策略

常言道，安全是一項集體的責任。如果您是一名企業安全經理，那么當務之急就是實施那些能夠讓所有利益相關者都應遵循的安全策略。理想情況下，您應該在計劃階段，就將安全和開發團隊召集在一起，以確保他們能夠通力協作。這樣，在項目的開發過程中，實施安全控制將會變得更加容易。而隨著人員意識的提高，各種所謂在存儲庫中直接存儲密碼的行為，也就不會頻繁出現。

此外，通過清晰的記錄，團隊成員還可以及時報告，并協同解決存儲庫中暴露的各項安全問題。

總結

每位開發人員都應當專注于保護自己的代碼，以及在GitHub中的安全問題。上述提供的各項安全實踐，值得您和您的團隊在開發過程中，持續嘗試與踐行。

您可以在使用GitHub原生安全服務的同時，實施適當的身份驗證和訪問控制，并通過集成其他工具的方式，來增強開發工作流程中的安全態勢。當然，您也可以通過查看GitHub業務安全性(請參見--https://github.com/business/security)和GitHub安全性文檔(請參見--https://help.github.com/articles/github-security/)，來獲取有關如何保護GitHub上程序代碼的更多信息。

原標題：Stay Safe on GitHub: Security Practices to Follow ，作者：Dickson Mwendia

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】