結論から言うと、この脆弱性の話を読んで翌朝にはエンジニア2人と15分のミーティングを入れた。
github.devのリンクを1回クリックするだけでGitHubのアクセストークンが盗まれる。セキュリティ研究者のアマル・アスカール氏が実証したやつで、Jupyter Notebookを含むリポジトリを細工するだけで攻撃が完結する。Microsoftは2026年6月3日と4日に修正を入れたので今はパッチ済みだ。ただ問題はそこじゃない。
うちは従業員8名のSaaS系スタートアップで、コードベースにはプロダクトの全資産が詰まっている。非公開リポジトリが外部に漏れたら、それはほぼ詰みだ。競合に見られるよりも、将来の投資家デューデリで「セキュリティ体制が未整備」と判定される方が怖い。シリーズAを狙っているタイミングでそれが出ると、バリュエーション交渉が一気に不利になる。
今回の攻撃のロジックは3行でまとめるとこうだ。
エンジニアなら「リンクを踏むな」で片付けるかもしれない。でもセールスやオペレーション担当はgithub.devを何となく開くこともある。うちのCSメンバーは先月、READMEの文言確認でgithub.devを使っていた。そのタイミングで細工されたリンクを踏んでいたらアウトだった。
半年前に会ったあるVCのパートナーが、デューデリのチェックリストに「GitHubのアクセス権限管理」を明示的に入れていた。当時は「そんな細かいところまで見るんだ」くらいの感触だったが、今回の記事を読んで腑に落ちた。トークンが漏れたらコードベースが終わりというのは、投資家目線では当然のリスク評価ポイントだ。
GTMのフェーズ的にも今は契約社数を積み上げている最中で、リポジトリにはAPIの仕様やインテグレーションの設計が全部入っている。競合が同じスタックを使っているのは把握していて、実際に採用候補者経由で「あそこも似た構成らしい」という話は定期的に入ってくる。スパイ行為とまでは言わないが、情報管理を甘くしている理由はない。
今回のミーティングで決めたことは単純だ。まず全メンバーのGitHubアクセス権限を棚卸しして、github.devを使う必要がない役割のアクセスを絞る。次にPersonal Access Tokenのスコープを最小権限に見直す。社内でSlackのDMやメールで共有されたgithub.devのリンクは踏む前に確認するフローを作る。大げさに聞こえるかもしれないが、これは1時間もあれば整理できる話だ。
この手のインシデントが起きたときのコストを雑に計算すると、エンジニアの対応工数・投資家への説明コスト・最悪の場合のPR被害で数百万円は飛ぶ。一方で今回の対処にかかるのはエンジニア2人×1時間程度だ。ROIで言えば議論するまでもない。
パッチが出たからもう安全、という読み方をした人はちょっと待ってほしい。今回は修正が早かったが、同じ構造の穴が別の場所にないとは言えない。github.devとVS CodeのWebview周りの設計に起因する問題で、Microsoftが全部塞ぎきったかどうかは外部からは判断できない。デスクトップ版VS Codeにも同種の問題が存在するとアスカール氏は指摘している。
うちのプロダクトの価値はコードベースに宿っている。それを守るのは技術の話ではなくて、経営判断だ。あなたのチームのGitHubアクセス権限、最後に見直したのはいつだっけ。
github.devのリンクを1回クリックするだけでGitHubのアクセストークンが盗まれる。セキュリティ研究者のアマル・アスカール氏が実証したやつで、Jupyter Notebookを含むリポジトリを細工するだけで攻撃が完結する。Microsoftは2026年6月3日と4日に修正を入れたので今はパッチ済みだ。ただ問題はそこじゃない。
うちの規模だからこそリスクが大きい
うちは従業員8名のSaaS系スタートアップで、コードベースにはプロダクトの全資産が詰まっている。非公開リポジトリが外部に漏れたら、それはほぼ詰みだ。競合に見られるよりも、将来の投資家デューデリで「セキュリティ体制が未整備」と判定される方が怖い。シリーズAを狙っているタイミングでそれが出ると、バリュエーション交渉が一気に不利になる。
今回の攻撃のロジックは3行でまとめるとこうだ。
- github.devのリンクをクリックさせる
- Notebook内のJavaScriptがVS Codeのキー操作を偽装して悪意ある拡張機能をインストールさせる
- 拡張機能がAPIトークンを取得して非公開リポジトリの一覧を外部に送信する
エンジニアなら「リンクを踏むな」で片付けるかもしれない。でもセールスやオペレーション担当はgithub.devを何となく開くこともある。うちのCSメンバーは先月、READMEの文言確認でgithub.devを使っていた。そのタイミングで細工されたリンクを踏んでいたらアウトだった。
投資家に聞かれたとき答えられるか
半年前に会ったあるVCのパートナーが、デューデリのチェックリストに「GitHubのアクセス権限管理」を明示的に入れていた。当時は「そんな細かいところまで見るんだ」くらいの感触だったが、今回の記事を読んで腑に落ちた。トークンが漏れたらコードベースが終わりというのは、投資家目線では当然のリスク評価ポイントだ。
GTMのフェーズ的にも今は契約社数を積み上げている最中で、リポジトリにはAPIの仕様やインテグレーションの設計が全部入っている。競合が同じスタックを使っているのは把握していて、実際に採用候補者経由で「あそこも似た構成らしい」という話は定期的に入ってくる。スパイ行為とまでは言わないが、情報管理を甘くしている理由はない。
今回のミーティングで決めたことは単純だ。まず全メンバーのGitHubアクセス権限を棚卸しして、github.devを使う必要がない役割のアクセスを絞る。次にPersonal Access Tokenのスコープを最小権限に見直す。社内でSlackのDMやメールで共有されたgithub.devのリンクは踏む前に確認するフローを作る。大げさに聞こえるかもしれないが、これは1時間もあれば整理できる話だ。
ROIで考えると対策コストは限りなくゼロに近い
この手のインシデントが起きたときのコストを雑に計算すると、エンジニアの対応工数・投資家への説明コスト・最悪の場合のPR被害で数百万円は飛ぶ。一方で今回の対処にかかるのはエンジニア2人×1時間程度だ。ROIで言えば議論するまでもない。
パッチが出たからもう安全、という読み方をした人はちょっと待ってほしい。今回は修正が早かったが、同じ構造の穴が別の場所にないとは言えない。github.devとVS CodeのWebview周りの設計に起因する問題で、Microsoftが全部塞ぎきったかどうかは外部からは判断できない。デスクトップ版VS Codeにも同種の問題が存在するとアスカール氏は指摘している。
うちのプロダクトの価値はコードベースに宿っている。それを守るのは技術の話ではなくて、経営判断だ。あなたのチームのGitHubアクセス権限、最後に見直したのはいつだっけ。