top of page
Blog article

Blog article

基盤の強化：GitHubによるnpmサプライチェーンセキュリティ抜本改革の詳細分析

エグゼクティブサマリー


2025年9月に発生した一連のサプライチェーン攻撃、特に自己増殖型ワーム「Shai-Hulud」は、npmエコシステムの認証および公開ワークフローにおける体系的な弱点を露呈させ、JavaScriptサプライチェーン全体の完全性を脅かす事態となりました 1。これらの攻撃は、GitHubによるnpmエコシステムのセキュリティ基盤を根本的に見直す直接的なきっかけとなりました。

これに対しGitHubは、アカウント乗っ取り、トークン窃取、悪意のあるパッケージの注入に対してnpmレジストリを事前対策的に強化するため、3つの柱からなる戦略を発表しました。この戦略は、フィッシング耐性のある二要素認証（2FA）の義務化、有効期間の長いトークンを廃止し短命な粒度の細かいトークンへの移行、そしてTrusted Publishingを介したトークンレスCI/CD認証の推進から構成されています 1。

この対応は、発見後に悪意のあるパッケージを削除するといった事後対応的なインシデント対応から、すべての発行者に対するベースラインセキュリティを引き上げる事前対策的な多層防御モデルへの重要なパラダイムシフトを意味します 2。これは、OpenSSF（Open Source Security Foundation）などの組織が推進する、エコシステム横断的な新たなセキュリティ標準にnpmを整合させる動きでもあります 5。

これらの変更は、すべてのnpmメンテナーと組織に対してワークフローの更新を要求します。GitHubは混乱を最小限に抑えるための段階的な展開を約束していますが 6、積極的な採用が不可欠です。本レポートでは、これらの対策を詳細に分析し、この移行を乗り切るための戦略的ガイドを提供します。


セクション1：変革の触媒：2025年npmサプライチェーン攻撃の解剖


本セクションでは、GitHubによる抜本的な変更の背景にある重要な文脈を提供するため、それを必要とさせた攻撃の性質とメカニズムを分析します。


1.1 「Shai-Hulud」ワーム：自己増殖する新種の脅威


一連の攻撃の中でも、「Shai-Hulud」と名付けられたワームは、その巧妙な自己増殖メカニズムにより、npmエコシステムに前例のない脅威をもたらしました。


初期ベクトル：人的要因


攻撃チェーンは一貫して、人気のあるnpmパッケージのメンテナーを標的としたフィッシングキャンペーンから始まりました 8。攻撃者は、公式のnpmセキュリティアラートを装ったメールなどのソーシャルエンジニアリング手法を用い、開発者を偽のログインページに誘導して認証情報を入力させることで、アカウントへのアクセス権を奪取しました 8。


増殖メカニズム：ワーム


従来の攻撃とは異なり、Shai-Huludは自己増殖型のワームでした 1。その悪意のあるペイロードの中核は、実行されると侵害された環境内で追加のnpmトークンをスキャンする

post-installスクリプトでした 12。トークンが発見されると、それを利用して、侵害されたメンテナーがアクセス権を持つ他のパッケージに悪意のあるコードを自動的に注入し、汚染された新しいバージョンを公開しました。これにより、さらなる人間の介入なしにレジストリ全体に自己を拡散させることが可能でした 12。


ペイロード：高度な機密情報収集


このマルウェアの能力は、単にnpmトークンを盗むだけにとどまりませんでした。オープンソースのシークレットスキャンツールであるTruffleHogを積極的に展開し、被害者のファイルシステムをスキャンして、GitHub Personal Access Token（PAT）やAWS、GCP、AzureなどのクラウドサービスのAPIキーを含む、広範な機密情報を収集しました 12。


データ漏洩と影響


収集された機密情報は、webhook.siteエンドポイントへのPOSTや、最も大胆な手口として、被害者のアカウント下に「Shai-Hulud」という名前の公開GitHubリポジトリを作成し、盗んだデータをダンプするなど、複数のチャネルを通じて漏洩されました 12。このワームはまた、プライベートリポジトリを公開状態にしようと試みました 12。この攻撃により、GitHubとコミュニティによって封じ込められるまでに500以上のパッケージが侵害されました 3。

このShai-Hulud攻撃は、npmレジストリの相互接続性を逆手に取った戦略的な転換点でした。自己増殖する性質は、たった一人の侵害されたメンテナーがエコシステム全体に連鎖的な障害を引き起こす可能性があることを示し、脅威モデルを個別のインシデントから体系的なリスクへと根本的に変化させました。従来の攻撃は線形的でしたが、Shai-Huludは再帰的なループを導入し、指数関数的な拡散の可能性を生み出しました。GitHubのXavier René-Corail氏が指摘したように、これは「無限の攻撃の流れを可能にした可能性」がありました 1。これにより、脅威は単なるコンテンツの問題（一部のパッケージに悪意のあるコードが含まれていること）から、インフラの完全性の問題（レジストリ自体が指数関数的な攻撃拡散の媒介となること）へと昇格しました。したがって、GitHubの対応も同様に体系的である必要がありました。マルウェアスキャンを改善するだけでは不十分であり、この増殖サイクルを根源で断ち切るために、中核となる認証と公開のメカニズムを再設計する必要があったのです。


1.2 先行インシデントと体系的な脆弱性


Shai-Huludの出現以前にも、npmエコシステムは同様の攻撃ベクトルを利用した深刻なインシデントを経験しており、これが後の大規模な侵害の土壌となりました。


暗号資産窃取キャンペーン


Shai-Huludに先立ち、2025年9月初旬には、chalk、debug、ansi-stylesといった、合わせて週に26億回以上ダウンロードされる基盤的なパッケージを標的とした大規模な攻撃が発生しました 10。この攻撃の悪意のあるペイロードは、ブラウザ環境に自身を注入し、暗号資産の取引を傍受して宛先アドレスを攻撃者が管理するウォレットに書き換える、洗練された「ウォレットドレイナー」でした 9。この攻撃もまた、一人のメンテナーに対するフィッシングキャンペーンの成功に端を発しています 10。


post-installスクリプトの悪用


これらの攻撃に共通するテーマは、npmのpost-installスクリプト機能の悪用です 3。この機能は、正当なセットアップタスクのために設計されていますが、パッケージのインストール時に任意のコードを実行できるため、マルウェア配布のための強力で広く悪用されるベクトルとなっています 9。


長命トークンの内在的リスク


これらの攻撃は、有効期間が長く、広範な権限を持つ「クラシック」npmトークンの極めて高い危険性を浮き彫りにしました。一度トークンが盗まれると、手動で失効されるまで永続的で強力なアクセスを提供し、攻撃者に損害を与える十分な時間を与えていました 22。これらのトークンがCI/CD環境にシークレットとして保存されていることが多かったため、漏洩の主要な標的となっていました 22。


セクション2：GitHubの新セキュリティフレームワークの解体：多層防御


本セクションでは、GitHubの新しいセキュリティモデルの3つの柱について技術的な詳細を掘り下げ、各コンポーネントが最近の攻撃で露呈した特定の脆弱性にどのように対処するかを分析します。

特徴

レガシーモデル（旧方式）

強化モデル（新方式）

主要なセキュリティ改善点

2FA方式

TOTP（時間ベースのワンタイムパスワード）。フィッシングに対して脆弱。

FIDO/WebAuthnベースの2FAを推奨・義務化。

フィッシング耐性があり、中間者攻撃を根本的に防ぐ。

ローカル公開

2FAのバイパスが可能だった。

2FAが必須となり、バイパスオプションは削除。

メンテナーの対話的な公開操作のセキュリティを強制的に強化。

CI/CDトークン

「クラシック」または「オートメーション」トークン。長命で広範な権限を持つ。

粒度の細かいアクセストークン（Granular Access Token）。発行権限を持つトークンは7日間で失効。

侵害されたトークンの影響範囲と有効期間を劇的に縮小し、永続的なアクセスのリスクを軽減。

CI/CD認証

長命トークンをCI/CDのシークレットとして保存。

Trusted Publishing（OIDC）。トークンレス認証。

CI/CD環境から永続的なシークレットを排除し、トークン窃取の主要な攻撃ベクトルを無効化。


2.1 第1の柱：フィッシング耐性のある2FAによる発行者アイデンティティの強化


GitHubは、TOTP（Time-based One-Time Password）ベースの2FAを廃止し、公開アクションに対してより強力なFIDOベースの2FA（WebAuthn経由）の使用を義務付けます 1。ローカルでのパッケージ公開時に2FAをバイパスするオプションは完全に削除されます 1。

この変更の技術的な根拠は、両者のフィッシング耐性の違いにあります。TOTPは2FAがないよりは優れていますが、フィッシングに対して脆弱です。攻撃者は本物そっくりの偽ログインページを作成し、ユーザー名、パスワード、そして6桁のTOTPコードをリアルタイムで本物のサイトに中継することで、セッションクッキーを奪い、アクセス権を得ることができます 25。これは最近の攻撃で主要なベクトルとなりました。一方、FIDOベースの認証はフィッシング耐性があります。認証プロセスはクレデンシャルをオリジン（ウェブサイトのドメイン）に結びつけます。ユーザーが騙されたとしても、ハードウェアキーや生体認証センサーは偽のドメインでの認証を拒否します。これにより、フィッシング攻撃の連鎖を根本的な暗号レベルで断ち切ることができます 6。

これは長期的なトレンドの加速です。GitHubは2022年初頭に上位100のnpmパッケージのメンテナーに2FAを義務付け始め 27、徐々に要件を拡大してきました 28。最近の攻撃は、最も強力な形式の2FAを義務付け、より脆弱な方法を廃止する動機となりました。


2.2 第2の柱：粒度の細かい短命トークンによるトークン侵害リスクの軽減


レガシーな「クラシック」トークンは廃止されます 1。パッケージの公開には粒度の細かいアクセストークン（Granular Access Token）の使用が必須となり、決定的に重要な点として、公開権限を持つトークンは最大7日間の有効期間に制限されます 1。さらに、デフォルトでトークンによる公開アクセスは無効化され、ユーザーはより安全な代替手段へと誘導されます 1。

クラシックな「オートメーション」または「パブリッシュ」トークンは大きな負債でした。一度作成されるとローテーションされることはほとんどなく、ユーザーのアカウントと同等の権限を持ち、ユーザーがアクセスできるすべてのパッケージに公開可能でした 31。侵害されたクラシックトークン一つが「マスターキー」となり得たのです 23。

これに対し、粒度の細かいアクセストークンは、最小権限の原則を可能にします。特定のパッケージやスコープに限定したり、読み取り専用または読み書き権限に制限したり、IPアドレス範囲でアクセスを制限したりすることができます 23。

そして、7日間の有効期限という新しい制御が最もインパクトがあります。たとえ公開権限を持つ粒度の細かいトークンが盗まれたとしても、攻撃者にとっての有用性は最大1週間に限定されます。これにより、悪用の機会が劇的に減少し、自動化ワークフローに定期的なトークンローテーションというセキュリティのベストプラクティスを組み込むことが強制されます 1。


2.3 第3の柱：Trusted Publishingによるトークンレス認証へのパラダイムシフト


GitHubは現在、Trusted Publishingの採用を強く推奨しています。これは、OpenID Connect（OIDC）を使用してCI/CDワークフローをnpmレジストリで直接認証し、長命トークンの必要性を完全に排除するメカニズムです 1。

OIDCの仕組みは以下の通りです：

  1. 設定：メンテナーはnpmjs.comで信頼関係を設定し、特定のGitHub組織、リポジトリ、ワークフローファイル（例：publish.yml）が特定のパッケージを公開することを承認します 22。

  2. CI/CD実行：信頼されたGitHub Actionsワークフローが実行されると、GitHubから短命のOIDC IDトークンを要求します。このトークンは、ワークフローのコンテキスト（リポジトリ名、コミットSHAなど）に関するクレームを含む暗号署名付きJWTです 22。

  3. トークン交換：npm publishコマンドがこのOIDCトークンをnpmレジストリに送信します。

  4. 検証：npmはJWTの署名を検証し、そのクレームを事前に設定された信頼ポリシーと照合します。一致すれば、npmは非常に短命で一度しか使えないAPIトークンをワークフローランナーに返します 33。

  5. 公開：ランナーはこの一時的なAPIトークンを使用してパッケージをアップロードします。このトークンは直後に失効し、後で使用するために漏洩させることはできず、シークレットとして保存されることもありません 1。

この方法の重要な利点は、公開されたパッケージに自動的に**来歴証明（provenance attestation）**が含まれることです 1。これにより、消費者はパッケージのソースリポジトリと使用された特定のビルドプロセスに関する暗号的な証明を得ることができ、サプライチェーンの透明性と信頼性が向上します 1。

ただし、現時点ではいくつかの制限と課題があります。当初はGitHub Actions（ホストランナーのみ）とGitLab CI/CD（共有ランナー）をサポートしています 22。他のプロバイダーやセルフホストランナーのサポートは計画されていますがまだ利用できず、これは多くの組織にとって大きな障壁となります 22。また、Trusted Publishingを設定するにはパッケージがnpm上に既に存在している必要があり、新しいパッケージにとっては「鶏が先か卵が先か」の問題を生じさせています。このため、設定を有効にするためだけにプレースホルダーパッケージを公開するコミュニティツールが登場しています 38。

GitHubのフレームワークは、攻撃者のライフサイクル全体に対抗するために戦略的に制御を階層化する、多層防御の優れた実践例です。このセキュリティモデルは、単一のもろいシークレット（クラシックトークン）に依存するのではなく、アイデンティティ、クレデンシャル、公開プロセスのすべてが独立して強化される多面的なシステムへと移行します。このアプローチは、どの単一の制御も失敗する可能性があるという前提に基づいています。第1層として、フィッシングによって開発者が標的にされた場合、FIDO/WebAuthnが最初の防衛線となり、初期のアカウント侵害を防ぎます。第2層として、攻撃者がトークンを盗むことに成功した場合でも、トークンの7日間の有効期限と粒度の細かいスコープが次の防衛線となります。損害は時間と範囲の両方で封じ込められます。そして最も堅牢な第3層として、Trusted PublishingがCI/CD環境から静的で盗難可能なトークンを完全に排除します。CI環境を侵害した攻撃者は、漏洩させるべき長命のシークレットを見つけることができません。この階層的なアプローチは、攻撃チェーンの複数のポイントでの失敗に耐えることができる回復力のあるシステムを構築する、成熟したセキュリティ体制を示しています。


セクション3：比較分析：広範なエコシステムにおけるnpmのセキュリティ体制


本セクションでは、npmの新しいセキュリティモデルを他の主要なパッケージリポジトリと比較し、その相対的な成熟度とサプライチェーンセキュリティにおける業界全体のトレンドに関する文脈を提供します。

セキュリティ機能

npm（強化後）

PyPI

Maven Central

RubyGems

必須2FA

はい、公開アクションに対して

はい、全ユーザー

いいえ（発行者検証に依存）

いいえ（推奨）

フィッシング耐性2FA

はい、FIDO/WebAuthnを推奨

はい、WebAuthnをサポート

該当なし

はい、WebAuthnをサポート

トークンスコープ

はい、Granular Token

はい、スコープ付きトークン

該当なし

はい、スコープ付きAPIキー

トークン有効期限

はい（発行権限は7日間）

はい、設定可能

該当なし

はい、設定可能

Trusted Publishing (OIDC)

はい

はい（業界の先駆者）

いいえ

はい

アーティファクト署名

いいえ（計画中）

はい、PGP（オプション）

はい、PGP（必須）

はい、暗号署名

来歴証明

はい（Trusted Publishing経由）

いいえ

いいえ

いいえ

ID/名前空間の検証

いいえ

いいえ

はい（groupIdのドメイン検証）

いいえ


3.1 PyPIからの教訓：現代の公開セキュリティの先駆者


PyPIは、2023年4月に主要なレジストリとして初めてTrusted Publishingを導入しました 3。その成功した展開と14,000以上のプロジェクトによる自発的な採用は、トークンレス公開が実行可能であり、メンテナーに望まれていることを示す、業界全体にとって重要な概念実証となりました 41。npmはここでPyPIの戦略に直接従っています。

また、PyPIは2024年1月1日に全ユーザーに対する必須2FAの展開を完了しました 43。これは2022年にクリティカルなプロジェクトから始まった複数年にわたる取り組みでした 44。このプロセスは、追加の負担を懸念する開発者からの初期の反発に直面しましたが 44、最終的にはエコシステムを保護するために必要なステップと見なされました 45。npmのアプローチは、PyPIの段階的な展開から学んでいるように見えます。


3.2 Maven Centralモデル：ガバナンスと信頼における対比


Maven Centralのセキュリティモデルは根本的に異なり、より厳格な事前検証に基づいています。公開するには、プロジェクトは通常、発行者が所有権を証明する必要があるドメイン名に紐づけられた一意のgroupId（例：org.springframework）を所有しなければなりません 48。これは強力で検証済みの名前空間として機能し、npmやPyPIで一般的なタイポスクワッティングやIDの混乱を防ぎます。

また、GPGによるアーティファクトの署名は、Centralに公開する多くのプロジェクトにとって長年のベストプラクティスであり、要件でもあります。これにより、消費者はアーティファクトが正当な所有者によって公開されてから改ざんされていないことを確認できます 49。さらに、一度リリースバージョンのアーティファクトがMaven Centralに公開されると、それは不変です。上書きしたり削除したりすることはできません 49。これにより、アカウントを侵害した攻撃者が人気のある既存のバージョンを悪意のあるものに置き換えることを防ぎます。

このゲートキーパー型の高摩擦モデルは強力な保証を提供しますが、JavaScriptエコシステムの特徴である公開の速度と容易さを犠牲にします。Mavenのセキュリティモデルは検証済みの発行者を信頼することを前提としていますが、npmの新しいモデルは、あらゆる発行者の行動を保護することに焦点を当てています 48。


3.3 npmの新たな軌道評価


GitHubの新しい措置は大きな前進であり、npmのセキュリティ体制をPyPIのような同業者と同等、そして一部の領域（TOTPよりもFIDOを義務付ける点など）ではそれを上回るものにしています。Trusted Publishingへの積極的な推進は、CI/CDセキュリティに関する業界全体の標準への収束を示しています 36。

しかし、Mavenと比較すると、npmには依然として、事前のID検証とアーティファクト署名のための堅牢で必須のメカニズムが欠けています。来歴証明はソースへのリンクを提供しますが、悪意のある者が適切に来歴証明された悪意のある新しいパッケージを公開することを防ぐものではありません。エコシステムが多数の小規模な単一メンテナーのパッケージに依存していることは、これらの新しい措置が軽減するものの、排除はできない構造的なリスクとして残っています 52。

パッケージレジストリのセキュリティの進化は、「発行者の保護」と「プロセスの保護」という2つの競合する哲学を明らかにしています。Maven Centralは前者、つまり厳格な事前のID審査に焦点を当てています。一方、PyPI、そして今やnpmは後者を支持しており、よりオープンな公開モデルを受け入れつつ、認証と自動化の経路を積極的に強化しています。業界は、高速度のオープンソースエコシステムにとってよりスケーラブルなモデルとして、「プロセスの保護」に収束しつつあります。Mavenのモデルは、より構造化された企業主導のオープンソースの時代に設計されましたが、npmやPyPIのようなエコシステムの爆発的な成長は、その低摩擦モデルによって促進されました。これらのエコシステムにMavenスタイルの審査プロセスを後付けすることは文化的に不可能であり、エコシステムを破壊するでしょう。したがって、現実的な解決策は、誰が公開できるかを変えるのではなく、どのように公開するかを劇的に保護することでした。フィッシング耐性のある2FAやOIDCベースのTrusted Publishingのような技術は、この哲学に完璧に適合します。これらは、中央機関がすべての発行者のIDを審査する必要はありませんが、プラットフォームが公開行為自体に強力で検証可能なセキュリティ慣行を強制することを可能にします。


セクション4：戦略的実装とセキュア開発のための推奨事項


本セクションでは、ここまでの分析を開発チームのための実行可能なガイダンスに変換し、移行のためのロードマップを提供し、高度な防御態勢の概要を示します。


4.1 開発者と組織のための段階的移行ガイド


GitHubの新しいセキュリティ要件への移行は、計画的かつ段階的に進めることが重要です。


即時対応（最初の48時間）


  1. クレデンシャルのローテーションと監査：CI/CDで使用されている長命のクラシックトークンを含む、既存のすべてのnpmトークンを直ちに失効させ、ローテーションします 8。npmjs.comの「Access Tokens」ページを監査し、未使用または過剰な権限を持つトークンを特定して削除します。

  2. フィッシング耐性2FAの有効化：公開権限を持つすべての開発者は、npmおよびGitHubアカウントで直ちに2FAを設定し、TOTPアプリよりもWebAuthn（ハードウェアキー、生体認証）を優先します 3。

  3. 公開アクセスのレビュー：各パッケージについて、Settings -> Publishing accessに移動し、「Require two-factor authentication...」を選択して、すべての協力者に2FAを強制します 54。


短期移行（次の30日間）：Trusted Publishingの採用


  1. 候補ワークフローの特定：現在サポートされているGitHub ActionsまたはGitLab CI経由で公開されている公開パッケージを優先します 22。

  2. 段階的設定（GitHub Actionsの例）：

  3. 新規プロジェクトの場合は、プレースホルダーパッケージを公開します 38。

  4. npmjs.comで、パッケージのアクセス設定に移動し、「Trusted Publisher」を追加して、GitHubのユーザー/組織、リポジトリ、ワークフローファイル名（例：release.yml）を指定します 22。

  5. GitHub Actionsのワークフローファイルから、NPM_TOKENシークレットを使用するステップを削除します。

  6. ジョブにpermissionsブロックを追加します：permissions: id-token: write 22。

  7. npm publishコマンドが十分に新しいバージョンのnpm（>= 11.5.1）で実行されることを確認します 35。

  8. 公開のロックダウン：Trusted Publishingが機能することを確認したら、パッケージの設定に戻り、「Require two-factor authentication and disallow tokens」を選択します 22。これにより、OIDCが自動公開の


    唯一の方法となり、最大限のセキュリティが提供されます。


エッジケースと制限への対応


  • セルフホストランナー：セルフホストランナーを使用するワークフローでは、Trusted Publishingはまだ利用できません 22。ベストプラクティスは、可能な限り狭いパッケージスコープと、CIシステムの最も安全なシークレット管理機能に保存された、自動ローテーションされる短い有効期限を持つ粒度の細かいアクセストークンを使用することです。

  • プライベートパッケージのインストール：Trusted Publishingはnpm publishのみを対象とします。CIワークフロー内でプライベートパッケージをnpm installするには、別途読み取り専用の粒度の細かいアクセストークンが依然として必要です 22。

フェーズ

タスク

責任者

ステータス

メモ/参照

即時

すべてのクラシックnpmトークンを監査し、失効させる

組織管理者、メンテナー

☐ 未着手

CI/CDパイプラインと開発者環境をチェック

即時

すべての発行者にWebAuthn 2FAを強制する

組織管理者、メンテナー

☐ 未着手

TOTPよりもWebAuthnを優先する

短期

my-packageのrelease.ymlワークフローをTrusted Publishingに移行する

メンテナー

☐ 未着手

OIDC設定とワークフローの更新が必要

短期

Trusted Publishing移行後、パッケージ設定で「トークンを不許可」に設定する

メンテナー

☐ 未着手

最大限のセキュリティを確保するための最終ステップ

長期

新規プロジェクトでnpmからpnpmへの移行を評価する

開発チーム

☐ 未着手

post-installスクリプトのリスクを軽減

長期

CIパイプラインにビルド環境のサンドボックス化を導入する

DevOps/SREチーム

☐ 未着手

bubblewrapなどのツールを検討


4.2 GitHubの義務化を超える高度な防御戦略


GitHubが導入した新しいセキュリティベースラインは強力ですが、さらに堅牢なサプライチェーンセキュリティ体制を構築するためには、組織レベルでの追加的な防御策を講じることが推奨されます。


pnpmによるコード実行の制御


悪意のあるpost-installスクリプトの脅威を無力化する最も効果的な方法の一つは、デフォルトでそれらを実行しないパッケージマネージャーを使用することです。pnpmは「デフォルトで拒否」の原則に基づいて動作し、すべてのpost-installスクリプトをスキップし、開発者が必要不可欠なものだけを明示的にホワイトリストに登録することを強制します 55。この変更だけで、Shai-Huludワームや他の多くのnpmマルウェアキャンペーンの主要な感染ベクトルを無効化できます。


ビルド環境のサンドボックス化


さらに強力な防御として、開発およびCI環境をサンドボックス化することが挙げられます。Linuxのbubblewrapのようなツールは、npm installやpnpm installが実行されるための隔離された環境を作成し、ネットワーク、ホームディレクトリ（SSH/AWSキーを含む）、その他の機密性の高いファイルシステムへのアクセスを拒否します。これにより、悪意のあるスクリプトが実行されたとしても、それを封じ込め、機密情報の窃取やデータ漏洩を防ぐことができます 55。


「依存関係のクールダウン」期間の導入


ゼロデイの悪意のある公開から防御するために、組織は依存関係の最新バージョンを即座に採用しないポリシーを導入することができます。内部プロキシリポジトリやRenovateのminimumReleaseAge設定などのツールを通じて、遅延（例：7〜14日間）を強制することで、チームは広範なコミュニティやセキュリティ研究者が悪意のあるパッケージを発見し報告するための時間を確保し、それが自社のビルドプロセスに入る前に対応できます 14。

効果的なサプライチェーンセキュリティは、単一のツールやポリシーではなく、オープンソースエコシステムへの「暗黙の信頼」モデルから「明示的な検証と封じ込め」モデルへの文化的な転換です。GitHubの変更はこの転換の強力な触媒ですが、最終的な回復力は、組織が階層的な防御策をどれだけ採用するかにかかっています。従来の開発ワークフローはnpmレジストリとパッケージを暗黙的に信頼していましたが、最近の攻撃はこの信頼を打ち砕きました。GitHubの新しいルールは、FIDOが人物を、Trusted Publishingがプロセスを、来歴証明が起源を検証するという、明示的な検証への移行を強制します。しかし、これらのプラットフォームレベルの制御には限界があり、悪意があるが正しく公開されたパッケージを止めることはできません。したがって、最も成熟した組織は、pnpm（スクリプト実行の封じ込め）やサンドボックス化（ファイルシステム/ネットワークアクセスの封じ込め）の背後にある「侵害を前提とする」という考え方、つまり封じ込めへと次のステップに進む必要があります。


4.3 サプライチェーンセキュリティの未来への備え


Shai-Huludワームは、攻撃者が単純なクレデンシャル窃取から、自律的で自己増殖する脅威の作成へと、より洗練されていることを示しています 57。将来の攻撃は、より高度な難読化 1、ビルドツールやCI設定へのより直接的な標的化、そしてAIを利用した説得力のあるフィッシングの誘引や悪意のあるコードのバリエーション生成などを組み込む可能性が高いでしょう。

業界全体のTrusted Publishingと来歴証明への推進は第一歩です。次のフロンティアは、ビルドプロセスのより堅牢なランタイム監視、検証可能で再現可能なビルド、そしてコンプライアンスの成果物としてだけでなく、脅威の監視と対応のためのアクティブなセキュリティツールとしてのソフトウェア部品表（SBOM）の採用となるでしょう 59。


結論


GitHubによる包括的なセキュリティ強化は、単なる漸進的な改善ではなく、サプライチェーン攻撃の高度化に対する必要不可欠かつ決定的な対応です。これらは、npmエコシステムの基盤を根本的に強化するものです。

GitHubはプラットフォームのセキュリティベースラインを引き上げていますが、共同責任の原則は依然として最重要です。ソフトウェアサプライチェーンの最終的なセキュリティは、メンテナーと組織がこれらの新しいツールを積極的に採用し、セキュリティを意識した慣行を日々のワークフローに統合することにかかっています。

この移行には努力が必要ですが、2025年9月の攻撃が示したような混乱とコストのかかる修復作業という、何もしないことの代償ははるかに大きいものです 2。FIDOベースの2FA、粒度の細かいトークン、そして特にTrusted Publishingの積極的な採用は、今やJavaScriptエコシステムにおけるプロフェッショナルなソフトウェア開発の不可欠な側面となっています。



引用文献


  1. GitHub Mandates 2FA and Short-Lived Tokens to Strengthen npm ..., 9月 26, 2025にアクセス、 https://thehackernews.com/2025/09/github-mandates-2fa-and-short-lived.html

  2. GitHub tightens npm security with mandatory 2FA, access tokens, 9月 26, 2025にアクセス、 https://www.bleepingcomputer.com/news/security/github-tightens-npm-security-with-mandatory-2fa-access-tokens/

  3. GitHub Introduces npm Security with Stronger Authentication and Trusted Publishing, 9月 26, 2025にアクセス、 https://gbhackers.com/github-introduces-npm-security-with-stronger-authentication/

  4. GitHub Enhances npm Security with Mandatory 2FA and Access Tokens - SSOJet, 9月 26, 2025にアクセス、 https://ssojet.com/news/github-enhances-npm-security-with-mandatory-2fa-and-access-tokens

  5. Our plan for a more secure npm supply chain - The GitHub Blog, 9月 26, 2025にアクセス、 https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/

  6. GitHub is finally tightening up security around npm following multiple attacks - TechRadar, 9月 26, 2025にアクセス、 https://www.techradar.com/pro/security/github-is-finally-tightening-up-security-around-npm-following-multiple-attacks

  7. GitHub Boosting Security in Response to NPM Supply Chain Attacks ..., 9月 26, 2025にアクセス、 https://www.securityweek.com/github-boosting-security-in-response-to-npm-supply-chain-attacks/

  8. What We Know About the NPM Supply Chain Attack | Trend Micro (US), 9月 26, 2025にアクセス、 https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html

  9. Largest npm Supply-Chain Attack to Date Targets Billions of Downloads - Sweet Security, 9月 26, 2025にアクセス、 https://www.sweet.security/blog/largest-npm-supply-chain-attack-to-date-targets-billions-of-downloads

  10. Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk - Palo Alto Networks Blog, 9月 26, 2025にアクセス、 https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/

  11. 19 npm Packages Compromised in Major Supply-Chain Attack | OX Security, 9月 26, 2025にアクセス、 https://www.ox.security/blog/npm-packages-compromised/

  12. Shai-Hulud npm Supply Chain Attack | Wiz Blog, 9月 26, 2025にアクセス、 https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack

  13. Widespread Supply Chain Compromise Impacting npm Ecosystem - CISA, 9月 26, 2025にアクセス、 https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

  14. Security Advisory | NPM Packages Using Secret Scanning Tools to Steal Credentials, 9月 26, 2025にアクセス、 https://semgrep.dev/blog/2025/security-advisory-npm-packages-using-secret-scanning-tools-to-steal-credentials/

  15. 500+ npm Packages Compromised in Ongoing Supply Chain Attack 'Shai-Hulud' - Truesec, 9月 26, 2025にアクセス、 https://www.truesec.com/hub/blog/500-npm-packages-compromised-in-ongoing-supply-chain-attack-shai-hulud

  16. 180+ NPM Packages Hit in Major Supply Chain Attack - OX Security, 9月 26, 2025にアクセス、 https://www.ox.security/blog/npm-2-0-hack-40-npm-packages-hit-in-major-supply-chain-attack/

  17. GitHub Boosting Security in Response to NPM Supply Chain Attacks - SecurityWeek, 9月 26, 2025にアクセス、 https://www.securityweek.com/github-boosting-security-in-response-to-npm-supply-chain-attacks/amp/

  18. When Dependencies Turn Dangerous: Responding to the NPM Supply Chain Attack, 9月 26, 2025にアクセス、 https://blog.qualys.com/vulnerabilities-threat-research/2025/09/10/when-dependencies-turn-dangerous-responding-to-the-npm-supply-chain-attack

  19. Major NPM Supply-Chain Attack: Potential Impact on Mobile Applications - NowSecure, 9月 26, 2025にアクセス、 https://www.nowsecure.com/blog/2025/09/08/major-npm-supply-chain-attack-potential-impact-on-mobile-applications/

  20. npm Chalk and Debug Packages Hit in Software Supply Chain Attack - Sonatype, 9月 26, 2025にアクセス、 https://www.sonatype.com/blog/npm-chalk-and-debug-packages-hit-in-software-supply-chain-attack

  21. Wormable Malware Triggers GitHub's Push for Stronger npm Security | eSecurity Planet, 9月 26, 2025にアクセス、 https://www.esecurityplanet.com/news/wormable-malware-triggers-githubs-push-for-stronger-npm-security/

  22. Trusted publishing for npm packages, 9月 26, 2025にアクセス、 https://docs.npmjs.com/trusted-publishers/

  23. New npm features for secure publishing and safe consumption - The GitHub Blog, 9月 26, 2025にアクセス、 https://github.blog/news-insights/product-news/new-npm-features-for-secure-publishing-and-safe-consumption/

  24. GitHub Tightens Npm Security with Mandatory 2fa - ITdaily., 9月 26, 2025にアクセス、 https://itdaily.com/news/software/github-npm-2fa/

  25. a second attack has hit npm, over 40 packages compromised. : r/javascript - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/javascript/comments/1nifp98/a_second_attack_has_hit_npm_over_40_packages/

  26. Largest NPM Compromise in History - Supply Chain Attack : r/cybersecurity - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/cybersecurity/comments/1nbqs7c/largest_npm_compromise_in_history_supply_chain/

  27. Top-100 npm package maintainers now require 2FA, and additional security-focused improvements to npm - The GitHub Blog, 9月 26, 2025にアクセス、 https://github.blog/security/supply-chain-security/top-100-npm-package-maintainers-require-2fa-additional-security/

  28. npm is making 2FA mandatory for accounts with high impact packages : r/node - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/node/comments/xftu7i/npm_is_making_2fa_mandatory_for_accounts_with/

  29. npm: Enforcing 2FA for high-impact projects · Issue #464 · github/roadmap, 9月 26, 2025にアクセス、 https://github.com/github/roadmap/issues/464

  30. After Shai-Hulud, GitHub tightens npm publishing security, 9月 26, 2025にアクセス、 https://www.helpnetsecurity.com/2025/09/23/npm-publishing-security-improvements/

  31. About access tokens - npm Docs, 9月 26, 2025にアクセス、 https://docs.npmjs.com/about-access-tokens/

  32. General availability of granular access token on npm - GitHub Changelog, 9月 26, 2025にアクセス、 https://github.blog/changelog/2023-03-20-general-availability-of-granular-access-token-on-npm/

  33. Trusted Publishers for All Package Repositories - wg-securing-software-repos, 9月 26, 2025にアクセス、 https://repos.openssf.org/trusted-publishers-for-all-package-repositories.html

  34. Trusted publishing: a new benchmark for packaging security - The Trail of Bits Blog, 9月 26, 2025にアクセス、 https://blog.trailofbits.com/2023/05/23/trusted-publishing-a-new-benchmark-for-packaging-security/

  35. npm trusted publishing with OIDC is generally available - GitHub Changelog, 9月 26, 2025にアクセス、 https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/

  36. npm Adopts OIDC for Trusted Publishing in CI/CD Workflows - ... - Socket.dev, 9月 26, 2025にアクセス、 https://socket.dev/blog/npm-trusted-publishing

  37. GitHub to remove weak security options for npm registry - The Register, 9月 26, 2025にアクセス、 https://www.theregister.com/2025/09/23/github_npm_registry_security/

  38. Setup npm package for trusted publishing with OIDC - GitHub, 9月 26, 2025にアクセス、 https://github.com/azu/setup-npm-trusted-publish

  39. GitHub Boosts npm Security with Stronger Authentication and Trusted Publishing, 9月 26, 2025にアクセス、 https://cyberpress.org/github-boosts-npm-security/

  40. Introducing 'Trusted Publishers' - The Python Package Index Blog, 9月 26, 2025にアクセス、 https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

  41. Adoption of Trusted Publishers Growing Among Open Source Package Repositories, 9月 26, 2025にアクセス、 https://socket.dev/blog/adoption-of-trusted-publishers-growing-among-open-source-package-repositories

  42. New Guide for Package Repositories to Adopt Trusted Publishers - Open Source Security Foundation, 9月 26, 2025にアクセス、 https://openssf.org/blog/2024/08/05/new-guide-for-package-repositories-to-adopt-trusted-publishers/

  43. 2FA Required for PyPI - The Python Package Index Blog, 9月 26, 2025にアクセス、 https://blog.pypi.org/posts/2024-01-01-2fa-enforced/

  44. PyPI mandates 2FA for critical projects, developer pushes back - Bleeping Computer, 9月 26, 2025にアクセス、 https://www.bleepingcomputer.com/news/security/pypi-mandates-2fa-for-critical-projects-developer-pushes-back/

  45. PyPI to mandate 2FA by the end of 2023 - Cybersecurity Dive, 9月 26, 2025にアクセス、 https://www.cybersecuritydive.com/news/pypi-mandate-2fa-authentication/651520/

  46. PyPI Implements Mandatory 2FA for Enhanced Security in Software Publishing, 9月 26, 2025にアクセス、 https://blog.excellimatrix.com/post/pypi-implements-mandatory-2fa-for-enhanced-security-in-software-publishing

  47. After malicious uploads, PyPi requires multi-factor authentication - IT Brew, 9月 26, 2025にアクセス、 https://www.itbrew.com/stories/2023/06/29/after-malicious-uploads-pypi-makes-multi-factor-a-must

  48. Attacks on Maven proxy repositories - The GitHub Blog, 9月 26, 2025にアクセス、 https://github.blog/security/vulnerability-research/attacks-on-maven-proxy-repositories/

  49. Why or how is Maven more secure/reliable than NPM? : r/java - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/java/comments/qdq2qh/why_or_how_is_maven_more_securereliable_than_npm/

  50. Introducing MavenGate: a supply chain attack method for Java and Android applications, 9月 26, 2025にアクセス、 https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications/

  51. Maven Security, 9月 26, 2025にアクセス、 https://maven.apache.org/security.html

  52. npm got owned because one dev clicked the wrong link. billions of downloads poisoned. supply chain security is still held together with duct tape. : r/sysadmin - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/sysadmin/comments/1ncf87f/npm_got_owned_because_one_dev_clicked_the_wrong/

  53. [AskJS] what makes NPM less secure than other package providers? : r/javascript - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/javascript/comments/1nkw6gr/askjs_what_makes_npm_less_secure_than_other/

  54. Requiring 2FA for package publishing and settings modification - npm Docs, 9月 26, 2025にアクセス、 https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification/

  55. How to Prevent NPM Supply Chain Attacks Now | by Tahir | Sep, 2025 - Medium, 9月 26, 2025にアクセス、 https://medium.com/@tahirbalarabe2/how-to-prevent-npm-supply-chain-attacks-now-bbdb539a7729

  56. NPM packages .. How are you securing against dodgy packages and compromised developer accounts ? : r/cybersecurity - Reddit, 9月 26, 2025にアクセス、 https://www.reddit.com/r/cybersecurity/comments/1nk4rpc/npm_packages_how_are_you_securing_against_dodgy/

  57. Ongoing npm Software Supply Chain Attack Exposes New Risks - Sonatype, 9月 26, 2025にアクセス、 https://www.sonatype.com/blog/ongoing-npm-software-supply-chain-attack-exposes-new-risks

  58. PYPI Security: How to Prevent Supply Chain Attacks in Python Projects - Bolster AI, 9月 26, 2025にアクセス、 https://bolster.ai/blog/pypi-supply-chain-attacks

  59. GitHub security features, 9月 26, 2025にアクセス、 https://docs.github.com/en/code-security/getting-started/github-security-features

  60. safety - PyPI, 9月 26, 2025にアクセス、 https://pypi.org/project/safety/



All Tags

bottom of page