OpenAI、Axios汚染で露呈したmacOS署名ワークフローの供給網リスク

OpenAIが2026年4月10日に公表した内容は、典型的な「データ漏えい事故」とは少し性格が違う。問題になったのは、3月31日に発生したAxiosの大規模なソフトウェア供給網攻撃が、OpenAIのmacOS向けアプリ署名ワークフローに入り込み、コード署名証明書とnotarization（Appleの公証）関連素材に接触しうる状態をつくったことだ。OpenAIはユーザーデータ流出や製品改ざんの証拠はないとしつつも、証明書を「念のため侵害前提」で扱い、再署名と証明書ローテーションに踏み切った。これは、生成AI企業にとっても脅威の中心がモデルそのものだけでなく、CI/CDと配布基盤にあることを示す出来事だった。 (openai.com)

まず何が起きたのか。OpenAIによれば、2026年3月31日、同社がmacOSアプリの署名工程で使っていたGitHub Actionsワークフローが、改ざんされたAxios 1.14.1をダウンロードして実行した。このワークフローは、ChatGPT Desktop、Codex App、Codex CLI、Atlasの署名に使う証明書とnotarization素材にアクセス可能だった。OpenAIの調査では、実行タイミングやジョブの順序などから証明書の持ち出しは「成功していない可能性が高い」とされたが、それでも危険を過小評価せず、旧証明書の失効・新証明書への切り替えを実施している。OpenAIは、ユーザーデータ、社内システム、知的財産、既存配布ソフトの改ざんについては証拠を確認していない。 (openai.com)

Axios側の事故は、より広い業界横断の供給網攻撃の一部だった。GoogleとMicrosoftの分析では、悪性版として公開されたのは axios@1.14.1 と axios@0.30.4 で、ここに注入された plain-crypto-js が postinstall スクリプト経由で動作し、macOS・Windows・Linux向けの第2段階RATを取得する仕組みだった。Googleはこの活動を北朝鮮系のUNC1069、MicrosoftはSapphire Sleetに結び付けており、両社ともOS別のペイロード配信とC2通信の存在を示している。重要なのは、Axios本体のアプリ挙動を壊すのではなく、「インストール時」に静かに悪性コードを実行する設計だった点だ。CI/CD上で踏むと、その瞬間に開発・署名環境が汚染されうる。 (cloud.google.com)

なぜmacOSの署名ワークフローがこれほど重要なのか。Appleの説明では、Mac App Store外で配布されるmacOSアプリは、Developer ID証明書で署名され、Appleのnotarizationを受けることで、Gatekeeperが「識別された開発者のソフト」であり、「既知の悪性コードがない」と確認できる。署名は改ざんされていないことを示し、notarizationはApple側の検査を通ったことを示す。もしこの信頼連鎖の上流で証明書や公証素材が悪用されれば、偽アプリが正規ベンダー製に見える余地が生まれる。OpenAIが「偽のOpenAIアプリ配布」を主なリスクとして語ったのは、このためだ。 (support.apple.com)

OpenAIの対応はかなり教科書的でもある。同社は外部DFIR企業を起用し、新しいmacOSビルドを再署名し、Appleと協力して旧証明書による新規notarizationを止めた。これにより、仮に第三者が旧証明書で偽アプリを署名しても、notarizationを欠くため、macOSの既定設定ではGatekeeperにブロックされる。さらに2026年5月8日以降、旧証明書で署名された古いmacOS版は更新・サポート対象外となり、機能しない可能性がある。新証明書で署名された最小バージョンとして、ChatGPT Desktop 1.2026.051、Codex App 26.406.40811、Codex CLI 0.119.0、Atlas 1.2026.84.2 が案内されている。 (openai.com)

今回の技術的な教訓は、OpenAI自身がかなり率直に書いている。根本原因は、GitHub Actionsで「floating tag」を使っていたことと、新規公開直後の依存を避ける minimumReleaseAge 相当の設定がなかったことだ。GitHubは、第三者Actionを安全に使うにはフル長のcommit SHA固定が実質的に唯一の不変参照だと説明している。またnpmは、OIDCベースのtrusted publishingによって長寿命トークンを不要にし、さらに min-release-age により公開直後の版を一定日数インストール対象から外せるとしている。つまり、今の供給網防御は「脆弱性スキャン」だけでは足りず、参照の不変化、公開元の証明、最新版の即時採用を避ける時間差制御がセットで要る。 (openai.com)

この事件を生成AI文脈で見ると、示唆はさらに大きい。Googleは、同時期にTrivy、Checkmarx、LiteLLMに絡む別の供給網攻撃も確認しており、GitHubも3月17日にnpm向けDependabot malware alertを公開した。これは、オープンソースの「既知脆弱性」を追うだけでなく、「悪性版そのもの」を検知する運用へ、エコシステム全体が軸足を移し始めたことを意味する。AI企業はモデル配備だけでなく、デスクトップアプリ、CLI、エージェント、開発者向けSDKを継続的に出荷する。そのため、署名鍵、配布パイプライン、ビルドランナーはモデル重みと同じくらい重要な資産になっている、と読むのが自然だ。 (cloud.google.com)

結局のところ、この件の本質は「AI企業がAIらしい新種の攻撃で倒れた」のではなく、「最先端のAI企業でも、古典的だが進化したソフト供給網攻撃の射程内にある」と確認されたことにある。OpenAIは今回、証拠不十分でも証明書を切り替える保守的対応を選び、被害の連鎖を信頼面で先回りして断った。今後の焦点は、署名工程の分離、短命資格情報への移行、依存更新の遅延導入、第三者ActionのSHA固定、マルウェア版依存の自動検知といった、地味だが効果の大きい制御をどこまで標準化できるかに移るだろう。生成AIの安全性は、モデル評価だけでなく、そのモデルをユーザーの手元へ安全に届ける供給網の設計で決まる局面に入っている。 (openai.com)

主な出典
OpenAI公式インシデント説明、Google Threat Intelligence Groupの分析、Microsoft Threat Intelligenceの分析、AppleのmacOS署名・Gatekeeper文書、GitHub Actionsセキュリティ文書、npm公式ドキュメント。 (openai.com)

必要なら次に、
- 企業向けの再発防止チェックリスト
- 非技術者向けの短い要約版
- 開発者向けに「何をどう設定すべきか」を実務寄りに整理した版

のどれかに絞って続けられます。