Artificial Intelligence (AI)
Vercel侵害：OAuthサプライチェーン攻撃がプラットフォーム環境変数に潜む見えにくいリスクを露呈
Vercelに対するOAuthサプライチェーン侵害により、信頼されたサードパーティ製アプリとプラットフォーム環境変数が、従来の防御をどのように回避し、被害範囲を拡大させ得るかが明らかになりました。本記事では、攻撃の連鎖、根底にある設計上のトレードオフ、そしてこの事案が現代のPaaSとソフトウェアサプライチェーンリスクについて何を示しているのかを考察します。
目次
- 主なポイント
- このインシデントが明らかにすること
- インシデントのタイムライン
- 攻撃チェーン
- 開示タイムラインの異常
- AIによって加速された攻撃者の手口（CEOの評価）
- 環境変数設計の問題
- 認証情報のファンアウト：下流リスクの定量化
- OAuthの信頼関係が境界防御を迂回する理由
- 攻撃者の主張とアトリビューション
- MITRE ATT&CK マッピング
- サプライチェーン包囲網：LiteLLM、Axios、そして収束するパターン
- 過去のプラットフォーム侵害が明らかにすること
- 依然として不明な点
- 検知およびハンティングのガイダンス
- SIEM 実装のための検知ロジック
- 脅威ハンティング
- 防御に関する推奨事項
- 規制およびコンプライアンス上の影響
- 結論
- 侵入の痕跡
- 参考記事
- 侵害されたサードパーティ製OAuthアプリにより、Vercelの内部システムへの長期間かつパスワードに依存しないアクセスが可能となり、OAuthの信頼関係が従来の境界防御を回避し得ることが示されました。
- 影響はVercelの環境変数モデルによって拡大しました。このモデルでは、機密として明示的に指定されていない認証情報は内部アクセスがあれば読み取り可能であり、その結果、顧客のシークレットがプラットフォーム全体の規模で露出しました。
- 公表前から漏洩した認証情報に関するアラートが公開されていたことは、検知から通知までの遅延が、プラットフォーム侵害における重大なリスク要因であることを浮き彫りにしています。
- この事案は、攻撃者がCI/CD、パッケージレジストリ、OAuth連携、デプロイメントプラットフォーム全体で、開発者が保存した認証情報を一貫して標的にしているという、2026年のより広範な収束パターン（LiteLLM、Axios）に当てはまります。
- 効果的な防御には、アーキテクチャ上の変更が必要です。具体的には、OAuthアプリをサードパーティベンダーとして扱うこと、長期間有効なプラットフォームシークレットを排除すること、そしてプロバイダー側の侵害を前提として設計することが求められます。
進行中の事案 — 最終更新：2026年4月20日（月）
本分析は、公開時点で公に判明している Vercel OAuth サプライチェーン侵害に関する情報を反映したものです。本インシデントについては、Vercel および影響を受けた関係者による調査が現在も継続中であり、追加情報が明らかになるにつれて、下流への影響の全容、正確な初期アクセス経路、アトリビューションを含む重要な詳細が変わる可能性があります。情報に欠落がある箇所については、推測を行うのではなく、その旨を明示しています。防御に関する推奨事項および検知ガイダンスは、確認済みの攻撃チェーンと、確立されたサプライチェーン侵害のパターンに基づいています。組織は全体像の完全な把握を待つのではなく、これらの対策を直ちに講じるべきです。新たな技術的詳細、ベンダーによる開示、または第三者の調査結果が明らかになり次第、本分析を更新します。
2024年6月頃に始まり、2026年4月に公表されたこの侵入では、攻撃者が Context.ai の Google Workspace OAuth アプリケーションの侵害を悪用して Vercel の内部システムへの足掛かりを得て、未公表ではあるものの限定的とされる一部の顧客プロジェクトの環境変数が露出しました。Vercel は、フロントエンドおよびサーバレスアプリケーションで広く利用されているクラウドデプロイおよびホスティングプラットフォームです。
2026年4月19日、Vercel はセキュリティブリテンを公開し、CEO の Guillermo Rauch は X の詳細なスレッド で攻撃チェーンを認めるとともに、侵害された第三者として Context.ai の名前を挙げました。
本インシデントが重要である理由は、OAuth サプライチェーンにおける信頼関係が、従来の境界防御を回避するラテラルムーブメントの経路を生み出すことを示している点と、Vercel の環境変数に関する機密性モデルにより、機微ではない認証情報が保存時に暗号化されておらず、内部アクセスを持つ攻撃者がこれを読み取れる状態にあった点にあります。
本分析では、攻撃チェーンを検証し、被害範囲を拡大させたプラットフォーム設計上の判断を評価し、増加するサプライチェーン侵害の波（LiteLLM、Axios、Codecov、CircleCI）との関連で本侵害を位置付けるとともに、Vercel および同様の PaaS プラットフォームを運用する組織に向けて、実行可能な検知およびハードニングのガイダンスを提供します。
このインシデントが明らかにすること
このインシデントが注目に値するのは、その高度さではありません。使用された手法自体は広く確立されたものですが、特に重要性を高めている、より広範な3つの含意があるためです。
- OAuthの増幅効果。単一のOAuth信頼関係が連鎖的に波及し、侵害されたベンダーと直接の関係がなかった下流の顧客にまで影響する、プラットフォーム全体の露出事象へと発展しました。
- AIによって加速された攻撃手法。CEOは、攻撃者の異例の速さはAIによる強化に起因すると公に述べており、これは2026年におけるAIで加速された攻撃者の手法に関する議論の中で、初期の注目度の高いデータポイントとなっています。
- 検知から開示までの遅延。少なくとも1件の公開顧客レポートは、Vercelによる開示の9日前に、認証情報が外部で漏洩したものとしてフラグ付けされていたことを示唆しており、プラットフォーム侵害における検知から開示までの遅延について疑問を投げかけています。
このタイムラインからの重要な観察点は、最初の OAuth 侵害から公表までの潜伏期間が約22か月に及んでいたことです。長期の潜伏期間自体は高度な侵入では珍しくありません。たとえば、Codecov の侵害は約2か月間、CircleCI の事案は数週間にわたって検知されませんでした。しかし、正規のアプリケーション権限を利用する OAuth ベースのラテラルムーブメントは検知が難しいことを示しています。
この問題をさらに深刻にしているのは、多くのサブスクリプション階層において Google Workspace の OAuth 監査ログがデフォルトで6か月しか保持されないことです。つまり、調査担当者が確認に着手する前に、最も初期の侵害活動に関するフォレンジック上の可視性は失われていた可能性が高いです。
攻撃チェーン
この攻撃では、現代の SaaS 環境に広く存在する信頼の連鎖が悪用されました。すなわち、企業の Google Workspace アカウントへのアクセスを許可されたサードパーティ製 OAuth アプリケーションです。
ステージ1: サードパーティOAuthの侵害（T1199）
AI分析ツールを提供する企業であるContext.aiには、Vercelの従業員が認可したGoogle Workspace OAuthアプリケーションがありました。攻撃者はこのOAuthアプリケーションを侵害しましたが、Context.aiがどのように侵害されたのかという正確な手口は公表されていません。RauchはXへの投稿で、Vercelは「インシデントの全容把握を支援するためにContextに連絡を取った」と述べており、この表現からは、Context自身では侵害を検知していなかった可能性が示唆されます。
これは、極めて重要な初期アクセス経路です。OAuthアプリケーションは、いったん認可されると、永続的なアクセストークンを維持し、以下の特徴があります。
- ユーザのパスワードを必要としません
- パスワード変更後も有効です
- 広範なスコープを持つことが多いです（メール、ドライブ、カレンダーへのアクセスなど）
- 初回認可後に監査されることはまれです
ステージ2: Workspaceアカウントの乗っ取り（T1550.001）
攻撃者は、侵害されたOAuthアプリケーションのアクセス権を利用して、Vercel従業員のGoogle Workspaceアカウントへと侵入を広げました。これにより、メールへのアクセス（追加の認証情報窃取につながる可能性）、Google Drive経由での社内ドキュメントへのアクセス、会議や関連リソースに関するカレンダー上の可視性、さらに他のOAuth接続サービスへのアクセスの可能性が生じました。
ステージ3: 内部システムへのアクセス（T1078）
攻撃者は、侵害されたWorkspaceアカウントを起点として、Vercelの内部システムへと侵入を広げました。Rauchはこの権限昇格について、「同僚の侵害されたVercel Google Workspaceアカウントから段階的にエスカレーションした一連の動き」と説明しています。具体的なラテラルムーブメントの手法――SSO連携を経由したのか、メールやドライブから取得した認証情報を用いたのか、あるいは別のOAuth接続された社内ツールを使ったのか――は明らかにされていません。
ステージ4: 環境変数の列挙（T1552.001）
攻撃者は、顧客プロジェクトの環境変数を列挙できる十分な権限を持って、Vercelの内部システムにアクセスしました。Rauchの公開声明によれば、Vercelはすべての顧客の環境変数を保存時に完全に暗号化して保管していますが、プラットフォームには変数を「非機密」として指定できる機能があります。攻撃者は、これらの非機密変数を列挙することで、さらなるアクセスを取得しました。
ステージ5: 下流での悪用の可能性（T1078.004）
露出した環境変数には、下流サービス用の認証情報が含まれていることが一般的です。Andrey Zagoruikoによる公開された顧客報告1件（2026年4月19日）では、4月10日にOpenAIから漏洩キー通知を受け取ったことが記載されており、そのAPIキーは報告によればVercel内にしか存在していなかったとされています。これは、Vercelの開示前に、少なくとも1件の露出した認証情報が実際の環境で検知されていたことを示唆しています。
この報告は、検知から開示までの過程における潜在的な不整合を示しており、より詳しい検証が必要です。この点については次のセクションで取り上げます。
開示タイムラインの異常
4月19日にXへ投稿されたGuillermo Rauch氏のスレッドに対する公開返信において、独立して注目に値するタイムライン上の事実が明らかになりました。Vercelの顧客であるAndrey Zagoruiko氏は、2026年4月10日にOpenAIから漏洩したキーに関する通知を受け取ったと報告しています。このAPIキーは、顧客によると、Vercel以外に存在したことは一度もありませんでした。
OpenAIの漏洩認証情報検知システムは、通常、そのAPIキーが本来存在すべきではない公開場所（例：GitHub、ペーストサイト、その他の類似ソース）で見つかった場合に作動します。Vercelの環境変数からOpenAIの通知に至る経路は、単純には説明できません。特に、この日付は、漏洩を示す最も早い公開証拠とVercelの開示との間に9日間の空白があることを示しています。
9日間のギャップが意味すること、そして意味しないこと
重要なのは、これは単一の公開レポートであり、フォレンジック調査結果ではないという点です。これを、Vercel が4月10日の時点で侵害を認識していたことの証拠として解釈すべきではありません。
しかし一方で、顧客に対してシークレットのローテーションを正式に通知する前に、少なくとも1つの認証情報が外部で検出されていたことを示す証拠ではあります。この違いは、次の3つの対象者にとって重要です。
- 規制当局: GDPR では、データ管理者が侵害を認識した時点から、72時間の侵害通知期限が起算されます。Vercel がいつ認識したのかという問題は、いまや公になっています。
- 監査担当者: SOC 2 および ISO 27001 の評価者は、継続的モニタリングの証跡の一部として、検知から通知までの遅延を精査します。
- 顧客: 自社の認証情報が露出した可能性のある組織は、その露出期間が4月19日に終了したと想定することはできません。実際には、それよりかなり前から積極的に悪用されていた可能性があります。
インシデント対応計画の観点から見ると、このデータポイントは実務上の重要な点も裏づけています。OpenAI、Anthropic、GitHub、AWS、Stripe などのプロバイダーから届く、依頼していない漏洩認証情報の通知は、いまやプラットフォーム侵害に対する主要な早期警戒チャネルとなっています。セキュリティチームは、こうした通知を日常的なノイズではなく、優先度の高いシグナルとして扱うべきです。
AIによって加速された攻撃者の手口（CEOの評価）
Vercel の CEO である Guillermo Rauch 氏は、4月19日に X へ投稿したスレッドで、次のように明言しています。
「攻撃グループは高度に洗練されており、さらに私の強い推測では、AI によって大幅に加速されていたと考えています。彼らは驚くべき速さと、Vercel に対する深い理解をもって行動しました。」
これは、影響を受けたプラットフォームの CEO による注目すべき公式見解であり、慎重に評価すべきです。「速度」に基づくアトリビューションは本質的に解釈を伴うものですが、このセクションで論じるいくつかの理由から、十分に注意を払う価値があります。
証拠として「AI によって加速された」状況がもっともらしく見える場合
Rauch 氏の評価が、事後的な合理化ではなく何らかの実態を反映しているのであれば、根底にあるフォレンジック上のシグナルには、次のうち 1 つ以上が含まれる可能性があります。
- 手動のペースを上回る列挙速度。これにはスクリプトだけでもある程度説明がつきますが、LLM を活用した偵察では、スキーマの発見、エンドポイントの探索、認証情報の形式認識を、手動でクエリを組み立てるよりも高速に並列化できます。
- 文脈に即したクエリの構築。事前の偵察が明確に確認できないにもかかわらず、Vercel 固有の用語（project slug、デプロイ先の名称、環境変数の命名規則など）を把握しているように見えるクエリ。
- エラーへの適応的な挙動。LLM 支援を受けた攻撃者は、固定的なスクリプトよりも API エラーやレート制限から自然に立ち直る傾向があり、その場で戦略を切り替えます。
- プロンプト設計されたソーシャル上の成果物。翻訳文やテンプレート文のようではなく、その地域や文脈に即した本物らしさを持つフィッシングの誘導文、コミットメッセージ、またはサポートチケット。
なぜこれは Vercel のインシデントにとどまらず重要なのか
Rauch 氏の評価が正式なフォレンジックレビューに耐えるかどうかにかかわらず、このカテゴリ自体、すなわち AI によって強化された攻撃者のオペレーションは、もはや単なる推測ではありません。Microsoft が 2026 年 4 月に公表した、AI を利用した device-code フィッシング（Storm-2372 後継キャンペーン）に関する資料では、動的なコード生成、きわめて高度に個別最適化された誘導文、バックエンド自動化のオーケストレーションのために、実際の攻撃者が生成 AI を利用していることが記録されています。これは、人間のペースによる攻撃者の挙動を前提に調整されたテレメトリのベースラインでは、AI によって加速されたオペレーターに対して偽陰性が生じる可能性があることを意味します。
検知エンジニアリングへの示唆
AI によって加速された攻撃者が列挙とラテラルムーブメントのタイムラインを圧縮する場合、過去のインシデントデータに基づく滞留時間や速度のしきい値に合わせて調整された検知ルールでは、アラートが十分に上がらない可能性があります。特に、チームは次のしきい値の見直しを検討する必要があります。セッションごとのユニークリソース列挙率、エラーから成功への回復曲線の比率、短時間内におけるクエリパターンの多様性です。
環境変数設計の問題
この侵害で最も重大な点は、初期アクセスベクターではありません。OAuth の侵害は、既知で研究も進んでいるリスクです。問題の本質は、顧客のシークレットに対してデフォルトで安全ではない構成を生み出した Vercel の環境変数の機密性モデルにあります。
侵害発生時点における Vercel 環境変数の仕組み
Vercel のプロジェクトでは、環境変数を使用して構成情報やシークレットをサーバレス関数およびビルドプロセスに注入します。これらの変数には、表 2 に示すように、アクセス制限を制御する「sensitive」フラグがあります。
重大な設計上の選択
sensitive フラグは、デフォルトでオフになっています。開発者がこのフラグを明示的に切り替えずに追加した DATABASE_URL、API_KEY、STRIPE_SECRET_KEY、または AWS_SECRET_ACCESS_KEY は、いずれも Vercel の内部アクセスモデルにおいて、保存時に暗号化されないまま保管されていました。
すべての個別のシークレットについて、明示的なオプトインを必要とし、ガードレールやデフォルト設定もないセキュリティ管理は、実運用において採用率が低くなります。
Vercel の対応
Rauch 氏は、Vercel がすでにダッシュボードの変更を展開済みであることを認めました。具体的には、環境変数の概要ページと、sensitive 変数の作成および管理のために改善された UI です。これらの変更により見つけやすさは向上していますが、本稿執筆時点ではデフォルト設定は変わっておらず、開発者は引き続き変数ごとにオプトインする必要があります。Vercel がデフォルトを切り替えるかどうかは、依然として未解決の問題であり、顧客はその点について働きかけるべきです。
業界の同業他社との比較
業界の潮流は、感度の階層を持つ環境変数ストアではなく、Vault、AWS Secrets Manager、Doppler、Infisical のような、シークレット保存専用に設計された仕組みに向かっています。今回の侵害は、そのアーキテクチャ上の選択の正しさを裏付けています。
表3は、Vercelの環境変数ベースのアプローチが、類似プラットフォームにおける一般的な運用と比べてどのような位置付けにあるかを要約したものです。
この特定のケースについて、Vercelプロジェクトの環境変数に通常どのようなものが含まれる可能性があるか、およびその下流への影響を表4にまとめます。
1つのVercelプロジェクトには、一般的に10～30個の環境変数が含まれています。組織規模で見ると、50件のプロジェクトのポートフォリオには、プラットフォーム内に500～1,500件の認証情報が存在する可能性があります。各認証情報は、それぞれ独自の影響範囲を持つ、まったく別のシステムへの潜在的なピボットポイントです。
これが、プラットフォーム侵害を単なる機密性の事案から、ソフトウェアサプライチェーン全体に連鎖する可能性のある事態へと引き上げる増幅要因です。
OAuthの信頼関係が境界防御を迂回する理由
この攻撃が約22か月にわたって成功した根本的な理由は、OAuthベースの侵入が、従来の認証情報ベースの攻撃を検知または阻止できる大半の制御を迂回するためです。
左列にある防御制御はいずれも、セキュリティチームがアカウント侵害の検知やブロックのために依拠しているものです。しかし、OAuthアプリ侵害の経路では、それらの制御はすべて無関係であるか、すでに満たされています。この非対称性こそが、OAuthガバナンスが、アイデンティティおよびアクセス管理とは別個の独立したセキュリティ分野として台頭している理由です。
ベンダーリスク機能としてのOAuthガバナンス
多くの組織では、OAuth付与を開発者向けのセルフサービスの問題として扱っています。つまり、各従業員が必要なツールを自ら承認し、中央でのレビューは最小限にとどまっています。今回のインシデントは、OAuth付与をサードパーティリスク管理として扱うべきであることを示しています。すなわち、承認された各OAuthアプリは、実質的に企業データへ継続的にアクセスできるベンダーであり、ベンダーレビュー、定期的な再承認、ならびに異常な利用の監視の対象とすべきです。
攻撃者の主張とアトリビューション
地下フォーラムにおける攻撃者の主張は、本質的に信頼できるものではありません。以下の内容は、認識向上と脅威追跡のために記載したものであり、確認済みの事実ではありません。侵害事案におけるアトリビューションは非常に困難であり、フォーラム上の主張はしばしば誇張、捏造、またはインシデントと周辺的にしか関係のない当事者によって行われます。
ShinyHunters関連の主張
ShinyHuntersグループとの関係を名乗る攻撃者が、BreachForumsにVercelのデータを保有していると主張する投稿を行いました。
インシデントを、ShinyHunters との関係を主張する攻撃者によるものと特定することを難しくしている要因がいくつかあります。
- 既知の ShinyHunters メンバーは、BleepingComputer に対して関与を公に否定しています。
- 2,000,000 ドルの身代金要求が Telegram を通じて伝えられたとされています。これは、正当な侵害主張と捏造された侵害主張の両方に共通する、一般的な金銭化のパターンです。
- ShinyHunters という名称は、当初の活動以降、複数の、互いに無関係である可能性のある攻撃者によって使用されてきました。
- Vercel のセキュリティ情報ではこれらの主張に言及しておらず、Rauch のスレッドは攻撃チェーンには触れているものの、フォーラムへの投稿自体には直接言及していません。
サプライチェーンのリリース経路: Vercel の見解
Rauch は、最も影響の大きいシナリオについて、「当社はサプライチェーンを分析し、Next.js、Turbopack、および多数のオープンソースプロジェクトがコミュニティにとって安全な状態にあることを確認しました」と直接説明しました。
本稿執筆時点では、リリース経路の完全性に関する独立した検証が継続中です。Next.js、Turbopack、またはその他の Vercel のオープンソースプロジェクトを利用している組織は、標準的な実務として、引き続きパッケージ完全性のシグナル（チェックサム、署名、来歴証明）を監視する必要があります。
フォーラムで主張されているデータについて独立した検証がない以上、それらの主張は未確認として扱うべきです。Vercel が説明した OAuth ベースの攻撃チェーンは技術的に妥当であり、フォーラム投稿者が主張するほどのアクセス範囲を必要としません。このことは、それらの主張が誇張されている可能性、別個の無関係なインシデントを示している可能性、または捏造である可能性を示唆しています。
MITRE ATT&CK マッピング
確認された攻撃チェーンは、表6に要約したとおり、確立された MITRE ATT&CK の手法に明確に対応しています。このマッピングは、Vercel の開示内容で明示的に説明されている挙動を反映しており、新たな悪用手法ではなく、よく知られている OAuth の悪用パターンと整合しています。
このマッピングに基づくと、OAuth アプリケーションへのアクセスから内部システムへのアクセスへのピボット（T1199 から T1078）は、最も価値の高い検知ポイントです。
そのため、組織は異常な OAuth アプリケーションの挙動を監視する必要があります。特に、想定されたスコープ外のリソースにアクセスするアプリケーションや、想定外の IP 範囲からアクセスするアプリケーションに注意すべきです。
サプライチェーン包囲網：LiteLLM、Axios、そして収束するパターン
Vercel への侵害は、単独で発生したものではありません。2026年3月から4月にかけて、ソフトウェアサプライチェーン攻撃が前例のないほど集中して発生しており、これは協調的なキャンペーン活動、あるいはより可能性が高いのは、複数の攻撃者が同じ構造的な弱点、すなわちパッケージレジストリ、CI/CD システム、OAuth プロバイダ、デプロイメントプラットフォームの間にある信頼境界を、同時期に発見したことを示唆しています。
2026年3月24日：LiteLLM の PyPI サプライチェーン侵害
悪意のある PyPI パッケージ litellm バージョン 1.82.7 および 1.82.8 は、Trivy（Aqua Security の脆弱性スキャナ）から盗まれた、PyPI 公開権限を持つ CI/CD 公開用認証情報を使って公開されました。攻撃の標的となったのは、1日あたり約340万回ダウンロードされる、広く利用されている LLM プロキシ LiteLLM でした。
- 初期アクセス：攻撃者（「TeamPCP」として追跡）は、PyPI への公開権限を持つ Trivy の CI/CD パイプライン認証情報を侵害しました。
- ペイロード：主要クラウドプロバイダ全体で50種類以上の認証情報を標的とする3段階のバックドアであり、横展開のために Kubernetes DaemonSet による永続化機能を備えていました。
- 潜伏時間：悪意のあるパッケージは、検知および削除までの約40分から3時間にわたり公開状態にありました。
- 関連する CVE：CVE-2026-33634。
2026年3月31日：Axios の npm サプライチェーン侵害
npm パッケージ axios（週あたり7,000万〜1億回ダウンロード）は、メンテナーアカウントの乗っ取りによって侵害されました。悪意のあるバージョン 1.14.1 および 0.30.4 では、plain-crypto-js@4.2.1 への依存関係が注入されており、これにはクロスプラットフォームの Remote Access Trojan（RAT）が含まれていました。
- 初期アクセス：メンテナーアカウントが乗っ取られました（手口は非公開ですが、クレデンシャルスタッフィングまたはフィッシングが疑われています）。
- 規模：攻撃者のコマンド＆コントロール基盤に接続している 135 のエンドポイントが検出されました。
- 潜伏時間：検知まで 2～3 時間でした。
- 帰属：Microsoft は、この攻撃を北朝鮮の国家支援型攻撃者である Sapphire Sleet によるものとしています。
収束パターン
3週間で3件の攻撃。3つの異なる侵入経路。標的は同じです。開発者がツールチェーンに保存している認証情報とシークレットです。
過去のプラットフォーム侵害が明らかにすること
Vercelの侵害は、顧客のシークレットを大規模に露出させる、十分に文書化されたプラットフォームレベルの侵害パターンに沿っています。
Codecov Bash Uploader侵害（2021年1月～4月）
何が起きたか： 攻撃者は、CodecovのBash Uploaderスクリプト（CI/CDパイプラインで使用）を改ざんし、顧客のCI環境から環境変数を外部に送信しました。この侵害は約2か月間検知されませんでした。Twitch、HashiCorp、Confluentを含む29,000社超の顧客が影響を受けた可能性があります。
Vercelとの共通点： いずれのインシデントも、プラットフォーム侵害を通じて、環境変数として保存されていた顧客認証情報が露出した点が共通しています。
CircleCIセキュリティインシデント（2023年1月）
何が起きたか： 攻撃者は、個人用デバイス上のマルウェアを通じて従業員のSSOセッショントークンを窃取し、それを使ってCircleCIの内部システムにアクセスし、顧客のシークレットと暗号鍵を外部に送信しました。CircleCIは、プラットフォーム上に保存されているすべてのシークレットをローテーションするよう全顧客に推奨しました。
Vercelとの共通点： ほぼ同一のパターンです — 従業員アカウントの侵害 → 内部システムへのアクセス → 顧客シークレットの外部送信。
Snowflake顧客認証情報への攻撃（2024年5月～6月）
攻撃者UNC5537は、インフォスティーラーマルウェアによって取得された認証情報を使用し、MFAが有効化されていないSnowflakeの顧客アカウントにアクセスしました。Ticketmaster、Santander Bank、AT&Tを含む165以上の組織が影響を受けました。
Oktaサポートシステム侵害（2023年10月）
攻撃者は、盗まれた認証情報を使用してOktaのカスタマーサポート案件管理システムにアクセスし、Cloudflare、1Password、BeyondTrustを含むOkta顧客のセッショントークンが含まれていたHARファイルを閲覧しました。
パターンの要約
このパターンは明確です。プラットフォームレベルで顧客のシークレットにアクセスできることは、CI/CD、アイデンティティ、データウェアハウス、デプロイメントプラットフォーム全体で繰り返し悪用されてきた構造的リスクです。各インシデントは同じ流れをたどっています。すなわち、信頼関係または認証情報を起点とする初期アクセス、内部システムへの水平展開、そして大規模な顧客シークレットの流出です。
- Context.ai がどのように侵害されたのか。OAuth アプリケーション侵害の根本原因は開示されていません。Rauch 氏の「Vercel は支援のために Context に連絡を取った」という声明は、影響範囲が Context.ai 自身にとっても依然として不明確である可能性を示唆しています。
- Vercel が最初に異常なアクティビティを検知した時期。4 月 10 日に Vercel の顧客が受け取った OpenAI からの通知により、この疑問がより明確に浮上しています。Vercel は内部検知の時系列を公表していません。
- 資格情報の悪用に関する最も早い公開証拠と Vercel の開示との間に 9 日間の差がある理由。複数の説明が考えられます（協調開示、調査継続中、顧客通知の進行中など）が、公開されている情報だけではどれが該当するのか判断できません。
- 影響を受けた顧客数。Rauch 氏は影響を「かなり限定的」と説明していますが、具体的な件数は開示されていません。
- ShinyHunters フォーラムでの主張が同一の攻撃者によるものかどうか。それらの主張が確認済みの攻撃チェーンと一致するのか、あるいは別個のインシデントなのかは、依然として検証されていません。
- Context.ai の現在の状況と、その下流顧客への通知。Context.ai が独自のインシデントレポートを公表しているか、または他の顧客に通知しているかは不明です。
- 内部アクセスの全容。環境変数以外に、22 か月の潜伏期間中に攻撃者が Vercel のどの内部システムまたはデータにアクセスしたのかは不明です。
検知およびハンティングのガイダンス
このセクションでは、本インシデントの影響を受けた可能性がある組織向けに、実践的な検知およびハンティングのガイダンスを提供します。
Vercelをご利用のお客様向け（緊急）
1. すべての環境変数を監査し、以下のコードをVercelプロジェクトで実行して設定を確認します
# CLIを使用して、すべてのVercelプロジェクトのenv varを一覧表示
vercel env ls --environment production
vercel env ls --environment preview
vercel env ls --environment development
# sensitiveとしてマークされていない変数を確認
# （現時点ではVercel CLIはsensitiveフラグを表示しないため、
# ダッシュボードまたはAPIで確認してください）
2. 公開された認証情報の不正使用を検索します
- 予期しないIPレンジまたはユーザエージェントから、公開されたアクセスキーを使用して実行されたAPIコールについて、クラウドプロバイダのCloudTrail / 監査ログを照会します。
- AWS CloudTrail: eventSource に sts.amazonaws.com、iam.amazonaws.com、s3.amazonaws.com を含むイベントで絞り込みます。ローテーション対象となったVercel保存済みアクセスキーのいずれかに一致する userIdentity.accessKeyId を検索します。既知のCIDRレンジ外の sourceIPAddress、または python-requests、curl、Go-http-client、もしくは見覚えのない自動化文字列を含む userAgent をフラグ付けします。対象期間: 2024年6月～現在。
- GCP Audit Logs: キーがVercelに保存されていたサービスアカウントについて、protoPayload.authenticationInfo.principalEmail を照会します。protoPayload.requestMetadata.callerIp を既知のレンジに対してフィルタします。予期しない送信元からの storage.objects.get、compute.instances.list、iam.serviceAccountKeys.create を含む protoPayload.methodName を確認します。
- Azure Activity Logs: 認証情報がVercelの環境変数に含まれていたアプリケーションIDまたはサービスプリンシパルに一致する caller で絞り込みます。想定レンジ外の callerIpAddress をフラグ付けします。優先して確認するクエリ: Microsoft.Storage/storageAccounts/listKeys、Microsoft.Compute/virtualMachines/write、Microsoft.Authorization/roleAssignments/write。
- データベースアクセスログ: 接続文字列がVercel環境変数として保存されていたすべてのデータベースについて、漏洩期間全体（2024年6月～2026年4月）の接続ログを照会します。アプリケーションの既知の送信元レンジ（Vercel edge IP、VPN、オフィス）外のIPから開始された接続を検索します。通常のデプロイ時間帯以外に、公開された認証情報を使って行われた接続をフラグ付けします。PostgreSQLでは pg_stat_activity と log_connections ログを照会します。MySQLでは general log または audit plugin を照会します。MongoDB Atlasでは、未知のIPからの DATA_EXPLORER および CONNECT イベントについて Project Activity Feed を照会します。
- 決済代行サービス: Stripeでは、公開されたキーを使用したAPIコールについて Dashboard → Developers → Logs を確認します。サーバ以外の source_ip でフィルタします。認識できない /v1/charges、/v1/transfers、/v1/payouts、/v1/customers のコールを確認します。Braintree / Adyen については、同等のAPIトランザクションログを照会します。優先対象: Vercelに非sensitiveな環境変数として保存され、まだローテーションされていない api_key。メール送信サービスのログについても、想定外の送信がないか監査します。
- 漏洩した認証情報に関する未承諾の通知が、漏洩期間中にOpenAI、Anthropic、GitHub、AWS、Stripeなどのプロバイダから届いていないか確認します。これらの自動検知システムは、現在、この種の侵害に対する主要な早期警告チャネルとなっています。
3. ローテーションを実施し、必ず再デプロイします
重要な運用上の注意点として、Vercel環境変数をローテーションしても、過去のデプロイはさかのぼって無効化されません。Vercelのドキュメントによると、以前のデプロイは再デプロイされるまで、引き続き古い認証情報の値を使用します。
再デプロイを行わずにローテーションだけを実施すると、到達可能な過去のデプロイ成果物内で侵害済みの認証情報が引き続き有効なままになります。認証情報をローテーションした後は、その変数を使用していたすべての環境を必ず再デプロイするか、古いデプロイを明示的に無効化する必要があります。
- ローテーションの優先順位:
- クラウドプロバイダの認証情報（AWS、GCP、Azure）。
- データベース接続文字列。
- 決済代行サービスのキー。
- 認証シークレット（JWTシークレット、セッションキー）。
- サードパーティAPIキー。
- モニタリングおよびロギングのトークン。
セキュリティチーム向け（プロアクティブ）
OAuth アプリケーションの監査 — Google Workspace
- 管理コンソール → セキュリティ → API の制御 → サードパーティ製アプリのアクセス
- 承認済みの OAuth アプリケーションをすべて確認します。
- 広範なスコープ（Drive、Gmail、Calendar）を持つアプリケーションを特定します。
- 現在取引関係のないベンダーのアプリケーションを調査します。
- 想定外の IP 範囲からの OAuth トークン使用を監視します。
- 既知の不正な OAuth Client ID を検索します:
- 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
SIEM 実装のための検知ロジック
以下の検知パターンは、確認済みの攻撃チェーンの各段階に対応しています。各パターンでは、観測可能な挙動、計測対象とするログソース、および調査を開始すべき条件を示します。組織は、各自のログソーススキーマに照らしてフィールド名を検証したうえで、これらを自組織の SIEM プラットフォーム（Sigma、Splunk SPL、KQL、Chronicle YARA-L）に対応したルールへ変換する必要があります。
OAuth アプリケーションの異常（ステージ1～2）
Google Workspace のトークン監査ログおよび管理者監査ログで、3つのパターンを監視してください。まず、既知の不正な OAuth Client ID（110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com）に関連するトークンのリフレッシュまたは認可イベントは、直ちにアラートを発する必要があります。これは侵害された Context.ai アプリケーションです。
次に、広範なスコープ（メールへのフルアクセス、Drive の読み取り／書き込み、カレンダーアクセスを含む）を付与する OAuth アプリケーションの認可イベントは、現在有効なベンダーインベントリと照合して確認する必要があります。現在ビジネスで使用されていないアプリケーションは、認可を取り消してください。3つ目として、認可済み OAuth アプリケーションからのトークン利用で、送信元 IP が想定される社内およびベンダーの CIDR 範囲外である場合は、調査対象としてフラグを付けてください。これは、トークンの窃取またはアプリケーション侵害を示している可能性があります。
内部システムへのアクセスとラテラルムーブメント（ステージ3、T1078）
攻撃者が侵害された Google Workspace アカウントを掌握すると、そのアイデンティティを信頼する内部システムへと横展開します。検知は次の4つの指標に重点を置く必要があります。
- 異常な SSO／SAML 認証イベント。侵害された Workspace アカウントが、見慣れない IP アドレス、地理的位置、またはデバイスフィンガープリントから内部アプリケーション（Vercel ダッシュボード、CI/CD プラットフォーム、内部ツール）に認証しているかどうかを、ID プロバイダのログで監視してください。特に、そのアカウントがこれまで一度もアクセスしたことのないシステムへの初回アクセスに注意してください。
- メールおよび Drive の認証情報収集。Google Workspace の監査ログを確認し、大量のメール検索クエリ（「API key」「secret」「token」「password」「.env」などのキーワード）、異常な Google Drive ファイルアクセスパターン（共有認証情報ストア、エンジニアリング運用手順書、またはインフラ文書のオープン）、および侵害されたアカウントでのメール転送ルール作成を確認してください。
- OAuth 連携された内部ツールへのアクセス。侵害された Workspace アイデンティティには、内部ツール（Slack、Jira、GitHub、内部ダッシュボード）への既存の OAuth 付与がある可能性が高いです。これらの下流サービスにおいて、侵害されたユーザに関連付けられたセッション作成または API アクティビティが、通常の勤務時間外、またはそのユーザの過去のアクセスパターンと一致しないインフラから発生していないかを監視してください。
- 権限昇格の試行。侵害されたアイデンティティが、より高い権限を要求する、新しいグループやロールに参加する、またはこれまで利用していなかった管理コンソールにアクセスする動きがないかを監視してください。特に Google Workspace では、Directory API 呼び出し、委任設定の変更、または他のユーザの OAuth トークンを列挙しようとする試みを監視してください。
環境変数の列挙（ステージ4）
環境変数へのアクセスに関する異常なパターンについて、Vercel のチーム監査ログを監視します。具体的なイベント種別は Vercel の監査ログスキーマに依存しますが、対象となる挙動は、通常のデプロイ活動と整合しない件数または頻度で環境変数を読み取り、一覧表示、または復号する API コールです。
まず通常のデプロイ頻度をベースライン化してください。CI/CD パイプラインはビルド時に正当に環境変数を読み取ります。そのうえで、件数、タイミング、または送信元 ID の観点でそのベースラインから逸脱するアクセスパターンに対してアラートを設定します。特に、サービスアカウントではなくユーザアカウントに起因する環境変数アクセス、またはアクセス対象のプロジェクトと通常やり取りしないアカウントからのアクセスには注意を払ってください。
下流の認証情報の不正利用（ステージ5）
漏洩期間中（2024 年 6 月～2026 年 4 月）に機微ではない Vercel 環境変数として保存されていたすべての認証情報について、対応するサービスのアクセスログを照会し、想定外の送信元からの利用がないか確認してください。AWS では、これは特定のアクセスキー ID で絞り込んだ CloudTrail クエリを意味し、既知のアプリケーション、CI/CD、および社内ネットワークの範囲外の IP アドレスからの API コールを確認します。
GCP および Azure では、これに相当するのは、関連するサービスアカウントまたはアプリケーション ID で絞り込んだ監査ログクエリです。SaaS API（Stripe、OpenAI、Anthropic、SendGrid、Twilio）については、アプリケーションが稼働していなかった時間帯、または認識できない IP からのキー利用がないか、プロバイダのダッシュボードまたは API ログを確認してください。自社インフラによるものと特定できない利用が見られる認証情報は、侵害されたものとして扱い、直ちにローテーションを実施し、攻撃者がその認証情報を使ってどのような操作を行ったのか調査する必要があります。
サードパーティの認証情報漏洩通知
GitHub（secret scanning partner program）、AWS（compromised key detection）、OpenAI、Anthropic、Stripe、Google Cloud など、自動シークレットスキャンを実施しているプロバイダからの、未依頼の認証情報漏洩通知を監視するよう設定してください。これらの通知は現在、プラットフォームレベルでの認証情報露出に対する主要な早期警戒チャネルとなっています。デプロイプラットフォームにのみ存在するキーに対するこの種の通知は、通常のキー衛生管理上のノイズではなく、プラットフォーム侵害の潜在的な兆候として扱うべきです。
脅威ハンティング
Google Workspace 管理コンソール — 手動検索手順：
- 管理コンソール → レポート → 監査と調査 → OAuth ログイベント
- フィルタ: アプリケーション名 = "Context.ai" または クライアント ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
- 日付範囲: 2024年1月 ～ 現在
- すべての結果をエクスポートします。該当が1件でもあれば、直ちにアクセスを取り消し、インシデント調査を実施します。
Google Workspace — 広範なスコープを持つすべてのサードパーティ OAuth アプリ：
- 管理コンソール → セキュリティ → API の制御 → サードパーティ アプリのアクセス → Google サービスを管理
- 並べ替え: "アプリのアクセス" → "制限なし"
- 各アプリについて、(a) 現在有効なベンダーとの関係が存在すること、(b) スコープが業務用途に照らして正当であること、(c) 最終利用日が最近であることを確認します。90日以上使用されていないアプリは、アクセスを取り消します。
- アクセスされたと考えていない場合であっても、機密としてマークされていなかった Vercel のすべての環境変数をローテーションします。不必要なローテーションのコストは、認証情報が侵害された場合のコストと比べればごくわずかです。
- ローテーション後は、すべての環境を再デプロイします。ローテーションだけでは、古いデプロイは無効になりません。
- 認証情報、トークン、キー、またはシークレットを含むすべての環境変数で、sensitive フラグを有効にします。すべてのプロジェクトを監査します。
- Google Workspace（または Microsoft Entra）の管理コンソールで、OAuth アプリケーションの認可を監査します。現在アクティブに使用されていないアプリケーションのアクセスは取り消します。
- Vercel の環境変数に認証情報が保存されていたすべてのサービスについて、2024年6月から現在までの期間を対象にアクセスログを確認します。
短期的なハードニング（1～4週間）
- シークレットを専用のシークレットマネージャー（HashiCorp Vault、AWS Secrets Manager、Doppler、Infisical）に移行します。プラットフォームの環境変数として保存するのではなく、実行時にシークレットを注入します。
- サポートされている場合は、CI/CDおよびデプロイパイプラインにOIDCベースの認証を実装し、長期利用される認証情報を完全に排除します。
- OAuthアプリケーションの監視を導入します。商用ソリューション（Nudge Security、Grip Security、Valence Security）または Google Workspace の組み込みOAuthアプリ管理を利用します。
- 認証情報ローテーションの自動化を確立します。シークレットは、インシデントの有無にかかわらず、定義されたスケジュール（30～90日）でローテーションする必要があります。
- OAuth許可をベンダーとの関係として扱います。契約済みベンダーとあわせて、サードパーティリスクのインベントリに追加します。
アーキテクチャ上の変更（1～6か月）
- 環境変数に対してゼロトラストの姿勢を採用します。デプロイプラットフォームに保存されたあらゆるシークレットは、プラットフォームレベルの侵害で露出する可能性があると想定します。単一の認証情報の露出が連鎖的な被害につながらないようにシステムを設計します。
- すべての認証情報に対して最小権限のスコープ設定を実装します。データベース認証情報には必要最小限の権限のみを付与し、APIキーは特定の操作に限定してスコープを設定し、クラウド認証情報は長期利用されるアクセスキーではなく、ロールベースの一時的な認証情報を使用します。
- 企業のIDシステムにアクセスするOAuthアプリケーションまたは統合については、サードパーティベンダーのセキュリティレビューを確立します。既存の許可に対する定期的な再レビューも含めます。
- PaaSプラットフォームをSBOM/ASPMインベントリに含めます。この侵害事案は、デプロイプラットフォームを外部サービスではなく、ティア1のサプライチェーン依存関係として扱うべきことを示しています。
推奨される監視
- 上記のOAuthクライアントIDについて、Google Workspace Admin Console を監査します。
- 想定外の env.read または env.list API呼び出しがないか、Vercel の監査ログを監視します。
- 2024年6月～2026年4月の期間中に、想定外のIPまたはユーザエージェントから、Vercel の環境変数として保存されていた認証情報が使用されていないか、CloudTrail、GCP Audit Logs、Azure Activity Logs を確認します。
- 依存関係ツリーにそれらのパッケージが含まれている場合は、それぞれのアドバイザリで公開されているLiteLLMまたはAxios関連のIOCを監視します。
- 露出期間中は、主要なAPIプロバイダからの未依頼の漏洩認証情報通知に注意します。
- GDPR（EU）: 露出した認証情報によってEUの個人データを含むシステムにアクセスできた場合、露出が確認された時点で72時間以内の侵害通知の期限が開始していた可能性があります。4月10日のOpenAIによる通知は、一部の組織における認識時点が、Vercelの4月19日の開示より前であった可能性を示しています。
- CCPA/CPRA（カリフォルニア州）: 消費者データへのアクセスを可能にする認証情報の露出は、通知要件を発動させる可能性があります。
- PCI DSS: 決済処理業者の認証情報（Stripe、Braintree、Adyen）が露出していた場合、PCIのインシデント対応手順およびフォレンジック調査要件が適用される可能性があります。
- SOC 2: SOC 2上の義務を負う組織は、インシデント、実施した認証情報のローテーション対応、および更新した統制を継続的モニタリングの証跡に文書化する必要があります。
- SECサイバーセキュリティ規則（8-K）: 上場企業が当該侵害を重要性があると判断した場合、4営業日以内に開示する義務があります。
- LiteLLM: CI/CD認証情報が盗まれる → 悪意のあるパッケージが開発者のシークレットを大規模に収集。
- Axios: メンテナアカウントが乗っ取られる → RATが数百万の開発者環境に展開。
- Vercel: OAuthアプリケーションが侵害される → 顧客のデプロイ用シークレットへのプラットフォームレベルのアクセスが発生し、少なくとも1件の公開レポートでは、開示前に下流側の認証情報悪用が実環境で検出されていたことが示唆されています。
それぞれの攻撃は、ソフトウェアサプライチェーンの異なるつながりを標的にしています。これらを総合すると、認証情報が普遍的な標的であり、信頼関係が普遍的なアタックサーフェスであるエコシステムの姿が浮かび上がります。業界が警鐘を鳴らしてきた連鎖的被害は、もはや単なる理論ではありません。
防御に向けた道筋は、容易ではないとしても明確です。
- プラットフォームの環境変数に長期間有効な認証情報を保存することをやめてください。実行時インジェクションに対応した専用のシークレットマネージャーを使用してください。
- OAuthアプリケーションを暗黙的に信頼することをやめてください。監査、監視、および定期的な再認可を実施してください。
- プラットフォームプロバイダーの内部セキュリティ態勢を前提にすることをやめてください。侵害されるシナリオを前提に設計してください。
- 認証情報のローテーションを積極的に開始してください。そして、その後の再デプロイも忘れないでください。
- サードパーティプロバイダーからの認証情報漏洩通知は、定型的なノイズではなく、優先度の高い早期警戒シグナルとして扱ってください。
参考記事
The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables
By: Peter Girnus
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）