GitHub 近期針對其旗下 npm 套件管理系統與 GitHub Actions 自動化工作流，整合並實施了一系列安全性預設值變更。這些措施旨在切斷供應鏈攻擊（Supply Chain Attacks）中常見的攻擊鏈，防止惡意程式碼透過合法的開發管道滲透至成千上萬的下游使用者端。根據 InfoQ 的報導，GitHub 的核心策略並非尋找單一的終極解決方案，而是透過多層次的緩衝機制，在攻擊者獲取權限與正式發布惡意代碼之間創造時間差。
針對帳號權限被盜的初始入侵階段，npm 引入了讀取專用模式（Read-only）模式。當高影響力的帳號變更電子郵件地址或使用二階段驗證（2FA）恢復碼時，帳號將被凍結 72 小時，期間無法發布新版本。在 GitHub Actions 方面，為了防止攻擊者透過提交惡意程式碼到 Fork 分支來觸發工作流，actions/checkout 的預設行為已更改，除非團隊明確選擇退出，否則工作流將不再在常見的觸發條件下檢出不信任的 Fork 代碼。此外，GitHub Actions 的快取機制現在對不信任的觸發源設為唯讀，防止攻擊者透過污染共享快取來影響具有高權限的發行工作流。
為了防止憑證外洩與惡意擴散，GitHub 採取了更為激進的預設限制。npm v12 版本現在預設禁用安裝腳本（Install Scripts），並禁止透過 Git 或遠端 URL 獲取依賴項，這能有效阻止套件在安裝瞬間執行惡意指令。同時，Dependabot 的版本更新建議現在會等待三天後才開啟拉取請求（Pull Request），為維護者提供審查緩衝期。在發布端，npm 推出了分階段發布（Staged Publishing），要求在正式發布前必須完成額外的核准與 2FA 驗證。此外，npm 的信任發布（Trusted Publishing）目前已擴展支援 CircleCI，旨在消除在流水線中存放長效憑證的風險。
這些變更在開發者社群中引發了激烈爭論，焦點在於「時間延遲」是否為正確的防禦手段。部分維護者認為 72 小時的凍結期過短，因為攻擊者常選在週五或假期發動攻擊，三天的緩衝不足以讓度假中的維護者發現異常。另一派觀點則指出，單純的流程門檻無法解決根本問題。例如，若攻擊者買下維護者過期的電子郵件網域，僅需透過密碼重設即可掌控套件，此時 72 小時的延遲幾乎沒有意義。
社群中最強烈的批評指向 GitHub 長期拒絕實施作者端簽名（Author-side Package Signing）。這是一種類似於 Linux 發行版的機制，要求作者對代碼進行數位簽名以證明身份。批評者認為，GitHub 傾向於採取不需要維護者主動參與的自動化限制，而拒絕簽名機制則是擔心會增加貢獻者的門檻。然而，支持 GitHub 的觀點則認為，如果建構基礎設施本身被攻破，簽名系統同樣會被利用來簽署惡意套件，因此透過限制推送權限與引入時間延遲，反而是更務實的防禦方式。
從實務意義來看，GitHub 的做法將安全責任從「事後偵測」轉向「事前緩衝」。雖然分階段發布與信任發布能提供極高安全性，但目前仍採取選擇性加入（Opt-in）模式，普及率不高。而這次強制變更的預設值，如禁用安裝腳本，雖然提升了安全性，但也可能導致許多依賴該功能的舊有建構流程失效。這顯示出安全強化與開發便利性之間始終存在權衡，而 GitHub 目前選擇以犧牲部分便利性與引入時間成本，來換取對大規模供應鏈攻擊的緩衝能力。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。