軟體開發者在日常工作中會依賴大量的開源套件，這種開發模式雖然提升了效率，但也創造了一個巨大的安全漏洞，稱為供應鏈攻擊（Supply Chain Attack）。供應鏈攻擊是指攻擊者並不直接攻擊目標公司，而是將惡意程式碼植入該公司所依賴的第三方套件中。一旦開發者更新套件，惡意程式碼就會隨著套件進入公司內部環境。
近期 OpenAI 遭遇了一場名為 Mini Shai-Hulud 的供應鏈攻擊，其攻擊目標是廣泛使用的開源庫 TanStack。這次事件為我們提供了一個很好的實務案例，讓我們理解從一個第三方套件漏洞，如何演變成威脅到公司產品合法性的嚴重風險。
供應鏈攻擊的傳播路徑
在這次事件中，攻擊者首先污染了 TanStack 的 npm 套件。當 OpenAI 的兩名員工在公司環境中安裝或更新該套件時，惡意程式碼隨之在他們的開發裝置上執行。
這類惡意軟體通常會進行憑證竊取（Credential Exfiltration），也就是在背景偷偷搜尋開發者電腦中的金鑰、密碼或 Token。由於這兩名員工擁有存取部分內部原始碼儲存庫（Source Code Repositories）的權限，攻擊者成功地透過這兩個入口，獲取了儲存在儲存庫中的敏感憑證資料。
程式碼簽署憑證的重要性與風險
在這次事件中，最關鍵的風險在於程式碼簽署憑證（Code Signing Certificates）被外洩。
對於 Junior 工程師來說，可以將程式碼簽署想像成數位世界的蓋章證明。當你下載一個 macOS 或 Windows 應用程式時，作業系統會檢查該程式是否有合法開發者的簽章。如果沒有簽章，或者簽章無效，系統會警告使用者該軟體可能包含惡意程式碼或來源不明。
由於 OpenAI 的簽署憑證被竊取，攻擊者理論上可以使用這些憑證來為任何惡意軟體蓋章，讓該軟體看起來就像是 OpenAI 官方發布的合法應用程式。這會導致使用者在不知情的情況下安裝偽裝成 ChatGPT 或 Codex 的木馬程式。
OpenAI 的應對措施與技術緩解
面對憑證外洩，OpenAI 採取了分階段的補救措施，這在工程實務上是非常標準的危機處理流程。
首先是遏制與清理。他們立即隔離受影響的裝置、撤銷所有受影響的使用者對話 session，並對所有儲存庫進行憑證輪替（Rotation），也就是廢除舊金鑰並更換新金鑰。
其次是處理 macOS 的特殊機制。macOS 具有公證（Notarization）機制，軟體在分發前必須經過 Apple 的掃描確認。OpenAI 與平台提供者協調，阻止使用舊憑證進行新的公證。這意味著即便攻擊者持有舊憑證，也無法通過 Apple 的公證檢查，除非使用者強行繞過系統安全設定。
最後是強制更新。由於舊憑證最終必須被完全撤銷（Revoke），一旦撤銷，所有使用舊憑證簽名的舊版本 App 將無法啟動。因此，OpenAI 給予使用者一個緩衝期，要求在指定日期前更新至使用新憑證簽名的最新版本。
如何防止類似的供應鏈攻擊
為了減少未來被類似攻擊影響的機率，OpenAI 提到了一些具體的安全控制措施，這對所有開發團隊都有參考價值。
第一是強化 CI/CD 流水線中的憑證管理。不要將敏感憑證直接儲存在原始碼儲存庫中，而應使用專門的金鑰管理系統（KMS）或 Secret Management 工具。
第二是導入套件管理控制。例如設定最低發布年限（minimumReleaseAge）。這是一種非常實用的策略，要求套件必須發布一段時間（例如 24 小時）後才能被自動更新。這樣可以給予社群時間發現並回報惡意版本，避免開發者在惡意版本發布的第一時間就將其下載到公司內部。
第三是驗證套件來源（Provenance）。透過數位簽章或雜湊值（Hash）驗證下載的套件是否與官方發布的版本完全一致，防止套件在傳輸或儲存過程中被篡改。
總結
這次事件提醒我們，現代軟體開發是一個高度互連的生態系。單一第三方套件的漏洞可能會透過開發者的權限，迅速擴散到公司核心的基礎設施。身為工程師，除了關注功能開發，更應意識到依賴管理（Dependency Management）本身就是一種安全風險，必須透過嚴格的憑證管理與自動化檢核機制來降低威脅。
來源：openai.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。