補助金フラッシュ 士業編集部サプライチェーン攻撃は、取引先やソフトウェアの更新を狙う古典的な脅威だと思われがちです。ですが今の実務で本当に怖いのは、信頼していた更新が認証情報の流出に変わり、そのまま本番環境まで広がることです。
本記事では、Nxの事例を軸に、攻撃手法の全体像と、企業が優先して見直すべきセキュリティ対策を整理します。
なぜ更新1回が全社被害に変わるのか?
Nxの事例で見えた72時間の連鎖
2025年、JavaScript開発で広く使われるビルドツールNxが侵害された事例で注目すべきなのは、改ざんパッケージが公開されたこと自体より、そこから被害組織のクラウド管理権限まで一気に広がった点です。
Google Cloudの報告では、開発者端末で実行された不正コードがGitHubの個人用トークンを盗み、その後の偵察、CI/CD環境の悪用、AWS権限昇格を経て、72時間未満でAWS管理者権限の取得まで進みました。S3上のデータ窃取、EC2とRDSの停止、GitHubリポジトリの公開まで起きており、被害は単なる開発環境の事故では終わっていません。1
この事例は、サプライチェーン攻撃を仕入先や委託先だけの問題として見るのが危険だと教えてくれます。ソフトウェアライブラリ、パッケージ公開基盤、CI/CD(テストや公開を自動化する仕組み)、クラウド連携まで含めて、自社の業務が外部の仕組みとつながっている場所すべてが対象になるからです。
経済産業省も、取引先の対策状況を外から判断しにくい現状を踏まえ、サプライチェーン全体の対策水準を見える化する制度を2026年度に始める方向で整備を進めています。2
本当に怖いのは、改ざんパッケージの後ろにある権限設計
Nxの公表資料によると、悪性版パッケージがnpm上に存在した時間は約4時間でした。長期間の潜伏ではありません。それでも被害が大きくなったのは、短い公開時間でも、盗まれた認証情報が次の足場になったからです。3
ここで押さえたいのは、サプライチェーン攻撃の本質が入口の改ざんだけではなく、入口の後ろにある権限の連鎖だということです。
更新や依存関係の取り込みは毎日の業務に溶け込んでいます。そこに個人用トークン、CI/CDの実行権限、クラウドの信頼設定が無防備につながっていると、攻撃者は人手をほとんどかけずに次の段階へ進めます。
ここまでで、入口そのものより横展開の設計が重要だと分かります。次に、その横展開がどの手口で起きたのかを見ます。
どの攻撃手法が被害を広げるのか?
PRの自動処理とインストール時スクリプトが入口になる
Nxの事後報告では、最初の突破口はGitHub Actions(開発作業を自動で実行する仕組み)のワークフローでした。攻撃者はpull_request_targetを使ったPRタイトル検証ワークフローの注入弱点を悪用し、リポジトリ権限でコマンドを実行できる状態を作っています。
GitHub Security Labは以前から、pull_request_targetと信頼できないPR内容の取り扱いを組み合わせると、npm installのような処理経由で危険なコードが動き得ると警告していました。GitHubの公式ドキュメントも、信頼できないコードを明示的にチェックアウトする使い方はリポジトリ侵害につながると案内しています。345
その後、攻撃者は盗んだトークンを使って公開用ワークフローを動かし、npmの公開トークンを抜き取りました。そして改ざん版Nxをnpmへ公開し、利用者側ではpostinstallと呼ばれるインストール直後に自動実行される処理を通じて情報窃取が始まりました。
利用者が怪しい添付ファイルを開いたわけではありません。いつもの更新作業が、そのまま攻撃の実行タイミングになったことが、この手口の厄介さです。13
個人用トークンとOIDC連携が横展開の通路になる
Google Cloudの報告では、被害組織の開発者端末から盗まれたのはGitHubの個人用トークンでした。個人用トークン(Personal Access Token, PAT)は、持ち主の代わりにGitHubへアクセスできる認証情報です。GitHubは、より範囲を絞れるfine-grained PATの利用を推奨しており、対象リポジトリや権限を細かく制限できます。
裏を返すと、広い権限を持つトークンが端末に残っていると、流出時の被害も持ち主の権限に引っ張られます。6
さらに問題を大きくしたのが、GitHub ActionsとAWSのOIDC連携でした。OIDC(OpenID Connect)自体は、長期の秘密鍵を置かずにクラウドへ接続できる安全な仕組みです。
ただし、AWSもGitHubも、どの組織、どのリポジトリ、どのブランチからの要求だけを信頼するかという条件設定と、付与する権限の最小化が必要だと案内しています。
今回の事例では、その役割が広すぎたため、攻撃者はCloudFormation(AWSの構成変更を自動化する機能)経由で新しいIAMロール(AWSの権限設定)を作成し、管理者権限を付けられました。178
ここまでを見ると、攻撃手法の中心はマルウェアの巧妙さだけではありません。認証情報の保管場所、CI/CDの実行権限、クラウド側の信頼設定が一直線につながっていたことが、被害を広げた主要因でした。だから対策も、パッケージ監視だけでは足りません。
次は、優先順位を絞って対策を考えます。
何を優先して直せばよいのか?
トークンを短命にし、使える範囲を細かく絞る
優先順位の一番上に置くべきなのは、長く使える認証情報を減らすことです。GitHubはfine-grained PATの利用を推奨しており、対象組織、対象リポジトリ、権限、承認の要否まで細かく設定できます。
どうしても個人用トークンが必要な場面でも、有効期限を付け、必要最小限の権限だけを与え、そのまま読める設定ファイルや開発端末へ残しっぱなしにしない運用へ変えるべきです。6
パッケージ公開側でも同じです。npmはTrusted publishingを提供しており、GitHub ActionsなどのCI/CDとOIDCで結び、長期のnpm書き込みトークンを使わずに公開できます。Nxも事後対応でこの方式へ切り替えました。
加えて、公開物の由来を確認できるプロベナンス情報を使えば、どのワークフローから出た成果物かを後から検証しやすくなります。39
GitHub Actionsは、危険な設定を減らしてから使う
二つ目の優先事項は、GitHub Actionsの既定設定を鵜呑みにしないことです。GitHubは2023年2月、新しく作られるリポジトリではGITHUB_TOKENを既定で読み取り中心にする変更を案内しました。
ただ、既存の組織やリポジトリには自動適用されませんでした。CodeQLの公式解説でも、2023年2月より前に作られた組織やリポジトリは既定でread-writeのままであると説明されています。見直したつもりでも、古い設定が残っている可能性があります。1011
そのため、実務ではワークフローごとにpermissionsを明示し、つまり必要な権限だけを書くことが重要です。
あわせて、pull_request_targetを本当に必要な場面だけに限定し、信頼できないコードをその文脈で実行しないようにします。外部製のActionはフル長のコミットSHAで固定し、ワークフローファイルの変更にはレビュー担当を必須にします。GitHubは、コミットSHAで固定する方法が、Actionの版を確実に固定する唯一の方法だと明記しています。5
ここまでで、直すべき場所はかなり絞れます。トークン、ワークフロー、クラウド連携の三つです。最後に、現場で最初に確認したい項目を、開発部門だけに閉じない形で整理します。
自社で最初に確認したい項目
依存パッケージより先に、認証情報の置き場を見る
インシデント対応でありがちなのは、パッケージ名やバージョンの確認だけに時間を使い、すでに流出した認証情報の封じ込めが遅れることです。
Nxの公表資料でも、影響確認の入口としてGitHubのセキュリティログを見て不審なリポジトリ作成がないか確かめ、見つかった場合はGitHub CLIの認可取り消しや各種トークンのローテーションを進めるよう案内しています。3
最初の確認項目は、たとえば次の順番にすると動きやすくなります。
- GitHub、npm、クラウドの認証情報をどこに保存しているか
- CI/CDからクラウドへ渡している権限に、管理者級の操作が含まれていないか
- 端末や開発コンテナに、長期トークンやそのまま読める設定ファイルが残っていないか
- 依存パッケージの更新を、どの端末と権限で実行しているか
この順番の狙いは明確です。入口の特定より先に、被害拡大の通路を閉じるためです。サプライチェーン攻撃は、最初の改ざんを完全に予防できなくても、通路を細くしていれば本番環境まで届きにくくなります。
取引先にも求める基準を決めておく
もう一つ重要なのは、自社だけ安全でも足りないことです。とくに外部の開発会社、SaaS(クラウドサービス)、委託先、オープンソース依存が多い企業では、どの条件を満たす相手と連携するのかを決めておかないと、毎回の調達や契約が担当者任せになります。
経済産業省が進める評価制度も、まさに取引先の対策状況を見える化し、発注側と受注側で求める水準を合わせやすくする狙いがあります。2
求める基準は、難しい監査票から始めなくても構いません。公開ワークフローの権限を絞っているか、発行トークンに有効期限があるか、クラウド連携はOIDCの条件付きで動いているか、公開物の由来を確認できるか。この四つだけでも、質問の質は大きく変わります。サプライチェーン攻撃への備えは、ソフトの安全性だけでなく、認証情報と権限の設計をどこまで管理できているかで決まるからです。
明日からの見直しは、依存パッケージ一覧より先に、その設計図を開くところから始めるのが近道です。
出典・参考資料
「S1ngularity - What Happened, How We Responded, What We Learned」Nx Blog ↩
「Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests」GitHub Security Lab ↩
「セキュリティで保護された使用に関するリファレンス」GitHub Enterprise Server 3.20 Docs ↩
「Use IAM roles to connect GitHub Actions to actions in AWS」AWS Security Blog ↩
「GitHub Actions – Updating the default GITHUB_TOKEN permissions to read-only」GitHub Changelog ↩
執筆者：補助金フラッシュ 士業編集部
補助金・助成金の活用法からAI導入、業務の生産性向上まで、中小企業の経営に役立つ情報を士業の専門家チームがわかりやすく解説します。
こちらもおすすめ
小規模事業者のための品質管理入門。顧客信頼を高めるQC活動の始め方
小規模事業者にとって、品質管理は大企業だけの専門業務ではありません。納期どおりに届く、前回と同じ仕上がりになる、問い合わせへの返答がぶれない。こうした日々の安定感が、顧客信頼を支えます。小規模事業者の品質管理は、特別な認証や大きなシステムからではなく、仕事のばらつきを減らす小さなQC活動から始めるのが現実的です。 この記事では、白書のデータと品質管理の基本をもとに、手作業が多い現場でも始めやすい進め方を取り上げます。まずは、身近な仕事のばらつきを見るところから始めましょう。
小規模事業者の経営戦略・経営計画の立て方
SWOT分析で弱みを並べると、経営計画を作った気になりやすいものです。人手が少なく、資金にも時間にも限りがあるほど、気になる弱みは次々に見つかります。 小規模事業者に必要なのは、弱みを全部直すことではなく、限られた人、時間、資金を選ばれる理由へ集めることです。経営戦略は、会社を平均点に近づける作業ではなく、どこで違いを出すかを決める作業です。限られた資源の使い道を決めると、弱みの優先順位も自然に変わります。 この記事では、弱み補強から抜け出し、経営戦略を経営計画へ落とし込む順番を考えます。
小規模事業者の組織・人材マネジメント入門。属人化を防ぎ、少人数でも機能するチームのつくり方
少人数の会社では、ひとりが休むだけで現場の流れが変わります。だからこそ最初から全部任せるより、経営者が仕事の型を作り、育った段階で手放すほうが現実的です。 これは監視を強める話ではなく、誰が担当しても迷わない組織に近づけるための人材マネジメントです。採用が難しい時代に、属人化を防ぎながらチームを育てる考え方を取り上げます。
小規模事業者のための労務管理入門。労働時間管理・給与計算の基本を解説
従業員を雇い始めると、雇用契約、勤怠、給与、届出など、確認することが一気に増えます。小規模事業者の労務管理で最初に整えたいのは、制度名を覚えることよりも、毎日の労働時間を正しく記録し、その記録から給与を計算する流れです。 36協定や就業規則は大切ですが、土台になるのは労働時間管理です。時間があいまいなままでは、給与計算も残業の判断も後から説明しにくくなります。 この記事では、初めて労務管理を見直す人に向けて、どこから手を付けるべきかを実務の順番で整理します。
国の補助金と自治体の上乗せ助成・利子補給制度の併用について解説
国の補助金を見つけると、そこで調べものを終えてしまいがちです。けれども、実際の負担額を大きく変えるのは、国の制度そのものより、その後に使える自治体の上乗せ助成や利子補給であることがあります。 大事なのは、補助金を割引券のように見るのではなく、国、都道府県、市区町村、金融機関がそれぞれ何を支援しているかを分けて見ることです。 この記事では、EV購入、賃上げを伴う設備投資、マル経融資の利子補給を例に、併用を考える順番を整理します。
補助金と融資はどう組み合わせる? 創業期、経営革新期のケース別資金調達プラン
補助金は、設備投資や販路開拓の背中を押してくれる制度です。しかし、採択されたらすぐ資金が入る、と考えて計画を組むと資金繰りでつまずきます。 補助金は投資の実質負担を軽くする手段であり、融資は支払いと入金の時間差を埋める手段です。資金調達プランでは、いくらもらえるかより、いつ支払い、いつ入金され、遅れたときにどこまで耐えられるかを先に見ます。 この記事では、創業期と経営革新期のケース別に、補助金と融資をどう組み合わせるかを整理します。最初の資金繰り表を作る材料としてお役立てください。