npmとGitHub Actionsのサプライチェーン攻撃を遮断する新防御策
npmとGitHub Actionsを舞台にしたサプライチェーン攻撃が、近年組織化された巧妙な手口で猛威を振るっている。2026年前半、GitHubはこの攻撃連鎖を根本から断つため、数多くの防御策を相次いでリリースした。
公式ブログで公開された内容をもとに、初期侵入の防止、認証情報の抜き取り対策、マルウェア拡散の阻止、インシデント対応まで、最新の変更点をまとめて解説する。CI/CDパイプラインやパッケージレジストリを扱う開発者や運用担当にとって、すぐに活用できる情報が揃っている。
サプライチェーン攻撃の実態と攻撃チェーン
オープンソースエコシステムを標的としたサプライチェーン攻撃は、複数の脆弱性を組み合わせて短期間に被害を拡大する。典型的な流れは、メンテナーのアカウント乗っ取りに始まり、CI/CDワークフローの欠陥を突いてプロジェクトへ侵入し、認証情報を窃取したうえで、マルウェアを仕込んだパッケージを一気に配布するというものだ。
GitHubはこうした攻撃チェーンを研究し、最も効果の高い箇所に対策を集中投入している。以下の図は、よく見られる攻撃のステップを簡略化したものだ。
この連鎖を断ち切るため、GitHubは複数の防御層を設けてきた。次節から順に見ていく。
初期侵入を許さない新たな対策
サプライチェーン攻撃の第一段階は、多くの場合フィッシングによるメンテナーアカウントの侵害だ。また、GitHub Actionsのワークフロー設定ミスを突いた手口も頻発している。これらに対抗するため、2026年6月にいくつかの重要な変更が施された。
高影響度npmアカウントの保護
npmでは、影響度の高いアカウントに対して予防的な保護措置が導入された。メールアドレスの変更や二要素認証のリカバリコードを使用した場合、アカウントは72時間にわたって読み取り専用となる。この猶予期間によって、正当なメンテナーがアカウント回復のための時間を確保し、攻撃者が即座に悪用することを防げる。
GitHub Actionsワークフローの安全強化
GitHub Actionsでは、「pwn request」と呼ばれるフォークからのプルリクエストを通じた不正コード実行が長年の課題だった。これに対処するため、actions/checkout のデフォルト動作が変更され、フォークからの信頼できないコードをチェックアウトしないようになった（明示的にオプトアウトすれば従来どおり利用できる）。
さらに、ワークフローのトリガー（実行条件）に対して、誰がどの種類のトリガーを使えるのかをエンタープライズや組織レベルで制御できるポリシーが追加された。これにより、不要な pull_request_target の使用を禁止したり、信頼できないトリガーの範囲を限定したりできる。
加えて、Actionsのキャッシュ操作にも制限がかかった。信頼度の低いワークフローからは、他のワークフローと共有しているキャッシュを変更できないようにし、キャッシュポイズニングによる権限昇格の道を塞いでいる。
認証情報の抜き取りを防ぐ仕組み
初期侵入に成功した攻撃者は、次にCI/CDパイプラインやリポジトリに残る認証情報を狙う。これらを抜き取られないようにすることが、攻撃拡大を防ぐ要となる。
信頼できる公開で長期クレデンシャルを排除
npmの「Trusted Publishing（信頼できる公開）」は、長期にわたって有効なトークンを使わずにパッケージを公開する機能だ。2026年4月より、CI/CDサービスとしてCircleCIが新たにサポートされたことで、より多くのプロジェクトがこの仕組みを利用できるようになった。CI/CD環境に直接シークレットを置く必要がなくなり、たとえ環境が侵害されてもトークンが漏洩するリスクが大きく下がる。
Actionsネットワークファイアウォール（技術プレビュー）
Actionsワークフローの実行中に発生するすべての外向き通信をログに記録する機能が、テクニカルプレビューとして提供開始された。これにより、悪意のあるコードのダウンロードや、未知のドメインへの認証情報の送信といった異常を検知できる下地が整う。将来的には、ネットワークの出口制限（egress restriction）やポリシーによる遮断も視野に入っている。
攻撃の拡散を封じるnpmとGitHub Actionsの強化
認証情報を手にした攻撃者は、次にマルウェアを仕込んだパッケージを大量に公開し、できるだけ多くのプロジェクトに感染させようとする。拡散速度を落とし、悪用の連鎖を食い止める対策がいくつか実装された。
段階的パブリッシュ（Staged Publishing）
2026年5月からnpmで利用可能になったStaged Publishing（段階的公開）は、CI/CDパイプラインのクレデンシャルだけではパッケージを直接公開できなくする仕組みだ。パイプラインからステージングされたバージョンは、別途npm CLIやWebサイト上での手動承認と二要素認証を経て初めて本公開される。これにより、CI/CDが侵害されても自動的にマルウェアが配布されるリスクを断ち切る。
npm v12でインストールスクリプトをデフォルト無効化
攻撃者はパッケージのインストール時に実行されるスクリプト（install scripts）を悪用し、即座に認証情報を抜き取る手法を多用してきた。2026年6月に発表されたnpm v12では、こうしたインストールスクリプトがデフォルトで無効化される。正当な用途でスクリプトが必要な場合は、利用者が明示的に許可を与えることで再び有効にできる。
Dependabotバージョン更新に3日間のクールダウン
攻撃者は新たに公開した悪意あるバージョンが、Dependabotの自動プルリクエストで一気に下流プロジェクトに取り込まれることを狙う。このスピードを抑制するため、2026年7月からDependabotのバージョン更新にはデフォルトで3日間のクールダウンが設けられた。リリース後少なくとも3日が経過するまでプルリクエストは開かれず、その間にコミュニティや自動検知が悪意あるバージョンを発見する猶予が生まれる。なお、セキュリティアップデートは即時に発行されるため、緊急の修正が遅れることはない。
インシデント対応を迅速化する機能
防御策と並行して、万一の侵害発生時に素早く対処できる機能も強化されている。
セルフサービスでのクレデンシャル無効化
2026年6月、エンタープライズ管理者やメンバーが、自身の全クレデンシャルを即座に無効化できるセルフサービスツールが提供された。2月にリリースされたエンタープライズ全体のクレデンシャル管理機能を拡張したもので、サプライチェーン攻撃で認証情報の漏洩が疑われる場合に、数クリックで影響範囲を封じ込められる。
OAuthトークンとAppトークンの即時失効API
2026年3月には、GitHubのOAuthトークンおよびAppトークンをプログラムから即座に失効させるAPIが拡充された。2025年4月に導入されたPersonal Access Token向けの失効APIに続くもので、公開リポジトリにクレデンシャルが漏れてしまった場合でも、開発者が自身で迅速に無効化できる。漏洩したトークンの悪用可能な期間を大幅に短縮する手段となる。
今後の展望
GitHubは製品をデフォルトで安全にする方針を掲げ、npmとGitHub Actionsの両面からサプライチェーン攻撃の遮断に取り組んでいる。今回紹介した変更は数カ月の成果に過ぎず、引き続きchangelogや公式ブログで新たな対策が発表される見込みだ。
オープンソースの持続可能性と企業の安全な利用を支えるこれらの取り組みは、コミュニティ全体にとって大きな前進といえる。
この記事のポイント
- サプライチェーン攻撃は、アカウント乗っ取りからCI/CD経由でマルウェア配布へと連鎖する。GitHubは各段階に多重の防御を適用している
- npmの高影響度アカウントに72時間の読み取り専用期間を設定し、乗っ取り後の即時悪用を防止
- GitHub Actionsの
pull_request_targetやキャッシュ操作を安全なデフォルトに変更し、初期侵入を抑止 - 長期クレデンシャルを使わない「Trusted Publishing」と「Staged Publishing」で認証情報漏洩と自動公開を遮断
- Dependabotのクールダウンとnpm v12のインストールスクリプト無効化で拡散速度を抑制
- クレデンシャルの即時失効機能により、万が一のインシデント対応を迅速に実施可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
海田 洋祐
・ 複数業界における17年間のデジタルビジネス開発経験 ・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識 ・ 15ヶ国語対応の多言語SaaSの開発経験 ・ 17年間にも及ぶ、Eコマース長期運営経験 ・ 幅広い業界でのSEO最適化の豊富な経験