Ing. Calogero Bono
GitHubは2026年10月20日、パッケージファイアウォール（package firewall）を発表しました。これは、パッケージをインストールするコンピューターと、それらを配布する公開レジストリとの間に置かれるフィルターです。現在はGitHub Enterprise Cloudの全顧客向けに公開プレビューとして提供されており、対応しているのはnpmだけです。目的は、インストールの瞬間に感染するマルウェアを止めることです。人の目が届かないままAIエージェントやビルドシステムが依存関係を取り込んでいくため、このリスクは特に高まっています。ソフトウェア開発に関わる人や、その管理をしている人にとって、サプライチェーンのセキュリティがどこへ向かっているかを示すサインです。
その前に、用語を確認しておきましょう。レジストリ（registry）は、パッケージをダウンロードするためのオンラインの保管場所で、JavaScriptならnpmがそれにあたります。依存関係は、プロジェクトが利用する他者のコードの一部です。CI/CDは、ソフトウェアのビルドや公開を自動で行う手順です。SLSA attestationは、パッケージがどのように、誰によってビルドされたかを検証できる形で示した宣言です。メタデータは、パッケージに関する情報で、たとえば利用可能なバージョンの一覧などを指します。
GitHubのパッケージファイアウォールとは何ですか？
GitHubの公式チェンジログによると、近年、パッケージのインストール時を狙うマルウェア攻撃が本格的な波となっています。エージェントやCIのランナーは、人を介さずに依存関係をインストールしてタスクやビルドを実行するため、特に狙われやすい対象です。
ファイアウォールは、エンドポイントや社内レジストリと、上流のパッケージリポジトリの間に配置されます。The Hacker Newsの報道によると、GitHubは次のように説明しています。「The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate」。つまり、メタデータのリクエストとパッケージのダウンロードの両方を検査し、インストール時に適用されるポリシーのゲートとして機能するという意味です。
この問題は理論上の話ではありません。The Registerは、攻撃者がGitHubのissueを悪用し、1時間足らずで公開リポジトリ61件を標的にしたサプライチェーン攻撃キャンペーンを報じました。入手できたページには他の詳細がないため、二つのニュースが関連しているかどうかは判断できません。
仕組みと提供される制御機能は？
流れは二段階です。まず管理者がenterpriseのルールを設定します。次に、コーディングエージェントやCI/CDホストは、公開レジストリに直接接続する代わりにファイアウォールを参照します。メタデータのリクエストもダウンロードも、すべてファイアウォールを通り、ポリシーに基づいて評価されます。
提供される制御機能
The Hacker Newsの一覧によると、以下の制御機能があります。
- 既知のマルウェアのブロック。GitHub Advisory Databaseのアクティブな警告を照合します。
- 脆弱性の深刻度によるブロック。同じくデータベースを利用します。初期設定では「Critical only」のみをブロックしますが、「High or higher」「Medium or higher」「Any severity」を選択できます。
- アテステーションのダウングレードのブロック。要求されたバージョンのアテステーションを以前のバージョンと比較し、SLSAアテステーションが欠けている場合はダウンロードを止めます。
- 新しいインストールスクリプトのブロック。preinstallやpostinstallのフックで実行され、機密データの窃取に使われうるスクリプトが対象です。
- クールダウン（待機期間）。設定した最低経過日数より新しいバージョンのインストールを防ぎます。
クールダウンは1日から365日まで設定でき、初期値は1日です。0に設定すると無効になります。
誤って正常なパッケージがブロックされた場合は？
正常なパッケージが誤ってブロックされた場合、利用者は例外を申請できます。GitHubでは、GitHub Advanced Securityの他の機能と似た流れになります。The Hacker Newsによると、申請はenterpriseの管理者およびセキュリティ責任者が承認できるとのことです。
料金と利用対象は？
本サービスは、GitHub Enterprise Cloudの全顧客に公開プレビューとして提供されており、データレジデンシー版も含まれます。プレビュー期間中は無料です。一般提供が始まると、GitHubは使用量に応じた従量課金になると発表しています。Actionsの課金方式と似ているとのことです。
GitHubによると、プレビューの目的はインフラを拡充し、顧客の要望に応じて機能を追加することです。設定方法は「Protecting endpoints with package firewall」のドキュメントを参照するよう案内されています。
なぜ待機期間が話題になっているのか？
クールダウンは最もシンプルで、おそらく最も普及している対策です。The Hacker Newsによると、この1年でnpm、Python、Visual Studio Code、Ruby、Bun、pnpm、Yarnなどで同様の待機期間が導入されました。考え方は、公開されたばかりでまだ誰も確認していないバージョンが、すぐにビルドに入り込むリスクを減らすことです。
特に効果があるのは、メンテナーのアカウントを乗っ取って、人気パッケージに有害なバージョンを公開する攻撃です。待機期間があると、手動でも自動でも、被害が急速に広がるのを抑えられます。
同じ記事によると、2026年11月12日リリース予定のRust 1.100では、crateに対して設定可能な最低公開経過時間が追加される見込みです。オプション名は「global-min-publish-age」で、cargo/config.tomlに記述します。指定がない場合は、初期値として7日間の待機が適用されます。
一方、The Hacker Newsが引用したSocketは欠点も指摘しています。「The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception」。代償として、正当な修正も、開発者が例外を設けない限り待たされることになります。さらに、ファイアウォールの検査をすり抜けたリリースは、待機期間の間に単に生き延びるだけかもしれないとも述べています。Socketによれば、この仕組みの価値は、研究者、メンテナー、レジストリが対応する時間を与える点にあります。
知っておくべき制限
- 現在、ファイアウォールが対応しているのはnpmだけです。PHP、Python、その他のエコシステムは対象外で、情報源には他のレジストリの予定日も記されていません。
- 利用できるのはGitHub Enterprise Cloudの顧客だけです。小規模なプランについては情報源に記載がありません。
- 現在はプレビュー段階です。機能、インフラ、料金は変わる可能性があり、従量課金の金額もまだ明らかではありません。
- 独立したデータによる有効性の検証はありません。情報源はGitHubの発表を伝えているにすぎず、実際のマルウェアを使った検証は示されていません。また、誤検知の数値についても触れられていません。
- Socketも指摘するように、クールダウンは悪意あるコードを無害にするわけではありません。検出されなかったバージョンは、待機期間を過ぎても潜んだままになる可能性があります。
デジタル分野で働く人にとっての変化
実務上の重要な点は、セキュリティの重点が事後の検査から、インストール前の検査へ移りつつあることです。自ら書いてインストールまでこなすAIエージェントを使う場合、個々のエージェントを信頼するのではなく、中央の一つのルールで管理できることを意味します。AIを活用した開発ツールを使っているなら、中小企業（PMI）向けのバイブコーディングに関する記事で説明したリスクを読み直しておくと役立ちます。
イタリアの企業にとって、このテーマはコンプライアンスにも関わります。ソフトウェアのサプライチェーンは、NIS2のサプライヤー登録簿のガイドで扱っている内容の一部でもあります。パッケージが明文化されたルールを持つフィルターを通ったと証明できることは、具体的な論点になりますが、このファイアウォールとNIS2を結びつける情報源は存在しません。
オープンソースを多用する人は、各依存関係がサプライヤーであることを忘れないようにしましょう。詳しくは企業におけるオープンソースの解説で扱っています。Enterprise顧客でなくても、一部のパッケージマネージャーが提供する待機期間などの既存の機能で、同じ考え方を取り入れることができます。
ビルドサーバーや本番環境では、アップデートと隔離も重要です。他社に管理を任せたインフラをお探しなら、ホスティングおよびマネージドサーバーのサービスがあります。オーダーメイドのプロジェクトを検討しているなら、受注ソフトウェア開発のページをご覧ください。
私たちの見解
考え方は正しいと思います。パッケージがコンピューター上で動く前に止めることは、後から気づくよりも効果的であり、単一のポイントで行えば、各開発者やエージェントの注意深さに頼らずに済みます。GitHubが、監視されていないエージェントという問題からスタートしている点も、問題を率直に捉えていると感じます。
懸念は二つあります。一つ目は商業面です。これほど有用な保護が、当面はEnterprise層に限られ、プレビュー後は従量課金になる見込みです。最も狙われやすい小規模チームが取り残されるおそれがあります。二つ目は技術面です。多くの制御機能はGitHubのデータベースと時間経過に依存していますが、Socketも認めているように、時間は保証にはなりません。
そのため、これを決定的な盾とは考えていません。依存関係のレビュー、バージョンの固定、エージェントへの最小権限の付与と組み合わせてこそ役立つ、補助的な一層です。ファイアウォールを有効にすれば十分だと考えているなら、それは誤った安心感です。
よくある質問
GitHubのパッケージファイアウォールは無料ですか？
はい、ただしプレビュー期間中に限ります。GitHubは、一般提供後は使用量に応じて課金すると発表しており、Actionsに似た仕組みとなる見込みです。料金はまだ示されていません。
npmだけに対応していますか？
はい、現時点ではnpmパッケージのみに対応しています。他のエコシステムの対応予定は、情報源には示されていません。他の言語を使っている場合は、当面は別の対策を探す必要があります。
誰が利用できますか？
GitHub Enterprise Cloudの全顧客が利用でき、データレジデンシー版も含まれます。情報源には他のプランは記載されていません。管理者がenterprise全体のルールを設定します。
正当なパッケージがブロックされたらどうなりますか？
利用者は例外を申請できます。The Hacker Newsによると、申請は管理者やセキュリティ責任者が承認できます。GitHubによれば、流れはAdvanced Securityの他の機能に似ているとのことです。
待機期間だけでマルウェアを防げますか？
いいえ。公開直後のバージョンに対して時間を稼ぐ効果はありますが、Socketは、悪意あるコードは時間が経っても無害にならないと指摘しています。検出されなかったリリースは、待機期間を越えてしまう可能性があります。
一般提供までに注目すべき点
今後数か月は、三つの点に注目しましょう。GitHubが決める従量料金、npm以外への対応拡大、そしてRust 1.100で予定されている最低待機期間の導入です。当面は次のような準備ができます。
- CIやエージェントが使う依存関係を洗い出し、誰が監視なしで何をインストールできるかを決めます。
- 新しいバージョンに対する待機期間の導入を検討します。正当な修正も遅れる点を理解したうえで判断しましょう。
- 例外申請の手順を用意します。責任者が迅速に承認できる一方で、記録は必ず残す体制にします。
