如何維護安全 GitHub 存放庫

已完成

在這裡,我們將討論 GitHub 存放庫系統管理員可使用的一些基本安全性工具與技術。

注意

下列內容不涵蓋撰寫安全程式碼的基本概念,而是 GitHub 存放庫內可用的重要安全性考量、工具和功能。

安全開發策略的重要性

應用程式安全性很重要。 新聞媒體經常報導一些公司的系統遭入侵,以及私人公司和客戶資料遭竊的新聞。

那麼,在規劃安全開發策略時,需要考慮什麼問題? 顯然,我們需要保護資訊免於被揭露給不應該存取該資訊的人,但更重要的是,我們需要確保資訊只在適當時才會進行改變或銷毀。

務必正確驗證誰在存取資料,而且確實有權這麼做。 透過歷史或封存資料或記錄檔,我們必須能在發生問題時找出證據。

建置及部署安全的應用程式有許多層面。 以下是三個要考慮的事項:

  • 有一個常識性問題:許多開發人員和其他員工都認為自己了解安全性,但事實上他們並不了解。 網路安全性是持續演進的專業領域。 進行中的教育和訓練計畫是不可或缺的。

  • 必須正確且安全地建立程式碼:務必正確建立程式碼,並安全實作所需的功能。 我們也需確保功能在設計時就考慮到安全性。

  • 應用程式必須遵守規則和規定:我們需要確保程式碼符合必要的規則和規定。 我們必須在建立程式碼時測試合規性,然後定期進行重新測試,即使在部署之後也一樣。

每個步驟的安全性

GitHub 盾牌圖片,底下有 security 字樣。

安全性並不是您可以之後再新增至應用程式或系統的東西。 軟體開發生命週期的每個階段都必須存在安全開發。 這個概念對關鍵應用程式,以及處理敏感性或高度機密資訊的應用程式而言,更為重要。

實際上,為了讓小組為其開發的項目負責,需要在開發生命週期中左移或提早完成流程。 將部署後期的步驟提前一步,就會產生較少的錯誤,並提高開發人員的速度。

應用程式安全性概念對於過去的開發人員而言並非重點。 除了教育和訓練問題以外,這是因為其組織著重於快速功能開發。

不過,隨著 DevOps 實務的引進,安全性測試更容易整合到管線中。 安全性測試應該為日常傳遞程序的一部分,而不是由安全專家執行的工作。

整體而言,將重新作業的時間納入考量後,將安全性新增至開發生命週期稍早的 DevOps 實務,可讓開發小組提早發現問題。 提早發現問題實際上可以縮短開發高品質軟體所需的時間。

左移是一種程序變更,但並不是單一控制項或特定工具。 其主要是讓所有安全性更加以開發人員為中心,並提供開發人員所在之處的安全性意見反應。

安全性索引標籤功能

GitHub 提供安全性功能,可協助在存放庫中和跨組織保護資料。 若要找出安全性索引標籤:

  1. 在 GitHub.com 上,前往存放庫的主頁面。

  2. 在存放庫的名稱下,選取 [安全性]

顯示 GitHub 中 [安全性] 索引標籤位置的螢幕擷取畫面。

您可以從 [安全性] 索引標籤,將功能新增至 GitHub 工作流程,以協助避免存放庫和程式碼基底中的弱點。 這些功能包括:

  • 安全性原則 可讓您指定如何透過將 SECURITY.md 檔案新增至存放庫,以報告專案中的安全性弱點。
  • Dependabot 警示 會在 GitHub 偵測到您的存放庫使用易受攻擊的相依性或惡意程式碼時,通知您。
  • 您可以用來私下討論、修正及發佈存放庫中安全性弱點的相關資訊的 安全性諮詢
  • 程式碼掃描 可協助您尋找、分級及修正程式碼中的弱點和錯誤。

如需詳細資訊,請參閱 GitHub 安全性功能

注意

惡意程式碼的 Dependabot 警示諮詢目前處於搶鮮版 (Beta) 狀態,且可能會變更。 只有 GitHub 已檢閱的諮詢才會觸發 Dependabot 警示。

接著,我們會探索這些功能的一部分,並學習在軟體開發生命週期的所有階段分配安全性和作業責任的方式。

透過 SECURITY.md 來傳達安全性原則

GitHub 的社群權益很重要,但其中也有潛在風險。 事實上,任何人都可以公開地提出錯誤 (Bug) 修正附帶了一定的責任。 最重要的是資訊揭露的責任,可能導致安全性漏洞的底層錯誤 (Bug) 在可修正之前就已遭利用。 想要通報或解決安全性問題的開發人員會在存放庫的根目錄中尋找 SECURITY.md 檔案,以負責任地揭露其顧慮。 在此檔案中提供指導方針,最終會加快這些重大問題的解決。

若要深入了解 SECURITY.md,請參閱將安全性原則新增至存放庫

GitHub 安全性建議

GitHub 安全性建議可讓存放庫維護人員私下討論並修正專案中的安全性弱點。 存放庫維護人員在合作建立修正之後,即可發佈安全性建議,向專案社群公布安全性弱點。 存放庫維護人員發佈安全性建議,讓社群更輕鬆更新套件相依性,並研究安全弱點的影響。 GitHub 會將已發佈的諮詢儲存在 [常見弱點與漏洞 (CVE)] 清單中。 此清單用於自動通知受影響的存放庫,這些存放庫使用了已列出弱點的軟體。 如需詳細資訊,請參閱 關於存放庫安全性諮詢

使用 .gitignore 將敏感性檔案排除在存放庫之外

開發人員很容易忽略認可中包含的檔案。 有時候這些忽略的檔案是良性的,例如中繼組建檔案。 不過,總是存在著有人不小心認可敏感性資料的風險。 例如,有人可能會認可惡意執行者可能會使用的 API 金鑰或私人設定資料。 協助避免這類風險的一種技術,就是建置並維護 .gitignore 檔案。 這些檔案會指示用戶端工具 (例如 git 命令列公用程式) 在彙總認可的檔案時,忽略路徑和模式。

下列範例說明可忽略檔案的一些常見使用案例:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

您的存放庫可能包含多個 .gitignore 檔案。 設定會繼承自父目錄,而針對新 .gitignore 檔案的資料夾和子資料夾,其中覆寫欄位的優先順序高於其父代設定。 大部分的工作都是盡可能維護根 .gitignore 檔案,然而,如果專案有特定需求,因此獨立於父代進行維護會比較容易 (例如應該忽略的檔案),則將 .gitignore 檔案新增至專案目錄中會很有用。

若要深入了解 .gitignore,請參閱忽略檔案。 另請參閱 gitignore 存放庫 \(英文\) 中針對各種平台提供的入門 .gitignore 檔案集合。

從存放庫移除敏感性資料

雖然 .gitignore 檔案有助於協助參與者避免認可敏感性資料,但這只是強烈建議的做法。 如果開發人員的動機強烈,仍然可以採用因應措施來新增檔案,有時檔案可能會因為不符合 .gitignore 檔案設定而通過。 專案參與者應一律注意認可是否包含不應包含在存放庫或其歷程記錄中的資料。

重要

對於在任何時候認可至 GitHub 的任何資料,您都應該假設已遭入侵。 光是覆寫認可並不足以確保未來將無法存取該資料。 如需將敏感性資料從 GitHub 移除的完整指南,請參閱將敏感性資料從存放庫移除

分支保護規則

您可以建立分支保護規則,以強制執行一或多個分支的特定工作流程。 例如,您可以要求核准檢閱,或針對合併至受保護分支的所有提取要求傳遞狀態檢查。

保護分支的工作流程可用來:

  • 執行組建以確認可以建置程式代碼變更
  • 執行 Linter,檢查有無錯字及是否符合內部的程式碼撰寫慣例
  • 執行自動化測試,檢查程式碼有無任何行為變更
  • 依此類推

新增 CODEOWNERS 檔案

只要將 CODEOWNERS 檔案新增至存放庫,即可將個別小組成員或整個小組指派為程式碼擁有者,以分配到存放庫中的路徑。 然後,在設定給這些程式碼擁有者的路徑中,對於其中檔案的任何變更,擁有者需要檢閱提取要求。

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

您可以在存放庫的根目錄或在 docs.github 資料夾中建立 CODEOWNERS 檔案。