在我們之前的帖子中， 我們了解如何檢測和預防直接中毒 Pipeline 執行（D-PPE）。我們也了解如何使用以下方法檢測漏洞： Xygeni掃描儀以及一些保護機制。
中毒 Pipeline 執行 （PPE當攻擊者可以修改時，就會產生） pipeline 邏輯可以透過以下兩種方式實現：
- 透過修改 CI 設定檔（ pipeline）-> 直接個人防護裝備（D-PPE）
- 透過修改以下引用的檔案： pipeline （例如：從內部引用的腳本） pipeline 設定檔）-> 間接個人防護裝備（I-PPE）
在這篇文章中，我們將深入探討間接個人防護裝備（PPE）。但在此之前，作為我上一篇文章的補充，讓我們先來看看GitHub是如何管理執行的。 pipeline以及針對D-PPE的防護機制是什麼。
GitHub 如何保護執行流程？ pipeline來自 PR 嗎？
GitHub 在執行修改後的程式碼方面是如何運作的？ pipelines?
修改時間 pipeline可以來自推播或 Pull Requests （PR）。 作為一項重要的最佳實踐，強烈建議避免直接向受保護的分支「推送」數據，並使用其他方法。 Pull Requests 作為一種機制，在接受任何貢獻的程式碼之前強制進行一些審查。
Pull Requests 可能來自兩個不同的來源：
- 來自 叉子
- 來自 分館
來自 PR 的 叉子 可以來自 公眾 or 私立 倉庫。
由於我們正在處理個人防護裝備（中毒） Pipeline 執行），我們的重點不是「接受」PR，而是執行修改後的PR。 pipeline 在公關稿接受/批准過程中。 PPE攻擊的核心在於無意中執行了「惡意」修改後的程式。 pipeline.
簡而言之，中毒了 Pipeline 執行（PPE）產生於 攻擊者可以修改 pipeline 邏輯.
那裡有兩個 變種:
- 直接個人防護裝備 (D-PPE在D-PPE場景中， 攻擊者修改了 CI 配置文件 在他們有權存取的儲存庫中，可以透過兩種方式進行更改：一是將變更直接推送到儲存庫中不受保護的遠端分支；二是提交包含來自分支或派生分支的變更的 PR。 自CI以來 pipeline 執行過程由修改後的 CI 設定檔中的命令定義，攻擊者的惡意命令最終會在建置完成後在建置節點上執行。 pipeline 被觸發。
- 間接個人防護裝備 (個人防護裝備在某些情況下，即使擁有存取權限，對手也無法使用 D-PPE。 SCM 儲存庫（例如，如果 pipeline 配置為從同一儲存庫中單獨的受保護分支拉取 CI 設定檔）。 在這種情況下，與其毒害… pipeline 攻擊者本身會將惡意程式碼注入到被引用的檔案中。 pipeline （例如：從內部引用的腳本） pipeline 設定檔）
在這兩種情況下 GitHub 將執行修改後的操作。 pipeline 無需事先審查或批准.
來自分支的 PR 公眾 回購協議
GitHub 允許配置處理時的行為。 來自公共倉庫分支的 PR.
當 PR 來自分支時，GitHub 總是會在執行之前強制進行一定程度的「批准」。 pipeline 與公關活動相關這種程度的批准介於寬鬆批准和嚴格批准之間。
At 組織層級 （組織>>設定>>操作>>常規），您可以從幾個「審批」選項中進行選擇：
最嚴格的是最後一個（“需要獲得所有外部合作者的批准因為 GitHub 始終要求對來自外部合作者的 fork 的 PR 進行批准。
但即使在這種嚴格的情況下，也存在… 具有讀寫權限的協作者之間的區別.
- 當公關稿來自… 閱讀 用戶， 的執行 pipeline 已停止 直到變更獲得批准。如果批准通過，則修改後的版本生效。 pipeline 被執行。
- 當公關稿來自… 寫 用戶， 無需批准，修改後的 pipeline 總是執行！ ！
綜上所述，來自公共倉庫分支的 PR 缺乏有效的 PPE 保護。雖然對外部（讀取）使用者有一定的保護，但對內部（寫入）使用者則沒有任何保護。
關於什麼 來自私有倉庫分支的 PR?
來自分支的 PR 私立 回購協議
在這種情況下，GitHub 提供了一些有用的設定。
以上設定可透過以下方式配置： 組織 或 回購 水平。
日期 未選取任何選項GitHub 將 請求批准 以及 它不會執行修改後的程式碼。 pipeline這是最安全的配置！
这 最不安全的配置 當 “不"從 fork 運行工作流程 pull request已檢查在這種情況下，對於讀寫使用者來說都是如此，GitHub 會自動執行修改後的操作。 pipeline！ ！而且這種情況甚至可能更糟 更糟糕 如果 ”從 fork 向工作流程發送寫入令牌 pull requests“和”從 fork 向工作流程傳送金鑰和變數。 pull requests已檢查。除非有明確理由，否則請勿執行此操作！
如果“需要批准才能使用叉子 pull request 工作流程如果選取“”，上述情況會有所改善：GitHub 會要求批准，而不會執行修改。 pipeline 對於讀取用戶來說，它不會執行，但對於寫入用戶來說，它仍然會執行。
看到叉子了，那又怎樣呢？ 來自分支的 PR?
來自 PR 的 分館
為了保護這種情況，你必須依靠 分支保護規則.
在程式碼倉庫級別，您可以為任何分支建立分支保護規則。這些規則添加了一些… 對受保護分支的修改限制.
儘管您配置了一條規則“需要 pull request 合併之前“和”需要審批“ 修改後的 pipeline PR 建立後會自動執行「批准」僅適用於合併操作。
間接中毒呢？ Pipeline 執行
正如我們上面所看到的，D-PPE 可以透過使用來減輕 pull_request_target，但它 不適用於 I-PPE.
如果您使用 pull_request_target，預設檢出的將是基礎程式碼。但是，如果您想對貢獻的程式碼（PR 程式碼）進行一些驗證，則需要明確檢出 PR 程式碼。因此，如果 PR 程式碼修改了任何由…呼叫的 shell 腳本，則需要明確檢出 PR 程式碼。 pipeline，基礎（安全） pipeline 將呼叫「修改後的」shell腳本→間接個人防護裝備！ ！
解決這個問題比較複雜（沒有像 pull_request_target 那樣的萬能方法）。
我們的 pipeline 現在，由於我們使用了 pull_request_target，因此對 D-PPE 來說是安全的。但它仍然容易受到 I-PPE 的攻擊。
在我們的測試範例中，我們需要檢出 PR 程式碼才能進行構建，但測試是在構建生成的工件上執行的。
所以.. 為什麼不查看一下這兩個程式碼庫呢？
- 請查看 PR 程式碼，因為貢獻的程式碼正是我們想要建置和測試的。
- 檢出基礎程式碼以運行原始版本 pipeline 以及建置/測試腳本
這可以透過以下方式完成： 將這些程式碼庫檢出到不同的資料夾基礎程式碼可能檢出到根資料夾，而 PR 則檢出到另一個資料夾。在這種情況下，我們將從根資料夾對新資料夾中的程式碼執行建置和測試腳本。
這當然是一個簡單的解決方案！但是，為了方便學習，我想介紹一個非常有趣的變體（…）
GitHub上 工作流程運行 觸發事件
除了 pull_request_targetGitHub 也提供了另一個觸發事件： 工作流程運行本次活動允許 執行 pipeline 適應另一種 pipeline的執行.
工作流程運行 以及 pull_request_target 觸發器在某一方面是相似的：兩者都將在特權模式下執行，並且 儘管進行了公關修改，但基本情況 pipeline 將被處決！ ！
讓我們來看看我們目前的狀況 pipeline:
建構部分對 D-PPE 來說是安全的，但測試部分仍然容易受到 I-PPE 的影響。
这 pipeline 由於其本身對D-PPE是安全的，因此 pull_request_target 觸發。但由於呼叫了外部 shell 腳本，測試步驟仍然容易受到 I-PPE 攻擊。
避免使用個人防護裝備
上述目的 pipeline 目的是建立和測試貢獻的程式碼，確保個人防護裝備的安全。
所以.. 為什麼不拆分呢？ pipeline 分成兩份？ 一個用於構建，另一個用於測試..
- 該1st pipeline (建置 CI） 會 查看 PR 程式碼（以進行建置）進行建置並產生工件。
- 2nd pipeline (測試 CI） 會 檢出基礎程式碼（以避免修改 shell 腳本） 並對工件執行原始腳本。
- 為了同步測試 CI pipeline 在建置 CI 之後運行 pipeline我們將使用 工作流程運行 觸發。
這樣：
- pipeline 建置 CI is 安全至上 二者皆是 D-PPE （由於 pull_request_target) and 個人防護裝備 （因為它不再執行 shell 腳本）。
- pipeline 測試 CI 也 安全至上 二者皆是 D-PPE （由於 工作流程運行) and 個人防護裝備 （因為它會檢出基礎程式碼以取得原始 shell 腳本）
讓我們來看看兩者的程式碼。 pipeline根據這些修改…
1 pipeline （建置 CI）：
2 pipeline （測試 CI）：
哇……真是個好辦法！ ！但是……我們安全嗎？恐怕不安全😭
沒錯，我們引進了一個新的漏洞！ ！是哪個漏洞呢？這將是我們下一篇文章的主題🙂…敬請期待！ ！
注： 抱歉，我忍不住要說幾句🤐…你聽過… 神器中毒 ？ 😂
