AI開発ツール自体が攻撃面になった日 第1回:Vercel事件 — サードパーティAIツールが侵入経路になった

連載③が始まります。

連載①「vibe codingの代償」では、AIが作ったアプリが現実に何を漏洩させたのかを扱いました。Moltbook、Lovable、Replit——いずれも「AIで作られたもの」が事故を起こした事例でした。連載②「AIエージェント時代の権限設計」では、AIエージェントを準社員として認知・管理する4層の設計処方を組み立てました。両者を貫いたのは「組織内部の運用と防御」という主題です。

連載③が扱うのは、これとは別レイヤの問題です——AI開発ツールそのものが攻撃面になったという現実。

攻撃者はもはや、私たちが作ったアプリを狙うだけではありません。私たちが日常的に使っているAIツール、開発エコシステムそのものを狙い始めています。アプリが壊れて漏洩するのではなく、開発者が信頼しているツールが、そのまま侵入経路になる。「漏洩した側」ではなく「漏洩させる側」になるリスクが、開発者個人の机の上に降りてきています。

この連載は5回構成で、2026年4月の3週間で連続発生した3つの事件を時系列で解剖します。

• 第1回(本記事):Vercel事件(4月19日公開)——サードパーティAIツールが侵入経路になった
• 第2回:Bitwarden CLI事件(4月22日)——マルウェアがAIコーディングツールを名指しで狙い始めた
• 第3回:SAP CAP事件(4月29日)——Claude CodeのGitHub連携がそのまま侵入路になった
• 第4回:MCP設定ファイルは「攻撃者の地図」である——AIエージェント設定の永続化と伝播
• 第5回:開発者個人=組織境界の時代——個人のmacBook 1台が組織のサプライチェーンになる

連載①と連載②が日本企業の経営層・アーキテクトに向けた処方箋だったのに対して、連載③は技術リーダー・セキュリティ担当・脅威インテリジェンスの専門職に向けた、より深い領域の議論です。読者層は狭くなりますが、刺さる層には深く刺さる構造で書きます。

第1回は、「AIツールに付与したOAuth権限が、組織の認証境界そのものを侵食した」という認識転換を扱います。

1. 何が起きたのか — タイムラインの再構成

公開情報から再構成すると、Vercel事件は3か月にわたる多段階の侵害でした。4月19日の公開は、その最終局面に過ぎません。

注目すべきは、初期感染から公開まで約2か月のドウェルタイム(滞在時間)があったことです。Context.aiは3月にAWS侵害を検知してOAuthアプリを停止しましたが、その時点でOAuthトークンの流出は把握していませんでした。OAuthトークンの不正利用は、Vercel側の調査によって逆方向から発覚した——Context.aiが自社の侵害範囲を完全に把握できていなかったことを意味します。Vercelは外部調査会社としてGoogle傘下のMandiantを起用し、Context.aiは独立にCrowdStrikeにフォレンジック調査を依頼しました——同一の事件に対して2つの大手インシデントレスポンスチームが別々の角度から動いた、ということになります。

攻撃チェーンを図にまとめると、こうなります。

ここで重要なのは、攻撃が直接的なVercel侵害ではなかったことです。Vercelの境界(ファイアウォール、ネットワーク、認証システム)は破られていません。攻撃者は正規のOAuth信頼関係を継承することで、認証境界を迂回しました。

2. OAuth信頼関係という盲点

OAuthは「Login with Google」「Connect to Google Workspace」といった連携ボタンの背後で動く認可プロトコルです。SAML/OIDCと並んで、SaaS連携の事実上の標準。技術的には完成されており、設計上の脆弱性はありません。

問題は、OAuthが想定していなかった運用パターンにあります。

OAuthトークンには、いくつかの特性があります。

• 持続的アクセス:一度発行されると、明示的に取り消されるまで有効。多くのトークンは事実上無期限
• 再認証不要:トークン保持者は再認証(MFA含む)なしにAPIにアクセスできる
• 広範囲のスコープ:Allow All のような包括的同意で、Drive・Gmail・Calendarへのフル読み取り権限が一度に付与される
• 転送可能:トークン文字列を盗まれれば、攻撃者が正規ユーザーとして振る舞える

そして、AIツールはこの特性すべてを活用するように設計されています。AIツールが「あなたのDocsを要約する」「あなたのCalendarから会議をまとめる」「あなたのSlackから情報を引く」を実現するには、広範囲のOAuth権限が必要です。これは設計の必然であって、悪意ではありません。

ただし、この必然が、OAuthアプリ自体が侵害された場合の被害規模を爆発的に拡大します。

The Hacker Newsが報じたOX Securityの分析によれば、Vercel従業員がContext.aiのChrome拡張機能をインストールしてエンタープライズGoogleアカウントでサインインしたことが起点でした。Context.aiの公式報告は、より厳しい指摘を行っています——「Vercel社内の認可設定が、この操作によって、Vercelエンタープライズ Google Workspaceへの広範な権限の付与を許可していた」。つまり、Vercel従業員1人の判断が、組織全体のOAuth信頼境界を更新できる設計だった、ということです。

これは、Vercel固有の問題ではありません。多くの組織で、従業員が個別にOAuth同意を行える設定が、デフォルトのまま運用されています。Awarewaysの2025年調査ではAIツールがIT部門に可視化されている割合は11%以下、Netskopeの2026年調査では47%が個人アカウント経由でgenAIにアクセスしている——連載②第5回で見たシャドーAI統制の数字が、OAuth侵害経路としても効いてくるわけです。

連載②第1回で「識別なき主体を権限の対象にしてはならない」と書きました。この命題は、組織内部のAIエージェントだけでなく、外部のSaaSアプリにOAuth経由で付与する権限にも、そのまま適用されます。Context.aiは、Vercelから見れば、識別が確立されていない準社員(NHI)に膨大な権限を持っていた、ということです。

3. 「非機密」というラベルの罠

OAuth経由でVercel社内環境に侵入した攻撃者は、もう一つの設計判断を悪用しました。Environment variablesの「sensitive / non-sensitive」分類です。

Vercelは顧客の環境変数を保管・暗号化する仕組みを持っています。Rauch CEOがX投稿で明確に説明した通り——

Vercel stores all customer environment variables fully encrypted at rest. We have numerous defense-in-depth mechanisms to protect core systems and customer data. We do have a capability, however, to designate environment variables as "non-sensitive". Unfortunately, the attacker got further access through their enumeration.

要点を整理すると:

• すべての環境変数が暗号化保存される(Rauchの最初の主張)
• ただし、「non-sensitive」と明示的にマークすると、復号可能な状態でストレージされる(同じ平文に戻せる仕様)
• 攻撃者はこの「非機密」とラベル付けされた変数を列挙し、復号した
• 「非機密」変数の中に、APIキー・トークン・データベース認証情報・署名キーが含まれていた

ここに「ラベルの罠」があります。「non-sensitive」というラベルは、本来は「ビルド時に必要だが秘密ではない値(例:NODE_ENV=production、PUBLIC_API_URL)」を想定していました。しかし、開発の現場では、何を機密とすべきかの判断が個別開発者に委ねられているため、APIキーが「非機密」に分類されることが日常的に起きていました。

連載①第1回で立てた命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——を、ここで開発者の判断に置き換えて読むと、こうなります:開発者は「動かす」ための判断は速いが、「守る」ための判断は後回しにされやすい。Vercelの設計は、この人間側の弱点を増幅していました。

Trend Microの分析が指摘するのは、「プラットフォーム境界を制御だと期待していた前提が、技術的に間違っていた」という構造的問題です。Vercelの内部では、「sensitive」と明示しない限り、変数は内部アクセス権を持つアクターから読める状態だった。これは設計判断ですが、外部から見たとき、その判断は顧客に十分に説明されていなかった——多くの顧客は、Vercelに保管した環境変数はすべて暗号化・隔離されている、と理解していました。

Vercelは事件後、新規環境変数のデフォルトを「sensitive」に変更し、「team-wide management and security overview of environment variables」を導入しました。これは正しい修正ですが、事後実装であることが重要です。連載②第1回でCisco CPO Jeetu Patelが指摘した「85%が実験中・5%のみ本番運用」のギャップは、こうした「セキュリティ設計判断の事後修正」の連鎖として、業界全体に蓄積されています。

4. 「AIで加速された」攻撃の意味

Rauch CEOの発言で最も注目された一節がこれです。

We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel.

「AIによって有意に加速された」「驚くべき速度と、Vercelに対する深い理解」——この2つの観察は、AIが攻撃者側に渡ったときに何が変わるかを示唆しています。

Strobesの分析が整理する通り、AIで加速された攻撃者の特徴は、単に「ツールが速くなった」ことではありません。Kill chainの各フェーズが圧縮されることです。

• 偵察(Reconnaissance):従来は数日の手動列挙が必要だった。AIで自動化・並列化される
• 横展開(Lateral Movement):従来は人間の判断が必要だったルート選択が、環境パターンを認識し高価値ピボットを予測するモデルで駆動される
• 意思決定:Context.ai→OAuth→Google Workspace→Vercel→環境変数列挙の各段階で、機械速度の判断が連続する

ここで決定的なのは、防御側のincident responseが「人間の速度」を前提に設計されていることです。SIEMのアラート、SOCのトリアージ、エスカレーション、対応チームの招集——これらすべてが、攻撃者が人間の意思決定速度で動くことを暗黙の前提にしています。AIで加速された攻撃者は、SIEMが異常を検出する前に、すでに横展開を完了している可能性があります。

これは連載①第4回(Replit事件)で扱った「AIは確率最大化の装置である」という命題の、攻撃者側からの応用です。連載①第4回では、Replitエージェントが「動く」ように最適化された結果、Lemkin氏の本番DBを破壊した事例を扱いました。同じ最適化のメカニズムが、攻撃者側のオフェンシブツールに搭載されると、動かす速度がそのまま侵害の速度になるわけです。

ただし、Rauchの発言には注意が必要です。これはVercel CEOの観察(I strongly suspect)であって、技術的な確証(forensic evidence)ではありません。攻撃者がAIを使ったかどうかを、外部から確実に判定する手法は、現在のところ確立されていません。

それでも、観察された行動パターン(velocity、in-depth understanding、operational tempo)は、AIを用いない人間の攻撃者の典型的なパターンと比較したとき、有意に逸脱していました。Vercel側の調査はGoogle傘下のMandiantが担当しているため、後日より技術的な分析が公表される可能性があります。本記事執筆時点(2026年5月8日)では、Vercelは「ad hoc cadence for Security Bulletin updates」に移行しており、調査は継続中です。

5. 単発ではない — Salesloft Drift事件との構造的相似

Vercel事件は、単発ではありません。直接の前史があります——2025年8月のSalesloft Drift事件(UNC6395)です。

複数の専門ベンダー報告と一次資料から、事件の規模を整理します。

• 時期:2025年8月8〜18日(10日間で集中的な攻撃)
• 侵害対象:Salesloftの開発環境(GitHub、AWS)
• 窃取:Drift統合のOAuthトークン(Salesforce連携で使用されるもの)
• 影響範囲:700+組織(Cloudflare、Google、Palo Alto Networks、Zscaler、CyberArk、PagerDuty、Proofpoint等のセキュリティ大手を含む。詳細はAnomaliの分析レポート、Cloud Security Allianceのクロス業界教訓レポート)
• 窃取データ規模:BleepingComputerが報じた通り、ShinyHuntersが「760組織から15億レコード窃取」を主張。これは攻撃者の主張であり、Salesloft・Salesforceは公式に数値を認めていない。ただしBleepingComputerは情報源を「accurate」と評価
• 二次攻撃:2025年11月にGainsightアプリ経由で同様パターンが再発、約200社への波及

UNC6395の手口を、Vercel事件と比較すると、構造がほぼ同型だとわかります。

両事件に共通する設計欠陥は、3つあります。

欠陥1:OAuthアプリ自体が攻撃面である

連載②第1回でNHI(Non-Human Identity)を論じた際、典型例として挙げたのが「OAuthアプリ・SaaS統合」でした。Salesloft Drift事件は、この典型例が実際に侵害された場合の被害規模を初めて大規模に示しました。Vercel事件は、同じ構造がAIツールに移植された事例です。

欠陥2:OAuthトークンに有効期限管理がない

CrowdStrike 2026 Global Threat Reportが指摘するのは、SaaSとCI/CDレイヤが、エンドポイントに比べて監視が手薄である一方、保有する情報密度ははるかに高いこと。OAuthトークンが事実上無期限であることが、攻撃者の滞在期間と被害規模を増幅します。SANS 2026 Identity Threats & Defences Surveyでは、92%の組織が90日サイクルの機械認証情報ローテーションに失敗しています(連載②第1回で引用済)。

欠陥3:SaaS-to-SaaS連鎖の可視性がない

Wing Securityが整理する通り、典型的な企業環境では、Google Workspace/Microsoft 365の主アプリから、何百ものサードパーティSaaSへOAuth連携が伸びています。これらの間接的な連携——SaaS A → SaaS B → SaaS C——は、ID基盤の管理画面からは見えにくく、可視性が極端に低い。攻撃者は、この見えない経路を辿ります。

IBM 2026 X-Force Threat Intelligence Indexは、この傾向を数字で裏付けています——公開アプリの悪用を起点とする攻撃が前年比44%増、2025年に30万件以上のChatGPT認証情報が地下市場で販売。Salesloft Drift事件→Vercel事件の連続は、「単発の侵害」ではなく「OAuthサプライチェーン攻撃のシリーズ」として読むべきです。

6. AI開発エコシステム時代の新しい攻撃面

Vercel事件が示すのは、従来のサプライチェーン攻撃と質的に異なる新しい攻撃面の出現です。

伝統的なサプライチェーン攻撃(Codecov、SolarWinds、CircleCI)は、ソースコード/ビルドパイプラインを経由しました。攻撃者は、開発者が実行するコードに悪意あるバイトを混入させ、最終成果物経由で被害を広げました。これに対する防御は、コード署名・SBOM・ビルド検証といった、コード中心の対策に集約されてきました。

ところが、AI開発エコシステムの攻撃面は、コード経由ではありません。

新しい攻撃面の特徴は、3つに整理できます。

特徴1:身元を装う必要がない

伝統的なサプライチェーン攻撃では、攻撃者は何らかの形で「身元を偽装」する必要がありました。npmパッケージのtypo squatting、CIランナーの正規ユーザー振り、コミット署名の偽造——いずれも「正規アクター」を装うコストがかかりました。

OAuthトークン窃取は、このコストを払う必要がありません。OAuthトークンの保持者は、定義上、正規ユーザーです。Context.aiが正規にVercelからもらった権限を、攻撃者がそのまま継承しただけ。装う必要も偽造する必要もありません。

特徴2:AI機能のために広範な権限が必須

伝統的な「最小権限の原則」は、機能と権限のトレードオフを慎重に管理することで成立していました。連載②第2回で論じた3カテゴリ分離(削除・外部送信・金融)は、この古典原則のAIエージェント版です。

ところが、AIツールは機能の本質が「広範な権限」にあります。「あなたのGoogle Driveのすべてを読み取って要約する」「あなたのCalendarすべてを見て会議調整する」——これらの機能を実装するには、最小権限のロジックでは到達できない範囲のスコープが必要です。AIツールは、最小権限の原則と本質的に矛盾する機能要件を持っています。

特徴3:「使う側」と「作る側」の境界が曖昧

連載②までは、自社が「使う側」(AIエージェントを送り出す)か、「作る側」(他社が使うAIツールを提供する)か、の区別が比較的明確でした。Vercelは「Vercelプラットフォームを使う側」と「Vercelプラットフォームを提供する側」の両方の役割を持っています——Context.aiを使うエンドユーザーであり、同時にCustomer環境を保護するプロバイダーでもあります。

Kiteworksの分析が引用するDTEX 2026 Insider Threat Reportは、この曖昧化を数字で示しています——92%の組織が「genAIが情報共有のあり方を変えた」と回答する一方、わずか13%が「AI利用をセキュリティ戦略に統合できた」。AIツール採用とAIガバナンスのギャップが、「使う側」の脆弱性が「作る側」の事故に直結する経路を作っています。

7. 教訓 — AI連携OAuthの認証境界の見直し

Vercel事件から導かれる、組織レベルの対応は7つに整理できます。連載②第1〜4回の処方を補完する形で、「外部AIツールに対するOAuth境界」の設計判断を加える必要があります。

1. OAuthアプリのインベントリ化

Google Workspace管理コンソール / Microsoft Entra IDのサードパーティアプリアクセス管理画面で、現在組織が信頼しているOAuthアプリの全件棚卸しを行います。多くの組織で、想像の3〜10倍のアプリが信頼関係を持っています。Vercel事件のIOC(110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com)を起点に、類似の小規模AIツールの存在を確認するのが、最初の一歩です。

2. OAuthスコープの過剰付与レビュー

特に「Allow All」「全ファイル読み取り」「メール全文アクセス」を要求するアプリは、機能要件の妥当性を再評価します。AIツールの多くが「あったほうが便利」のレベルで広範な権限を要求します。BleepingComputerが指摘する通り、default-deny アプローチ——ユーザーが新しい統合に同意できる権限を、デフォルトで管理者承認制にする——を主要エンタープライズクラウドで採用するのが、現時点のベストプラクティスです。

3. シャドーAIサインアップの正規ルート確立

連載②第5回で論じた「Discover/Govern/Enable」フレームワークの実装。従業員が「このAIツールを使いたい」と表明できる経路を作り、シャドーOAuth同意が静かに蓄積する状況を解消します。Healthcare Brew 2026の調査が示した「承認代替手段提供で未承認利用が89%減」は、シャドーAIにもOAuth侵害経路にも同じ効果を持ちます。

4. 環境変数の機密分類のデフォルト変更

Vercelが事件後に実装した「sensitive」をデフォルトにする方針は、他のPaaS/CI/CD基盤にも展開すべき判断です。AWS Secrets Manager、HashiCorp Vault、Doppler等の専用シークレット管理を使っている組織は、プラットフォームの環境変数機能には機密情報を保管しない運用ルールを徹底します。Varonisの実装ガイドが示す通り、Vercel環境にシークレットを保管している組織は、事件直後の優先順位として「すべての環境変数を侵害済みと見做して即座にローテーション」を実施すべきです——クラウドキー(AWS、Azure、GCP)→ DB認証情報 → GitHubトークン → その他、の順で。

5. OAuthトークンの定期ローテーション

NHIのライフサイクル管理(連載②第1回)を、外部OAuthアプリにも拡張します。SANS 2026調査の92%が90日ローテーションに失敗している現状は、自動化されたローテーション基盤がなければ達成できないことを示しています。手動運用のままでは、機械認証情報は事実上永続化します。

6. 異常なOAuth振る舞いの監視

Trend Microが指摘するT1199(Trusted Relationship)→T1078(Valid Accounts)のピボットが、検出の最も重要なポイントです。具体的には、以下のような指標を監視します。

• 既存OAuthアプリが、これまでとは異なるIPレンジからアクセスしている
• アプリが期待されるスコープ範囲外のリソースに触れようとしている
• アプリが異常な時刻(深夜・週末)にバースト的にAPIを叩いている
• 同一OAuthトークンが地理的に矛盾する場所から短時間に使われている

CASB(Cloud Access Security Broker)とSSPM(SaaS Security Posture Management)の組み合わせが、現時点で最も実用的な検出基盤です。

7. インシデントレスポンス前提の見直し

Rauchの「significantly accelerated by AI」観察は、従来のレスポンスplaybookの前提が崩れている可能性を示唆します。アラート閾値、レスポンス時間目標、エスカレーションフロー——これらを機械速度の攻撃者を想定して再設計する必要があります。Trend Microが指摘する通り、「人間ペースの攻撃者を想定したdwell time仮定」は、AI支援攻撃者には通用しません。

まとめ

連載③第1回として、Vercel事件を扱いました。

事件の本質は、サードパーティAIツール(Context.ai)に付与されたOAuth権限が、Vercel組織の認証境界そのものを侵食したことです。Vercelは直接攻撃されていません。境界も破られていません。攻撃者は、正規のOAuth信頼関係を継承し、機械速度で横展開しました。

この攻撃面は、伝統的なサプライチェーン攻撃と質的に異なります。コード経由ではなく、ID信頼経由。身元を装う必要はなく、正規アクターとして振る舞える。最小権限の原則と矛盾する広範な権限が機能要件になっている。「使う側」と「作る側」の境界が曖昧になっている。

そして、これは単発ではありません。2025年8月のSalesloft Drift事件(UNC6395、700+組織、ShinyHuntersは15億レコード窃取を主張)、2025年11月のGainsight事件、2026年4月のVercel/Context.ai事件——OAuthサプライチェーン攻撃のシリーズとして、CrowdStrike 2026 Global Threat Reportが2025-2026年の主要トレンドに位置づけている流れです。

連載①第1回で立てた命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——は、開発者の判断にも、AIツールの設計にも、OAuth権限の付与にも、すべて適用できます。Vercel従業員1人がContext.aiに「Allow All」を許可した瞬間に、組織全体の認証境界が更新された。これは、動かすための判断が先行し、守るための判断が後追いだった結果です。

連載②第1回で立てた命題——「識別なき主体を権限の対象にしてはならない」——は、自社が運用するAIエージェントだけでなく、外部から自社にOAuth経由で接続するSaaSアプリにも同じ強度で適用すべきです。Context.aiは、Vercelから見れば識別が確立されていない準社員(NHI)に膨大な権限を持っていました。連載②で扱った4層構造の処方が、外部OAuthアプリにも拡張される必要がある——これがVercel事件が組織にもたらす最大の認識転換です。

そして、Rauch CEOの「significantly accelerated by AI」発言は、攻撃者側にもAIが渡った現実を示します。連載①と連載②が、組織が運用するAIエージェントの設計責任を論じてきたのに対して、連載③からは、攻撃者の側でも同じテクノロジーが武器化されている前提に立たなければなりません。連載①と連載②の処方は、すべて機械速度の攻撃者を想定したアップデートが必要です。

書き手として一つ記しておきたいのは、Vercelは私たちunTypeも本番運用で使っているプラットフォームだ、ということです。この事件は「他社の事故」ではなく、自社のスタックの一部で起きた事故として、私たちは受け止めました。事件後、unType社内でも、Vercel環境変数のsensitive分類を全件レビューし、不要なOAuth連携を整理しました。AI開発ツール時代のセキュリティは、もはや「セキュリティ部門がやる」ものではなく、開発者個人がコミットの度に判断する領域に降りてきています。

この開発者個人=組織境界という認識は、連載③全体を貫く主題です。第5回でこの主題を完成させますが、ここから始まる連載は、その完成に向けた階段です。

連載③第2回への接続

第2回は、Bitwarden CLI事件(2026年4月22日)を扱います。Vercel事件が「AIツールがOAuth経由で侵入経路になった」事例だとすれば、Bitwarden CLI事件は、マルウェアがAIコーディングツールを名指しで狙い始めた最初の事例です。

具体的には、わずか90分のnpm汚染期間で、汚染パッケージがClaude Code・Cursor・Codex CLI・Aider・Kiro・Gemini CLIの存在をチェックし、認証情報を窃取するロジックを実装していました。攻撃者の進化軌跡——2024年AWSキー → 2025年CI/CDシークレット → 2026年AIコーディングツール認証情報——が、明示的に観測された出来事です。

Vercel事件が「使う側のAIツール」を扱うのに対して、第2回は「作る側のAIツール」を扱います。攻撃者の視野が、開発者のキーボードの上の光るアイコンに、すでに移っている——その実証を、次回見ていきます。

参考情報

• Vercel: April 2026 Security Incident Bulletin — 公式インシデント報告(継続更新)

• Guillermo Rauch on X (April 19, 2026) — CEO直々のスレッド、技術的詳細

• Context.ai Security Bulletin — Context.ai側の公式声明

• TechCrunch: App host Vercel says it was hacked and customer data stolen — 4月20日報道

• The Hacker News: Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials — Hudson Rock分析含む詳細

• The Hacker News: Vercel Finds More Compromised Accounts in Context.ai-Linked Breach — 追加被害報告

• BleepingComputer: Vercel confirms breach as hackers claim to be selling stolen data — Rauch発言の原文確認

• The Register: AI-pwned: Vercel breach traced to stolen employee creds — AI加速攻撃の論点

• The Record: Cloud platform Vercel says company breached through third-party AI tool — Context.ai側情報

• Trend Micro: The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables — MITRE ATT&CK マッピング、技術詳細

• OX Security: Supply Chain Attack Hits Vercel: User Data is Being Sold on BreachForums For $2M — 攻撃チェーン分析

• Reco AI: The Vercel and Context AI Breach: An AI Supply Chain Attack, Step by Step — 詳細タイムライン

• Strobes: Vercel Security Breach 2026: How One AI Tool Did It — AI加速攻撃の分析

• Varonis: The Vercel Breach: Steps To Protect Your Organization — 防御実装ガイド(優先順位付き対応手順)

• BleepingComputer: Learning from the Vercel breach: Shadow AI & OAuth sprawl — シャドーAI接続、default-deny推奨

• Kiteworks: A Third-Party AI Tool Quietly Opened the Door to Vercel's Internal Systems — DTEX/IBM統計引用

• Cloud Security Alliance: The Salesloft Drift OAuth Supply-Chain Attack: Cross-Industry Lessons in Third-Party Access Visibility — 業界横断の教訓

• Anomali: Reviewing the Salesforce-Salesloft Drift OAuth Supply Chain Breach — 詳細タイムライン、MITRE ATT&CK マッピング、IOC

• BleepingComputer: ShinyHunters claims 1.5 billion Salesforce records stolen in Drift hacks — 窃取データ数値の出典(攻撃者主張)

• SecPod: Story of Cyberattack: Salesforce Supply Chain Breach — Gainsight事件への波及

• AppOmni: Salesloft Drift–Salesforce Breach (UNC6395) — UNC6395帰属分析

• CrowdStrike 2026 Global Threat Report — SaaS/CI/CDレイヤ攻撃トレンド

• IBM 2026 X-Force Threat Intelligence Index — 公開アプリ悪用44%増、ChatGPT認証情報30万件以上

• Netskope Cloud and Threat Report 2026 — シャドーAI個人アカウント47%

• Reco AI: AI & Cloud Security Breaches 2025 Year in Review — 1年の集約レビュー

• Wing Security: Supply chain attacks meet Shadow AI — SaaS-to-SaaS連鎖