Supabaseプロジェクトをnpmサプライチェーン攻撃から守る7つの防御策
npmエコシステムを狙ったサプライチェーン攻撃が2026年に相次いでいる。5月には、TanStackがGitHub Actionsのワークフローキャッシュを汚染され、正規リリースに悪意あるコードが混入する事件が発生した。Supabaseも同様に、supabase-javascriptというタイポスクワット（入力ミスを狙った偽装パッケージ）がnpm上に現れるなどの標的に遭っている。
同社はこの事態を受け、プロジェクトの保護に向けた社内横断の対応を開始し、誰もが参照できる公式ガイドを公開した。本記事では、そのガイドの中核を抜粋し、攻撃の構造と開発者が今すぐ実施すべき防御策を具体的に解説する。
npmサプライチェーン攻撃の3つの典型的な手口
サプライチェーン攻撃は、直接システムに侵入するのではなく、開発者が信頼しているパッケージに悪意あるコードを忍び込ませる。以下が最も一般的な三つの手口だ。
メンテナの認証情報を奪う「アカウント乗っ取り型」
攻撃者がnpmの公開トークンを盗むか、メンテナをフィッシングして乗っ取り、人気パッケージの新版に悪意あるコードを仕込んで公開する。次にnpm installを実行すると、その悪質なバージョンが導入されてしまう。
入力ミスを誘う「タイポスクワッティング型」
本物のパッケージ名から数文字だけ変えた類似名でパッケージを登録し、開発者やAIコーディングエージェントが誤ってインストールするのを待つ。Supabaseの例では、@supabase/supabase-js ではなく supabase-javascript というスコープなしの名前で公開された。AIエージェントがパッケージ名を幻覚（ハルシネーション）して提案することも多く、この手法は脆弱だ。
ビルドパイプラインを悪用する「CI/CD侵害型」
この手口は、GitHub ActionsなどのCI/CDパイプラインの脆弱なワークフローを突く。攻撃者はフォークしたプルリクエストからワークフローのキャッシュを汚染し、次回の正規リリース実行時にそのキャッシュを拾わせて、正規メンテナの署名で悪意あるコードを公開させる。TanStackを襲った攻撃がまさにこれで、セッションメッセンジャーネットワーク経由で機密情報が流出した。
いずれの手口も、npm install の完了までに環境変数やAWSメタデータ、SSH秘密鍵といった機密情報を根こそぎ奪われる危険がある。
Supabaseが実施するプロジェクト防御策
Supabaseはこの問題に対し、全社的な対応を開始した。以下が現在進行中の主な取り組みである。
公式セキュリティガイドの公開
同社は、npmセキュリティに関する推奨事項をまとめた単一の正規ガイドページを公開した。エージェントが読み取り可能な形式で、具体的なアクションを指示している。
GitHub Actionsの安全性強化
組織全体で pull_request_target の使用を精査し、アクションのバージョン参照をコミットSHAに固定する強制ルールの適用が最終段階に入っている。
クレデンシャル関連APIへの警告注釈
createClient などの関数にTSDoc（TypeScript向けドキュメントコメント）を追加し、エディタ上でホバー時に機密情報を扱う旨の警告が表示されるようにした。
全チャネルでの啓蒙活動
顧客かどうかを問わず、できるだけ多くの開発者に防御策を届けるため、ブログやコミュニティを通じた情報発信を強化している。
依存関係管理の厳格化
以下に挙げる設定変更は、いずれも数分で完了する。どれか一つでは完全な防御にはならないが、複数積み重ねることで攻撃者が諦めるほどの障壁を築ける。
パッケージマネージャを最新にして公開遅延を設定する
pnpm 11（またはnpm v11相当）にアップグレードし、minimumReleaseAge をデフォルトの24時間より長く設定する。多くの悪意あるパッケージはリリース後24〜48時間以内に検出され削除されるため、3〜7日の遅延を設けると、被害を受ける確率を大幅に下げられる。
# pnpm-workspace.yaml または .npmrc
minimumReleaseAge: 4320 # 分単位、3日依存バージョンを固定する
^ や ~ による範囲指定は、npmに対して「次のマイナーやパッチを自動的に取り入れて問題ない」と伝えているに等しい。認証情報やネットワーク通信を扱うパッケージでは、必ず正確なバージョン番号を指定しよう。
"dependencies": {
"@supabase/supabase-js": "^2.39.0",
"axios": "~1.6.0"
}"dependencies": {
"@supabase/supabase-js": "2.39.0",
"axios": "1.6.2"
}ロックファイルをコミットし差分を精査する
pnpm-lock.yaml や package-lock.json は、インストールされた正確なバージョンとハッシュを記録する。攻撃者が同じバージョン番号で悪意あるtarballを差し替えても、ハッシュが一致せずインストールが失敗する。ロックファイルをリポジトリにコミットし、プルリクエストの差分では目的不明な依存関係の変更がないか必ず確認する。
不用なインストールスクリプトを無効化する
サプライチェーン攻撃のペイロードの多くは、preinstall install postinstall といったライフサイクルスクリプトを通じて実行される。ネイティブコードを含むパッケージを必要としないプロジェクトでは、これらをグローバルに無効化する。npmでは npm config set ignore-scripts true または .npmrc に ignore-scripts=true を記述する。pnpmではAllow Buildsモデルを使って、実際に必要なパッケージだけを許可リストに登録する。
安全なパッケージ導入のための実践
パッケージ名を毎回検証する
タイポスクワッティング対策として、以下の点をインストール前に必ず確認する。
- スコープが正しいか。Supabase公式パッケージはすべて
@supabase/配下にある。 - メンテナの一覧が期待通りか。長年維持されてきたパッケージに新しいメンテナが突然加わっていれば警戒信号だ。
- ダウンロード数とリンク先のGitHubリポジトリが、本物のパッケージとして妥当であること。
CI/CDワークフローを狙った攻撃への対策
ActionsをコミットSHAで固定する
ワークフローで参照するサードパーティアクションは、タグではなくコミットの完全なSHAハッシュ（40文字）で固定する。タグは攻撃者が新しいコードで置き換えられるため安全でない。
- uses: actions/checkout@1f9a0c22da41e6ebfa534300ef656b67ce0c5b94 # v6.0.2pull_request_target の危険な使い方を回避する
pull_request_target イベントは、プルリクエストのコードをチェックアウトして実行するコンテキストで使うと、攻撃者がリポジトリのシークレットやキャッシュにアクセスできてしまう。TanStackを襲った攻撃はまさにこのパターンだった。PRのコードに触れる処理は必ず pull_request を使用し、pull_request_target はラベリングやコメント投稿など、コードを実行しない信頼済み操作に限定する。
on:
pull_request_target:
types: [opened, synchronize]
jobs:
build:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}on:
pull_request:
types: [opened, synchronize]
jobs:
build:
- uses: actions/checkout@v4インシデント発生時の即応策
クレデンシャルのローテーションと監査
もし疑わしいパッケージを含む環境で npm install を実行してしまったら、そのマシンを危殆化したと見なし、到達可能なすべての認証情報（AWS、GCP、Kubernetes、Vault、GitHub、npm、SSH、Supabaseのサービスロールキー）を直ちにローテーションする。Supabaseのダッシュボードでサービスロールキーの使用状況を監査し、不審なアクセスパターンがないかも確認する。半日はかかる作業だが、顧客への被害を防ぐ価値は十分にある。
スキャナの導入で第二の防御線を
Socket.devやnpq、Snykといったツールは、npmレジストリのパッケージをリアルタイムで監視し、怪しい挙動をフラグ付けしてくれる。これらは万能ではないが、基本的な対策をすでに実施しているチームにとって有効な第二の防御線となる。
AIコーディングエージェントに渡すセキュリティチェックリスト
以下は、Supabaseが推奨するリポジトリ監査プロンプトだ。Claude CodeやCursorなどに貼り付け、変更内容を必ず確認しながら適用する。プッシュやPR作成、依存関係の自動追加、クレデンシャルのローテーションは自動化せず、必ず人間が承認する。
このリポジトリのnpmサプライチェーン衛生状態を監査してください。以下の変更を適用し、何を行ったかを報告してください。明示的な承認なしにプッシュ、PR作成、新しい依存関係のインストール、クレデンシャルのローテーションは行わないでください。
パッケージマネージャ:
- 古いバージョンならpnpm 11+（または最新のyarn/npm/bun）にアップグレード
- 新バージョンに7日間の公開遅延を設定
- pnpm: `minimumReleaseAge: 10080` を pnpm-workspace.yamlに
- npm: `min-release-age=7` を .npmrcに
- yarn (berry): `npmMinimalAgeGate: '7d'` を .yarnrc.ymlに
- bun: `minimumReleaseAge = 604800` を bunfig.tomlの[install]セクションに
- ライフサイクルスクリプトをデフォルトで無効化。pnpmではallowBuildsで明示的に許可するパッケージをリスト。
- 非レジストリの透過的依存参照をブロック。pnpmでは`blockExoticSubdeps: true`等を設定。
- パッケージマネージャ自体を正確なバージョンとsha512ハッシュで固定
ロックファイルと依存関係:
- ロックファイルがコミットされていることを確認（gitignoreされていない）
- 認証、シークレット、通信、暗号、ユーザデータを扱う依存関係では^/~を正確なバージョンに置き換え
- Supabase関連のインポートがすべて`@supabase/`スコープか検証。スコープなしの類似名はタイポスクワットとしてフラグ
GitHub Actions（存在する場合）:
- すべてのサードパーティアクションのusesを40文字のコミットSHAに固定し、元タグをコメントで残す
- pull_request_targetを使いPRコードをチェックアウトしているワークフローを抽出し、pull_requestへの書き換えを提案
- インストールワークフローに`npm audit signatures`の非ブロッキングステップを追加
人の確認が必要な項目:
- Dependabotアラートとシークレットスキャンが無効なら有効化を提案
レポート:
- ファイル変更ごとに1行の理由付きリスト
- 自動変更せずに人の判断が必要な項目の一覧
この記事のポイント
- npmサプライチェーン攻撃は、アカウント乗っ取り、タイポスクワッティング、CI/CD侵害の3パターンに大別される
- Supabaseは公式ガイド公開、GitHub Actions強化、API警告追加などで対策を推進中
- 即効性のある防御策として、パッケージマネージャの更新と公開遅延設定、バージョン固定、ロックファイル精査、インストールスクリプト無効化、パッケージ名検証、ActionsのSHA固定、pull_request_targetの回避がある
- 万が一侵害が疑われる場合はクレデンシャル全ローテーションとスキャナ導入で二次被害を防ぐ
- AIエージェントには安全な監査プロンプトを組み込み、自動変更を人の目でレビューする体制を整える
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubへの不正アクセス調査詳報、攻撃者は内部リポジトリに侵入するも影響は限定的
2026年5月20日、GitHubは自社が所有する一部の内部リポジトリに対して、第三者による不正アクセスがあったことを公表した。GitHubの最高情報セキュリティ責任者（CISO）であるAlexis Wales氏がGitHub Blogで発表した調査報告によれば、ユーザーデータや個人リポジトリ、GitHub.comを含むサービスには一切の影響がなかったという。
攻撃者は漏洩したトークン（認証情報）を用いて、GitHub社が管理していた内部リポジトリの一部を閲覧・クローンした。ただし、ソースコードの改ざんやマルウェアの注入、ユーザー情報へのアクセスは確認されていない。GitHubのインシデント対応チームは、発覚から数分以内に問題のトークンを無効化し、侵入経路を遮断した。
本稿ではこのインシデントの技術的な背景、影響範囲、そしてGitHubを利用する開発者が今すぐ実践すべきセキュリティ対策について詳しく解説する。大規模プラットフォームでさえトークン管理のミスが致命的になりうるという現実は、すべてのソフトウェア開発者にとって重要な教訓だ。
何が起きたのか、侵入の経路と期間
GitHubによれば、最初に異常が検知されたのは2026年5月中旬のことだ。同社のセキュリティ監視システムが、特定のGitHub Actionsトークンを用いた不審なリポジトリアクセスを検出した。このトークンはある外部サービスとのインテグレーションに使用されていたが、意図しない形で第三者の手に渡っていた。
トークンとは、パスワードの代わりにシステム間の認証に使う文字列のことを指す。たとえばAPIを呼び出すときやCI/CDパイプライン（コードのビルドやテストを自動化する仕組み）でリポジトリにアクセスする際に必要になる。このトークンが漏れると、正規のユーザーになりすましてリポジトリを操作できてしまう。
問題のトークンは、GitHubが所有する特定のリポジトリに対する読み取り権限と、一部のリポジトリに対しては書き込み権限も持っていた。これにより攻撃者は、リポジトリの内容を手元にクローン（複製）することが可能だった。ただしGitHubの発表では、攻撃者が実際にコードを改ざんしたり、悪意ある変更を加えたりした証拠は見つかっていないとされている。
攻撃者の行動を振り返る
GitHubのセキュリティチームがログを詳細に分析したところ、攻撃者は以下のような行動をとっていた。トークンを取得したあと、GitHubのAPIを経由してターゲットのリポジトリリストを取得。次に、少数のリポジトリを選んでクローン操作を実行していた。このアクセスパターンは自動化されたスクリプトによるものではなく、人間が手動で操作している形跡が強かったという。
重要なのは、攻撃者がアクセスできたのが「GitHub自身が管理する内部リポジトリ」に限定されていた点だ。一般ユーザーや企業がGitHub上で運用するプライベートリポジトリ、オープンソースプロジェクトのリポジトリ、そしてGitHub.comのサービス基盤そのものには一切アクセスできていなかった。
上の図は、今回のインシデントにおける攻撃者の侵入経路とGitHubが取った即時対応を比較したものだ。漏洩トークンによる不正アクセスは数分で封じ込められ、ログ解析によって影響範囲が正確に特定された。
なぜトークンは漏洩したのか
現時点でGitHubは、トークン漏洩の正確な経路について詳細を明らかにしていない。しかし、過去数年にわたってソフトウェア業界で多発しているトークン漏洩インシデントと照らし合わせると、いくつかの可能性が浮かび上がる。
考えられる漏洩パターン
最も多いのは、ソースコード内にトークンがハードコード（直接埋め込み）されていたケースだ。開発中の利便性からAPIキーやシークレットをコードに直書きし、そのままGitHubの公開リポジトリや内部リポジトリにプッシュしてしまう事故は後を絶たない。
別の可能性としては、CI/CDパイプラインの設定ミスだ。GitHub Actionsのワークフローファイルが適切に構成されておらず、ログにトークンが表示されていたり、サードパーティのサービスに意図せずトークンが送信されていたりするケースがある。
三つ目のパターンは、サプライチェーン攻撃だ。依存している外部ライブラリやツールに悪意あるコードが仕込まれ、ビルドプロセス中に環境変数からトークンを抜き取る手法である。2024年以降、AI開発ツールの増加に伴い、この種の攻撃は急増している。
いずれの経路であれ、根本的な問題は「トークンの権限が必要以上に強かった」ことだ。原則として、トークンには作業に必要な最小限の権限だけを付与すべきである。この「最小権限の原則」を守っていれば、たとえトークンが漏洩しても被害範囲は限定的だったはずだ。
インテグレーションの盲点
今回のケースで注目すべきは、攻撃者が狙ったのが「GitHub自身が所有する内部リポジトリ」であり、ユーザーのリポジトリではなかった点だ。Alexis Wales氏の発表によると、漏洩したトークンは外部サービスとのインテグレーションに使われていた。つまり、GitHubが信頼できるパートナーとして連携していたサービス側で何らかのセキュリティ問題が発生し、トークンが漏洩した可能性が高い。
これは多くの企業が直面するジレンマを浮き彫りにしている。業務効率化のために外部サービスとの連携を深めるほど、トークンの管理箇所は増え、攻撃対象領域（アタックサーフェス）も広がる。GitHubのようなセキュリティ専門企業でさえ、このバランスに苦心しているのだ。
影響範囲と被害の実態
GitHubが公表した調査結果から、今回のインシデントで実際にどのような影響があったのかを具体的に見ていく。
図の通り、影響は極めて限定的だった。GitHubの広報は「ソースコードの一部が意図せず開示された可能性は否定できないが、ユーザーに対する二次被害や連鎖的なセキュリティ侵害は発生していない」としている。
ソースコードの改ざんはなかった
GitHubの調査チームが最も注意深く検証したのは、攻撃者がリポジトリのコードを改ざんしたかどうかだ。結論としては、コミットログやファイルのハッシュ値を含む完全な監査の結果、コードの修正・削除・マルウェアの注入を示す証拠は一切確認されなかった。
これはGitHubのバージョン管理システム（Git）の特性が功を奏した面もある。Gitはすべての変更履歴をSHA-1ハッシュで保護しており、過去のコミットを改ざんしようとすると直ちに検知できる仕組みになっている。攻撃者が万が一コードを書き換えたとしても、その痕跡は完全に残るため、発見は容易だったはずだ。
このインシデントから開発者が学ぶべきこと
GitHubのような巨大プラットフォームですらトークン漏洩を完全に防げなかった事実は、すべての開発者にとって警鐘だ。しかしこのインシデントからは、単に驚くだけでなく、具体的な教訓と実践可能な対策を引き出すことができる。
トークン管理の基本を徹底する
GitHubはインシデント報告の中で、トークン管理のベストプラクティスを改めて強調している。特に重要なのは以下の4点だ。
- トークンの有効期限を短く設定する。可能であれば数時間単位でローテーションする
- トークンに付与する権限を必要最小限に絞り込む。特定のリポジトリだけに読み取り権限を与え、書き込みは別トークンに分離する
- ソースコードや設定ファイルにトークンを直接記述しない。GitHubのシークレット機能や専用のシークレット管理サービス（例としてHashiCorp Vaultやクラウド各社のキー管理サービス）を使う
- リポジトリにトークンが誤ってプッシュされていないか、定期的にスキャンする。GitHubにはプッシュ時に自動検出する機能が標準搭載されている
これらの対策は決して難しいものではない。むしろGitHub Actionsや各種CI/CDツールには、トークンを安全に扱うための仕組みが最初から用意されている。設定を後回しにせず、プロジェクト開始時点で組み込んでしまうのが賢いやり方だ。
侵害を前提とした設計へ
より根本的な教訓は「侵害は起こりうる」という前提に立つことだ。どんなにセキュリティに投資していても、サプライチェーン攻撃やゼロデイ脆弱性（修正パッチが存在しない未知の脆弱性）によって防御線を突破される可能性は常にある。
GitHubのインシデント対応が迅速だった背景には、異常なAPI呼び出しパターンを即座に検知できる監視システムと、トークンを数クリックで無効化できる運用フローが整備されていたことがある。これらは事後対応（インシデントレスポンス）の設計が十分だったからこそ機能した。
この図が示すように、セキュリティの考え方は「侵入を100%防ぐ」から「侵入されても被害を最小限に抑える」へとシフトする必要がある。具体的には、トークンの権限制限、ネットワークのセグメント分離、操作ログの集中管理といった対策を組み合わせることになる。
GitHubの対応から見る、透明性あるインシデント開示の重要性
今回のインシデントで特筆すべきは、GitHubが公表のタイミングと内容において高い透明性を示したことだ。CISOであるAlexis Wales氏が自ら筆を取り、わずか数日のうちに詳細な調査報告を公開した。
セキュリティ業界では、こうした迅速な情報開示は「ラディカル・トランスペアレンシー（徹底した透明性）」と呼ばれ、近年ではGoogleやMicrosoftも同様の姿勢を取っている。ユーザーにとっては、隠蔽されるよりも正直に報告されたほうが信頼を損なわず、適切な防御策を取る時間も確保できる。
GitHubの発表には「ユーザーが取るべき具体的なアクションはない」と明記されていた。これ自体が重要な情報だ。影響範囲が明確に線引きされているからこそ、ユーザーは不要な心配をせずに済む。逆に言えば、影響範囲が不明瞭な発表ほどユーザーの不安と憶測を招く。
この記事のポイント
- 2026年5月、GitHubが内部リポジトリへの不正アクセスを公表。攻撃者は漏洩したトークンを使用して一部のリポジトリを閲覧・クローンしたが、コードの改ざんやユーザーデータへのアクセスはなかった
- 影響を受けたのはGitHub自身が所有する一部の内部リポジトリのみで、一般ユーザーのプライベートリポジトリやオープンソースリポジトリには一切影響が及んでいない
- トークン漏洩の原因は調査中だが、過去の業界事例からハードコードやCI/CD設定ミス、サプライチェーン攻撃などの可能性が考えられる
- 開発者が取るべき対策は明確で、トークンの有効期限短縮、最小権限の原則の徹底、シークレット管理サービスの利用、プッシュ時の自動スキャン活用が有効
- GitHubの迅速かつ透明性の高いインシデント開示姿勢は、業界全体の模範となる対応だった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験