OpenAI 回應 Axios 供應鏈事件，macOS 簽章憑證輪替把 AI 客戶端安全推上檯面

供應鏈攻擊最麻煩的地方，在於它經常不是打進產品本身，而是打進「產品是怎麼被做出來的」。OpenAI 這次對 Axios 開發工具遭入侵的回應，就是一個很典型的例子。官方說明顯示，問題並不在 ChatGPT 或其他應用程式本身被植入惡意程式，而是 OpenAI 在 macOS 應用簽章流程中使用的 GitHub Actions 工作流，曾下載並執行到受污染的 Axios 版本，導致 app signing 所需憑證材料暴露在風險範圍內。

如果你前幾天已讀過站內整理的 Axios 遭 npm 供應鏈攻擊，這次 OpenAI 的公告可以看成那場事件對 AI 產品公司造成的第一批具體後果之一。它證明了供應鏈攻擊不只影響一般 Node 專案，也會一路穿透到 AI 應用的發佈與信任鏈。

OpenAI 確認了哪些事

官方公告把關鍵事實講得相當清楚。

首先，事件源頭是 3 月 31 日的 Axios 供應鏈攻擊。當時 OpenAI 某個用於 macOS app signing 的 GitHub Actions workflow 下載並執行了惡意的 [email protected]。這個工作流可存取用於簽署 macOS 應用的憑證與 notarization 材料，而這些材料正是系統用來證明「這個安裝包真的是 OpenAI 發的」的重要信任根。

其次，OpenAI 表示目前沒有發現以下情況：

1. 沒有證據顯示用戶資料外洩。
2. 沒有證據顯示產品或原始碼被竄改。
3. 沒有證據顯示既有安裝版本遭植入惡意內容。

但即便如此，OpenAI 還是選擇把相關憑證視為可能已受影響，並啟動撤銷與輪替。這種處置方式很值得注意，因為它反映了現代供應鏈安全的一個基本現實：當你無法百分之百證明憑證材料完全沒有被帶走，最理性的決策往往不是等待更多證據，而是直接換掉整條信任鏈。

受影響的是哪些產品

這次事件的範圍並不是 OpenAI 全產品線，而是 macOS 應用相關的簽章流程。官方點名的更新門檻如下：

OpenAI 同時強調，這次事件不影響 iOS、Android、Linux、Windows，也不影響網頁版服務。換句話說，真正要採取行動的，是正在使用 OpenAI macOS 客戶端與工具鏈的那一群用戶，尤其是開發者與重度工作流使用者。

這次事故暴露的真正問題是 CI/CD 配置

OpenAI 在公告裡沒有只停在「我們很重視安全」這種標準公關句，而是直接說出根因：該 GitHub Actions 流程使用了 floating tag，而非鎖定到特定 commit hash，同時也沒有設定 minimumReleaseAge。這兩個細節非常關鍵。

使用 floating tag，代表工作流執行時抓到的是「當下最新的某個版本」，而不是先前驗證過的固定內容。對正常迭代來說這樣很方便，但在供應鏈被污染的情況下，便利性就會立刻變成風險放大器。

沒有 minimumReleaseAge，則意味著新版本套件一發布幾乎就能被流程拿來跑。這會讓短時間內上架又下架的惡意版本更容易穿透自動化流程。對很多團隊來說，這個設定以前比較像「可做可不做」的工程衛生；經過 Axios 事件之後，它會變成更接近基本防線的配置。

為什麼 AI 公司更容易被這類問題放大

一般軟體公司碰到簽章憑證輪替，已經很麻煩；AI 公司碰到，麻煩程度還會再多一層。原因不複雜：AI 產品現在越來越常同時存在桌面端、命令列工具、代理工作流與企業整合。只要其中某個客戶端被攻擊者偽裝成「看起來像官方程式」，風險就不只是釣魚安裝，而可能進一步影響企業內部程式碼、API 金鑰、文件與工作流程。

尤其像 Codex CLI 這類開發工具，本來就常被放進高權限環境使用。也因此，OpenAI 在 FAQ 中特別提醒用戶只透過官方頁面或應用內更新下載，不要從電子郵件、訊息、廣告或第三方下載站取得所謂的 OpenAI 安裝檔。這不是例行提醒而已，而是針對潛在冒牌安裝包風險的直接預防。

為什麼不立刻撤銷舊憑證

這是公告裡另一個很值得讀的決策細節。OpenAI 沒有選擇「現在就立刻把舊證書打掉」，而是給了一個到 5 月 8 日的更新窗口。表面上看起來像保守，實際上是風險與可用性之間的典型拉扯。

官方的理由是，新的惡意軟體若試圖使用舊材料簽章，因為新的 notarization 已被阻止，理論上會被 macOS 預設安全機制攔下；但如果現在立刻全面撤銷，也可能造成大量合法舊版本在新下載或首次啟動時直接失效，反而讓真實用戶在升級過程中被迫進入更混亂的狀態。

這是一個很現實的安全治理課題：在沒有觀察到已遭濫用的前提下，最快的處置不一定是對用戶傷害最小的處置。OpenAI 的做法是先封鎖新濫用空間，再提供更新窗口，同時持續監測是否出現惡意跡象。這種分段式處理，比起一刀切，更像成熟產品團隊會做的決策。

這件事給開發團隊的直接教訓

如果你的產品也在用 AI 功能或 AI 開發工具，這次事件至少留下三個明確教訓。

第一，供應鏈安全不只是 dependency scanner 的工作。真正高風險的位置，往往在 CI/CD、簽章、自動發佈、機密注入與權限配置。

第二，桌面端與 CLI 工具的信任鏈，重要性不亞於模型本身。大家很容易把安全焦點放在模型越權、資料外洩或 提示注入，但一個被偽裝成官方工具的安裝包，照樣可以成為更直接的入侵入口。

第三，固定版本、鎖 commit hash、拉長新套件可用時間窗口，這些以前看起來有點保守的流程，現在已經更接近基本盤。

OpenAI 這篇回應之所以值得注意，不是因為它揭露了多戲劇化的攻擊成果，而是因為它把一條常被忽略的事實擺到台前：AI 產品的安全，不只取決於模型輸出是否可靠，也取決於你是否能信任安裝到自己機器上的那個客戶端，真的是它本人。