タグアーカイブ GitHub Actions

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.2

pull_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、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp