なぜ更新1回で全社に被害が広がったのか? 事例で分かるサプライチェーン攻撃の手法とセキュリティ対策

なぜ更新1回が全社被害に変わるのか?

Nxの事例で見えた72時間の連鎖

2025年、JavaScript開発で広く使われるビルドツールNxが侵害された事例で注目すべきなのは、改ざんパッケージが公開されたこと自体より、そこから被害組織のクラウド管理権限まで一気に広がった点です。

Google Cloudの報告では、開発者端末で実行された不正コードがGitHubの個人用トークンを盗み、その後の偵察、CI/CD環境の悪用、AWS権限昇格を経て、72時間未満でAWS管理者権限の取得まで進みました。S3上のデータ窃取、EC2とRDSの停止、GitHubリポジトリの公開まで起きており、被害は単なる開発環境の事故では終わっていません。¹

この事例は、サプライチェーン攻撃を仕入先や委託先だけの問題として見るのが危険だと教えてくれます。ソフトウェアライブラリ、パッケージ公開基盤、CI/CD(テストや公開を自動化する仕組み)、クラウド連携まで含めて、自社の業務が外部の仕組みとつながっている場所すべてが対象になるからです。

経済産業省も、取引先の対策状況を外から判断しにくい現状を踏まえ、サプライチェーン全体の対策水準を見える化する制度を2026年度に始める方向で整備を進めています。²

本当に怖いのは、改ざんパッケージの後ろにある権限設計

Nxの公表資料によると、悪性版パッケージがnpm上に存在した時間は約4時間でした。長期間の潜伏ではありません。それでも被害が大きくなったのは、短い公開時間でも、盗まれた認証情報が次の足場になったからです。³

ここで押さえたいのは、サプライチェーン攻撃の本質が入口の改ざんだけではなく、入口の後ろにある権限の連鎖だということです。

更新や依存関係の取り込みは毎日の業務に溶け込んでいます。そこに個人用トークン、CI/CDの実行権限、クラウドの信頼設定が無防備につながっていると、攻撃者は人手をほとんどかけずに次の段階へ進めます。

ここまでで、入口そのものより横展開の設計が重要だと分かります。次に、その横展開がどの手口で起きたのかを見ます。

どの攻撃手法が被害を広げるのか?

PRの自動処理とインストール時スクリプトが入口になる

Nxの事後報告では、最初の突破口はGitHub Actions(開発作業を自動で実行する仕組み)のワークフローでした。攻撃者はpull_request_targetを使ったPRタイトル検証ワークフローの注入弱点を悪用し、リポジトリ権限でコマンドを実行できる状態を作っています。

GitHub Security Labは以前から、pull_request_targetと信頼できないPR内容の取り扱いを組み合わせると、npm installのような処理経由で危険なコードが動き得ると警告していました。GitHubの公式ドキュメントも、信頼できないコードを明示的にチェックアウトする使い方はリポジトリ侵害につながると案内しています。³⁴⁵

その後、攻撃者は盗んだトークンを使って公開用ワークフローを動かし、npmの公開トークンを抜き取りました。そして改ざん版Nxをnpmへ公開し、利用者側ではpostinstallと呼ばれるインストール直後に自動実行される処理を通じて情報窃取が始まりました。

利用者が怪しい添付ファイルを開いたわけではありません。いつもの更新作業が、そのまま攻撃の実行タイミングになったことが、この手口の厄介さです。¹³

個人用トークンとOIDC連携が横展開の通路になる

Google Cloudの報告では、被害組織の開発者端末から盗まれたのはGitHubの個人用トークンでした。個人用トークン(Personal Access Token, PAT)は、持ち主の代わりにGitHubへアクセスできる認証情報です。GitHubは、より範囲を絞れるfine-grained PATの利用を推奨しており、対象リポジトリや権限を細かく制限できます。

裏を返すと、広い権限を持つトークンが端末に残っていると、流出時の被害も持ち主の権限に引っ張られます。⁶

さらに問題を大きくしたのが、GitHub ActionsとAWSのOIDC連携でした。OIDC(OpenID Connect)自体は、長期の秘密鍵を置かずにクラウドへ接続できる安全な仕組みです。

ただし、AWSもGitHubも、どの組織、どのリポジトリ、どのブランチからの要求だけを信頼するかという条件設定と、付与する権限の最小化が必要だと案内しています。

今回の事例では、その役割が広すぎたため、攻撃者はCloudFormation(AWSの構成変更を自動化する機能)経由で新しいIAMロール(AWSの権限設定)を作成し、管理者権限を付けられました。¹⁷⁸

ここまでを見ると、攻撃手法の中心はマルウェアの巧妙さだけではありません。認証情報の保管場所、CI/CDの実行権限、クラウド側の信頼設定が一直線につながっていたことが、被害を広げた主要因でした。だから対策も、パッケージ監視だけでは足りません。

次は、優先順位を絞って対策を考えます。

何を優先して直せばよいのか?

トークンを短命にし、使える範囲を細かく絞る

優先順位の一番上に置くべきなのは、長く使える認証情報を減らすことです。GitHubはfine-grained PATの利用を推奨しており、対象組織、対象リポジトリ、権限、承認の要否まで細かく設定できます。

どうしても個人用トークンが必要な場面でも、有効期限を付け、必要最小限の権限だけを与え、そのまま読める設定ファイルや開発端末へ残しっぱなしにしない運用へ変えるべきです。⁶

パッケージ公開側でも同じです。npmはTrusted publishingを提供しており、GitHub ActionsなどのCI/CDとOIDCで結び、長期のnpm書き込みトークンを使わずに公開できます。Nxも事後対応でこの方式へ切り替えました。

加えて、公開物の由来を確認できるプロベナンス情報を使えば、どのワークフローから出た成果物かを後から検証しやすくなります。³⁹

GitHub Actionsは、危険な設定を減らしてから使う

二つ目の優先事項は、GitHub Actionsの既定設定を鵜呑みにしないことです。GitHubは2023年2月、新しく作られるリポジトリではGITHUB_TOKENを既定で読み取り中心にする変更を案内しました。

ただ、既存の組織やリポジトリには自動適用されませんでした。CodeQLの公式解説でも、2023年2月より前に作られた組織やリポジトリは既定でread-writeのままであると説明されています。見直したつもりでも、古い設定が残っている可能性があります。¹⁰¹¹

そのため、実務ではワークフローごとにpermissionsを明示し、つまり必要な権限だけを書くことが重要です。

あわせて、pull_request_targetを本当に必要な場面だけに限定し、信頼できないコードをその文脈で実行しないようにします。外部製のActionはフル長のコミットSHAで固定し、ワークフローファイルの変更にはレビュー担当を必須にします。GitHubは、コミットSHAで固定する方法が、Actionの版を確実に固定する唯一の方法だと明記しています。⁵

ここまでで、直すべき場所はかなり絞れます。トークン、ワークフロー、クラウド連携の三つです。最後に、現場で最初に確認したい項目を、開発部門だけに閉じない形で整理します。

自社で最初に確認したい項目

依存パッケージより先に、認証情報の置き場を見る

インシデント対応でありがちなのは、パッケージ名やバージョンの確認だけに時間を使い、すでに流出した認証情報の封じ込めが遅れることです。

Nxの公表資料でも、影響確認の入口としてGitHubのセキュリティログを見て不審なリポジトリ作成がないか確かめ、見つかった場合はGitHub CLIの認可取り消しや各種トークンのローテーションを進めるよう案内しています。³

最初の確認項目は、たとえば次の順番にすると動きやすくなります。

• GitHub、npm、クラウドの認証情報をどこに保存しているか
• CI/CDからクラウドへ渡している権限に、管理者級の操作が含まれていないか
• 端末や開発コンテナに、長期トークンやそのまま読める設定ファイルが残っていないか
• 依存パッケージの更新を、どの端末と権限で実行しているか

この順番の狙いは明確です。入口の特定より先に、被害拡大の通路を閉じるためです。サプライチェーン攻撃は、最初の改ざんを完全に予防できなくても、通路を細くしていれば本番環境まで届きにくくなります。

取引先にも求める基準を決めておく

もう一つ重要なのは、自社だけ安全でも足りないことです。とくに外部の開発会社、SaaS(クラウドサービス)、委託先、オープンソース依存が多い企業では、どの条件を満たす相手と連携するのかを決めておかないと、毎回の調達や契約が担当者任せになります。

経済産業省が進める評価制度も、まさに取引先の対策状況を見える化し、発注側と受注側で求める水準を合わせやすくする狙いがあります。²

求める基準は、難しい監査票から始めなくても構いません。公開ワークフローの権限を絞っているか、発行トークンに有効期限があるか、クラウド連携はOIDCの条件付きで動いているか、公開物の由来を確認できるか。この四つだけでも、質問の質は大きく変わります。サプライチェーン攻撃への備えは、ソフトの安全性だけでなく、認証情報と権限の設計をどこまで管理できているかで決まるからです。

明日からの見直しは、依存パッケージ一覧より先に、その設計図を開くところから始めるのが近道です。

1. 「Cloud Threat Horizons Report H1 2026」Google Cloud ↩

2. 「サプライチェーン強化に向けたセキュリティ対策評価制度構築に向けた中間取りまとめを公表しました」経済産業省 ↩

3. 「S1ngularity - What Happened, How We Responded, What We Learned」Nx Blog ↩

4. 「Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests」GitHub Security Lab ↩

5. 「セキュリティで保護された使用に関するリファレンス」GitHub Enterprise Server 3.20 Docs ↩

6. 「Managing your personal access tokens」GitHub Docs ↩

7. 「Use IAM roles to connect GitHub Actions to actions in AWS」AWS Security Blog ↩

8. 「アマゾン ウェブ サービスでの OpenID Connect の構成」GitHub ドキュメント ↩

9. 「Trusted publishing for npm packages」npm Docs ↩

10. 「GitHub Actions – Updating the default GITHUB_TOKEN permissions to read-only」GitHub Changelog ↩

11. 「Workflow does not contain permissions」CodeQL ↩