Vercel 2026年4月インシデント対応ガイド
最終更新: 2026年4月20日 12:07 PM AEST/ブリスベン - (v2 — Vercel CEO 2026年4月20日更新を反映)
重要: これは法的なアドバイスや公式見解ではありません。侵害を受けたと思われる場合は、インシデント対応パートナーに連絡してください。この情報は、OpenSourceMalware チームによる誠意として提供されるものです。インシデント対応企業への紹介が必要な場合は、これまでに協力したことのある企業をいくつかご紹介できます。
何が起こったのか？
Vercel は2026年4月19日、攻撃者が内部システムへの不正アクセスを取得したことを公表しました。公式発表はこちら: 発表
4月20日、Vercel CEO の Guillermo Rauch 氏は詳細なアップデートを公開し、初期アクセス経路を確認しました。Vercel の従業員が Context.ai という AI プラットフォームを使用しており、それが侵害されていました。そこから攻撃者は従業員の Google Workspace アカウントに移動し、Vercel 環境へと権限昇格しました。環境変数は保存時に暗号化されていますが、攻撃者は「機密」とフラグが立てられていない変数を列挙できました。Vercel は攻撃者を高度に洗練されており、AI による加速が大きい可能性があると特徴づけています。Google Mandiant が対応に関与しています。Vercel は Next.js、Turbopack、およびオープンソースプロジェクトは安全であると述べています。
以下は、そのセキュリティアドバイザリからの侵害指標セクションです:
詳細はかなり乏しいです。その唯一の Google IOC をどこで確認すればよいかさえ教えていません。Vercel の顧客として、この詳細レベルの低さにはかなり失望しています。何を探すべきか理解できるようにしてください！侵害されたかどうかを知るためにどこに行けばいいのか教えてください！
Vercel からの詳細がないため、このドキュメントを作成しました
Vercel でワークロードを実行している場合、以下のことが証明されるまで仮定してください:
- 露出期間中の Vercel プロジェクトで「機密」フラグが立てられていない環境変数は、読み取り可能だった可能性があります。
- ダッシュボードまたは
vercel env CLI を介して Vercel にプッシュされ、ローテーションされていない資格情報はすべて、存続する負債です。
- Vercel ↔ GitHub および Vercel ↔ Linear の統合パス内のトークンは、アクセス可能だった可能性があります。
- 「影響あり/なし」の明確なシグナルはすぐには得られません。まずローテーションし、その後調査してください。
既知の事実 vs. 主張されていること: ブリーフィングではこれらを分けて扱ってください
この区別は、エグゼクティブコミュニケーションや過剰対応（または過小対応）を防ぐために重要です。
Vercel により確認済み (速報 + 4月20日のCEOアップデート)
- Vercel の特定の内部システムへの不正アクセス。
- 初期アクセス経路: Context.ai — Vercel 従業員が使用していた AI プラットフォームが侵害されました。攻撃者はその足がかりを使って従業員の Vercel Google Workspace アカウントを侵害し、そこから Vercel 環境へと権限昇格しました。
- 顧客の環境変数は保存時に暗号化されています。しかし、「非機密」と指定された変数は、攻撃者が内部に入った後で列挙可能でした。
- 顧客への影響は「かなり限定的」とされています。Vercel は懸念がある顧客に直接連絡済みです。
- Next.js、Turbopack、Vercel のオープンソースプロジェクトは分析され、安全であると考えられています（つまり、Vercel の4月20日時点の声明では、これらのプロジェクトのリリースパスに悪意のある成果物はありません）。
- 攻撃者は高度に洗練されており、AI による加速が大きい可能性があると特徴づけられています。
- 対応パートナー: Google Mandiant が積極的に関与しており、外部の IR 企業、業界の同業他社、法執行機関も関与しています。
- Vercel は Context.ai に連絡を取り、全容の把握に協力しています。
- Vercel は UI の改善をリリースしました: 環境変数概要ページ、機密性の高い環境変数の管理改善。
第三者および攻撃者によって報告/主張されている（Vercel 未確認）
- Linear および GitHub の統合が不均衡に影響を受けた（コミュニティの報告、特に Theo Browne 氏の X でのポスト）。
- BreachForums で販売されているデータ: 内部 DB、従業員アカウント、GitHub トークン、npm トークン、ソースコード断片、アクティビティタイムスタンプ — 約 200 万ドルで提供。
- 攻撃者は自らを ShinyHunters と名乗っている。過去にその名称に関連する他の攻撃者は関与を否定しています。
- Vercel が顧客と直接確認した範囲を超えた特定の顧客データクラスが流出。
未確認の報告は、もっともらしく、自身のトリアージには実行可能 として扱ってください。ただし、Vercel が裏付けを取るか、独立した証拠を得るまでは、顧客や規制当局へのコミュニケーションで事実として引用しないでください。「列挙可能な環境変数」（Rauch 氏確認）と「BreachForums で販売されている npm + GitHub トークン」（攻撃者の主張）の間のギャップは、サプライチェーンリスクにとって最も重要なギャップです — ローテーションの目的では最悪を想定し、コミュニケーションでは確認済みのバージョンに固執してください。
スコーピング: このプレイブックを実行すべき対象
最高の緊急性 — Vercel から直接連絡があった場合、または以下のいずれかに該当する場合:
- Vercel ↔ GitHub 統合があり、リポジトリへの書き込みスコープがある（またはあった）。
- Vercel ↔ Linear 統合がある（またはあった）。
- Vercel 環境変数として暗号化されていないシークレット（機密フラグなし）を保存している。
- Vercel インフラ上または経由で実行される CI/CD から npm パッケージを公開している。
標準的な緊急性 — アクティブな Vercel プロジェクトを持つすべてのチーム（マーケティングサイトも含む）。マーケティングサイトには、CMS API キー、分析トークン、フォームハンドラーのウェブフックが含まれていることが多く、これらはより機密性の高いシステムにピボットする可能性があります。
それでも実施 — インシデント前にプロジェクトを削除した場合でも。問題は、シークレットが読み取り可能な形で Vercel に存在したかどうかであり、プロジェクトがまだあるかどうかではありません。
副次的な質問: 組織は Context.ai に直接露出していますか？
4月20日のアップデートでは、侵害された上流ベンダーとして Context.ai が指名されています。組織内の誰かが Vercel インシデントとは独立して Context.ai を使用している場合（ミーティングインテリジェンス、ナレッジマネジメント、CRM エンリッチメント、その他のワークフロー）、Vercel インシデントとは別に、独自の直接的な露出期間がある可能性があります。
これらのチェックを並行して実行してください:
- SSO / IdP（Okta、Entra、Google Workspace）で、Context.ai または Context 関連の OAuth アプリに認証したユーザーをクエリします。
- Google Workspace 管理コンソール → セキュリティ → OAuth アプリアクセスログで
context.ai または関連アプリ ID を検索します。
- 企業の経費 / SaaS 支出管理ツールで Context.ai のサブスクリプションを確認します。
- 付与された OAuth スコープを確認します — Gmail 読み取り、カレンダー、Drive、Workspace ディレクトリスコープは影響が大きいです。
環境内で Context.ai の使用が見つかった場合、OAuth 許可を取り消し、Context.ai ワークフローを通過した資格情報をローテーションし、影響を受けたユーザーの Google Workspace アカウントで Vercel が従業員のアカウントで確認したものと同じ侵害指標を監視してください。自身のインシデント詳細については Context.ai に直接連絡してください。Vercel は、他の影響を受ける組織を支援するために Context と調整していると公表しています。
フェーズ 0: 出血を止める（最初の60分）
2つの目標: 新たな被害を防ぎ、証拠を保全する。
-
デプロイを凍結する。 プロダクションブランチでの自動デプロイを一時停止します。攻撃者によって改変されたビルドが本番に出荷されるのを防ぎ、監査ログの増加を止めます。
-
Vercel の GitHub App を無効化する。 Vercel GitHub App がインストールされている場合（新しいコードを GitHub にプッシュしたときに Vercel への自動デプロイを行っている場合に該当）、無効化します。インストールされている GitHub アプリは https://github.com/organizations/<GitHub-Organization>/settings/installations で確認できます。
-
GitHub App が持っているアクセス権を特定する。 上記の設定ボタンをクリックし、Vercel アプリがアクセス権を持っていたリポジトリを監査します。これにより、今すぐ何に焦点を当てるべきかがわかります。GitHub → Organization → Settings → GitHub Apps → Vercel に移動して確認:
- リポジトリアクセス（全リポジトリか選択済みか）
- 付与された権限
- インストール日と誰がインストールしたか
- Vercel 監査ログのスナップショットを取得する チームのログをエクスポートまたはスクリーンキャプチャします。保持期間は限られており、UI ですべてが公開されているわけではありません。ログを汚染する変更を加える前に取得してください。 https://vercel.com/activity-log で確認できます。
- 「Observability Plus」を有効にする。 これは Vercel の有料追加機能であり、有効にして支払うことを提案するのは残念ですが、インシデント対応中はこれが最善の方法だと思います。決して嬉しいことではありませんが、デフォルトでは非常に短い監査ログの保存期間を延長するために、私は有効にしました。
- 露出の広がりを棚卸しする。 管理下にあるすべての Vercel チーム/アカウントについて、以下をリストアップ:
- プロジェクトとそれにリンクされた Git リポジトリ
- 接続されている統合（GitHub App、Linear、Slack、マーケットプレイス統合）
- チームメンバーとその役割
- チームの下で発行された個人アクセストークン / API トークン
- デプロイフック
- GitHub Organization の監査ログを確認する。 露出期間（控えめに見て2026年4月1日〜15日から現在まで）を探します。以下でフィルタリング:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy, protected_branch.updategit.ref.force_push またはプッシュイベントの force-push フラグ
現時点では、発表やシークレットのローテーションは行わないでください。まずスナップショットが必要です。
フェーズ 1: 侵害指標（IOC）の確認
Vercel の発表からの詳細はかなり乏しいです:
判明している限りでは、Google Workspace 管理コンソールに移動して、この googleusercontent.com アプリを探すことを提案しているようです。コンソールでこれを見つける方法は以下の通りです:
-
Workspace 管理 コンソール で セキュリティ > アクセスとデータ制御 > API 制御 に移動し、アクセス済みおよび保留中のアプリを見つけます。
-
次に、さまざまなリストで IOC を探します。これは oauth アプリのようです: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
見つけた場合は直ちに削除し、インシデント対応パートナーに相談してください。これは私の能力を超えています。
フェーズ 2: 資格情報のローテーション
ローテーションは最も価値の高い単一のアクションです。優先順位順に実行し、中断された場合でも最も危険なものが処理されるようにします。
何をローテーションするかは、GitHub および Vercel 環境で何が露出しているかに依存します。GitHub PAT などから始めて、このガイドに従って外側に向かって進めてください。
優先順位ティア
ティア 0 — 今日中に、他の何よりも先にローテーション:
ティア 1 — 今日中にローテーション、アプリで露出しているものに依存:
- 決済プロセッサのシークレットキー（Stripe、Adyen、Braintree など）
- 認証署名シークレット（NextAuth
AUTH_SECRET / NEXTAUTH_SECRET、JWT 署名キー、セッション Cookie キー、CSRF トークン）
- 書き込みアクセス権を持つデータベース接続文字列（
DATABASE_URL、直接の Postgres/MySQL URL、Mongo URI、認証付き Redis）
- クラウドプロバイダのルートまたは広範なスコープのキー（AWS IAM アクセスキー、GCP サービスアカウント JSON、Azure クライアントシークレット）
- ウェブフック署名シークレット（Stripe、GitHub、Slack — ローテーションし、送信元設定も更新）
ティア 2 — 今週中にローテーション:
- サードパーティ SaaS API キー（分析、メールプロバイダ、SMS、CRM）
- 所有するアプリの OAuth クライアントシークレット
- SMTP 資格情報
- アプリケーションレイヤー暗号化の暗号化キー（キーバージョンを上げてローテーション、単なる差し替えはしない）
- CDN パージキー、イメージサービスキー
- フィーチャーフラグプロバイダキー
ティア 3 — 都合の良いときにローテーション、それでもローテーションする:
- 読み取り専用の分析トークン
- Sentry / ログ DSN（注: DSN のローテーションは、イベントのドロップが短時間許容できる場合は重要ではありません）
- 公開キーと匿名キー（それでもローテーション — プロジェクトの存在を明らかにし、列挙を可能にする可能性があります）
操作順序の落とし穴
- セッション署名キーをローテーションすると、すべてのアクティブなセッションが無効になります。 強制ログアウトイベントを計画し、周知してください。
- ウェブフックシークレットは両端でローテーションする必要があります。 まず送信元（Stripe、GitHub）を新しいシークレットで送信するように更新し、次に受信側で新しいシークレットに対して検証するようにします。または、一時的に両方をサポートします。
- データベース資格情報 — 最初に新しいユーザーを作成し、デプロイしてから古いユーザーを無効にします。単に差し替えると停止が発生する可能性があります。
- AWS キー — IAM ユーザーのアクセスキーをローテーションする場合、2番目のキーを作成し、デプロイメントをロールしてから最初のキーを削除します。「無効化」して期待するだけではだめです。
- 環境変数を変更したら再デプロイする。 Vercel の環境変数は、多くのフレームワーク設定でビルド時に組み込まれます。環境変数を変更しても再デプロイしなければ完全には適用されません。
- CI シークレットも確認する。 シークレットが GitHub Actions、CircleCI などにミラーリングされていた場合、そのミラーもローテーションします。
よく見落とされるものを忘れずに
- プライベートリポジトリにコミットされた
.env.local（それでも問題 — ソースコードが流出した可能性があります）
- プロダクションだけでなく、Vercel のプレビュー/開発環境のシークレット
- Vercel の「チームレベル」共有環境変数として保存されたシークレット
- デプロイフック（これらもローテーション — 完全なデプロイトリガーです）
- アカウントの下で発行された Vercel 個人アクセストークン
- Vercel GitHub App のインストールを承認した GitHub 個人アクセストークン（アプリ自体とは別）
フェーズ 3: リポジトリレベルの調査
Vercel に接続されていたリポジトリについて:
main/master の HEAD を、インシデント期間前の安全なタグ/コミットと差分を取ります。- 以下への変更を探す:
package.json → scripts（特に postinstall、prepare、preinstall）package-lock.json / pnpm-lock.yaml / yarn.lock — 予期しない依存関係の追加やバージョンアップ.github/workflows/*.yml — 新しいワークフロー、新しい run: ステップ、新しい uses: で固定されていない SHAvercel.json — ビルドコマンドの変更、トラフィックを外部に漏洩させる可能性のある新しいリライト/リダイレクト
これらのリポジトリから npm パッケージを公開している場合
ここで Vercel の侵害がサプライチェーンイベントになる可能性があります。Vercel を使って公開していなくても、攻撃者が GitHub トークンを取得し、公開ワークフローがそのトークンを使用している場合:
npm 公開履歴を確認: npm view <pkg> time --json で予期しないバージョンを探す。- 各最近のバージョンの tarball を、それが由来するとされる git タグと比較。攻撃者はレジストリにあるものと一致しないタグから公開することがあります。
- ワークフローでの
NPM_TOKEN の使用を監査 — トークンをローテーションし、誰がアクセス権を持っていたか確認。
- パッケージに新しいメンテナーが追加されていないか確認:
npm owner ls <pkg>。
- 重要なものを管理している場合、tarball 内の post-install スクリプトの実行を監視 — 解凍して検査。
不正な公開の証拠を見つけた場合、npm セキュリティ（[email protected]）に報告し、OSV.dev への報告も検討してください。問題のあるバージョンを非推奨にし、削除しないでください（削除は時間制限があり、ダウンストリームの利用者に影響します）。
Vercel 所有のパッケージに関する注記: Vercel の4月20日のアップデートでは、Next.js、Turbopack、およびそれらのオープンソースプロジェクトは分析され、安全であると考えられています。これは Vercel が自社のリリースパスについて主張しているものです。上記のように自身のパッケージも監査する必要があります。Next.js や Turbopack を利用している場合、現在の情報に基づいて予防措置としてインシデント前のバージョンに固定する必要はありませんが、Vercel の速報でその姿勢が変更されるかどうかを監視してください。
フェーズ 4: Linear 統合の確認
チームが Vercel ↔ Linear 統合を使用している場合:
- Linear 監査ログ（ワークスペース設定 → セキュリティ → 監査ログ）を露出期間中について確認。
- 以下を探す:
- 新しい API キーの発行
- 新しい統合の追加
- サービスアカウントによるコメントの投稿
- ウェブフック送信先の変更
- メンバーの招待
- イシューデータの表示/エクスポート（統合はイシューへの読み取りアクセス権を持っており、イシューには顧客名、バグ詳細、時にはチケットに貼り付けられた資格情報が含まれることが多い）
- 特に懸念: Linear イシューには、開発者のデバッグ時に貼り付けられたシークレットが頻繁に含まれます。Linear ワークスペースで一般的な漏洩パターン（
AKIA、sk_live_、ghp_、ghs_、npm_、eyJ、----BEGIN）を grep してください。見つかったものはローテーションする必要があります。
フェーズ 5: ダウンストリームシステムのログ確認
ほとんどの場合、資格情報のローテーションは攻撃者の永続化を無効にしますが、攻撃者はすでにそのアクセスを使用していた可能性があります。ローテーションしたシークレットのコンシューマーで、露出期間中の使用の兆候がないか確認してください。
確認する期間
2026年4月1日から現在までを控えめな下限として使用してください。インシデントは4月19日に公開されましたが、初期アクセスは公開前に発生しています。Vercel がより具体的な日付を公開した場合、これに応じて狭めます。
何をクエリするか
- AWS CloudTrail — 侵害された IAM キーからの異常な API コール、特に S3 バケットに対する
GetObject のバースト、CreateUser、AttachUserPolicy、新しい ASN/国からのコンソールログイン。
- データベース監査ログ — 機密テーブルに対する異常な
SELECT *、大規模なエクスポート、予期しない送信元 IP からの接続。
- Stripe / 決済ログ — 異常な顧客作成、送金作成、API キー作成。
- 認証プロバイダログ（Auth0、Clerk、Cognito、Firebase） — ありえない移動のログイン、管理者ユーザーに対するパスワードリセットのトリガー、新しいアプリケーション登録。
- メールプロバイダ（SendGrid、Postmark など） — 予期しないアウトバウンドキャンペーン、新しい API キー、送信者 ID の変更。
- GitHub — クローン、フォーク作成、リポジトリアクセスを持つユーザーアカウント上の新しい SSH キー。
有用な IOC ハンティングの基本
Vercel または IR パートナーによって公開された攻撃者管理のホスト名や IP を、以下に貼り付けます:
- フロントエンドの HTTP アクセスログ（攻撃者は行動前にアクセスを確認するために事前プローブすることがあります）。
- DNS ログ — サーバーからの異常なドメインへのアウトバウンド解決。
- アウトバウンドプロキシ / VPC フローログ。
公開時点では、Vercel から IOC は公開されていません。Vercel の速報と、よく知られた IR 企業のブログ記事を更新がないか監視してください。
フェーズ 6: 残留する侵害の検出
プラットフォーム層の侵害後の攻撃者の永続化は、一般的に以下の形態を取ります。それぞれを積極的にハントしてください:1. Vercelチーム、GitHub Organization、Linearワークスペース、またはクラウドアカウントにおける新しいチームメンバーまたはコラボレーター。露出ウィンドウ内の日付であること。
2. 接続されたSSOプロバイダー（Google Workspace、Okta、Entra ID）における開発者アカウントの新しいOAuth認可。
3. 変更されたCI/CD設定 — 現在、コールバック先に通信を行うワークフロー、新しいセルフホステッドランナー、無害な名前の新しいシークレット。
4. Vercelにおける予期しないデプロイ — デプロイ履歴を確認し、既知の作成者による既知のコミットに対応付けられないデプロイを探す。
5. サーバーレス関数ログにおけるリバースシェルの兆候 — 書き込まれたり実行されたりするBase64ブロブ、Edge/サーバーレス関数からの異常な発信接続。
6. DNSの変動 — 新しいサブドメイン、CNAMEの変更、vercel.jsonまたはフレームワーク設定を介して追加されたリダイレクト。
7. 認証の変更 — MFAの無効化、リカバリーコードの再生成、ユーザーの操作なしでのパスワード変更。
コミュニケーション
内部
インシデントコマンダーを指名する。ローテーションが進行中の間は、最低でも毎日スタンドアップミーティングを実施する。「何をローテーションしたか、何が保留中か、何を発見したか」を一元管理する文書を作成する。Linearがインシデントの範囲に含まれる場合はLinearからは離れて、サイドチャネルを使用する。
顧客向け
法律顧問に相談する。通知の基準は異なるが、以下の点に留意する。
- GDPR: EU居住者に影響を与える報告義務違反については72時間以内。
- オーストラリア（NDBスキーム、OAIC）: 重大な損害が発生する可能性が高い場合、実行可能な限り速やかに通知する。
- 米国: 州ごとに異なる。30～60日の猶予期間を設ける州もあれば、特定のデータクラスについては即時通知を義務付ける州もある。
- カリフォルニア州（CCPA）: カリフォルニア州居住者の個人情報が対象となる場合、特定の義務が発生する。
- SOC 2 / ISO 27001の顧客: 契約上の通知条項は、規制上の最低要件よりも早期の通知を求めることが多い。MSAを熟読すること。
自社システムからのデータ持ち出しの証拠がない場合、まだ通知義務は発生していない可能性がある。しかし、「当社はVercelを使用しており、Vercelでインシデントが発生した」という事実だけでは、通常、機密データが実質的に危険にさらされていない限り、通知をトリガーするには十分ではない。その判断理由を文書化する。
事前準備済み声明
必要になる前に、以下を作成しておく。
- 社内全体向け説明
- 顧客向け勧告
- 規制当局向け通知テンプレート
- ステータスページの更新（公開している場合）
公開時の帰属に関する衛生管理
攻撃者の主張を事実として公に再述しない。一次情報源としてVercelの報告書にリンクする。Vercel自身に自社のインシデントを特徴付けさせる。あなたは自社の暴露範囲を特徴付けるという自身の役割に徹する。
中期的な堅牢化（インシデント後）
このインシデントは、たとえ影響を受けていないことが判明したとしても、修正する価値のある構造的な問題を浮き彫りにしている。
- すべてのシークレットをVercelの機密環境変数機能に移行する。 これをチームのデフォルトにする。開発者が作成時にフラグを立てるようにトレーニングする。
- 可能な限り短命な認証情報を採用する。 Vercelの環境変数にミラーリングされた長期的なアクセスキーではなく、AWS/GCP/AzureへのGitHub OIDCフェデレーションを使用する。組み込みの環境変数ではなく、実行時にアクセスされるクラウドネイティブなシークレットマネージャー（AWS Secrets Manager、GCP Secret Manager）を使用する。
- Google Workspace、Microsoft 365、GitHub Organization、Vercelチームに接続されているサードパーティのOAuthアプリを棚卸しする。 Vercel IAVはContext.aiであり、従業員のGoogle WorkspaceにOAuthを介して統合されたAIプラットフォームであった。同じクラスのリスクは、SaaSおよびAIツールの統合を寛大に承認してきたすべての組織に存在し、過去18ヶ月間のAIツールゴールドラッシュの中で、「承認されるもの」のハードルはかなり低下している。具体的なアクション：
- Google WorkspaceのOAuthアプリレポートを取得する（管理コンソール → セキュリティ → API制御 → アプリアクセス制御）。機密性の高いスコープ（
gmail.readonly、calendar、drive、admin.directory）を持つすべてのアプリをレビューする。
- Microsoft 365についても同様に行う（Entra ID → エンタープライズアプリケーション）。
- 四半期ごとのレビューを制度化する。機密性の高いスコープを持つ新しいOAuth許可には、セキュリティ部門の承認を必須とする。
- OAuthアプリのインストールをユーザー主導の承認ではなく、許可リストに制限することを検討する。
- GitHub Appのスコープに対する最小権限の原則。 VercelがOrganization全体のリポジトリアクセスを必要としない場合は、実際にデプロイするリポジトリに制限する。
- デプロイフックの定期的なローテーション。 四半期ごとに実施する。
- pre-commitおよびCIにシークレットスキャンを組み込む。 Trufflehog、gitleaks、または同等のツールを使用する。リポジトリの履歴を遡及的にスキャンし、コミットされてからローテーションされた可能性のあるものがないか確認する。一度コミットされたものは、どこかのクローンにまだ存在していると想定する。
- Vercelアカウントの設定を監査する。シークレットだけではない。 トークンのローテーションは漏洩に対処するが、構造的な露出はそのまま残る。
NEXT_PUBLIC_値がクライアント側に送られる、有効期限やスコープのないトークン、プレビューでのデプロイメント保護の無効化、ぶら下がったエイリアス、署名されていないウェブフックなど。これらはVercel API設定内に存在し、ソースツリーにはないため、シークレットスキャナーはそれらを見逃す。オープンソースの選択肢の一つ：vercelsior。
- Vercel統合フットプリントをSOC 2 / ISOの証拠の一部として文書化する。 顧客から尋ねられることになる。
- このプレイブックをQ3に、別のプラットフォームプロバイダーでの仮想的な同様の形状のインシデントを想定した 机上演習として実施する。このインシデントはVercelに固有のものではない。この経験から得られる筋肉記憶は汎用的に応用できる。
参考情報
更新履歴
- 2026-04-20 (v2) — Vercel CEO Guillermo Rauch氏の4月20日声明を受けて更新。いくつかの項目を「報告された」から「確認済み」に格上げ：侵害された上流ベンダーとしてContext.aiが特定されたこと、ピボットポイントとしてVercel従業員のGoogle Workspaceアカウントが使用されたこと、プラットフォーム内の横断的移動として非機密環境変数の列挙が行われたこと。Context.aiへの直接的な露出に関する並行スコーピングを追加。Next.js、Turbopack、およびOSSプロジェクトは安全であるというVercelの声明を追加。Mandiantの関与を追加。OAuthアプリ棚卸しの推奨事項を強化。
- 2026-04-20 (v1) — 初版。2026-04-19のVercel報告書および同時期の公開報道に基づく。Vercelが追加の詳細、IOC、またはより狭い露出ウィンドウを公開する際に更新すること。
opensourcemalware/vercel-april2026-incident-response
