# GitHub、悪意あるインストールを防ぐ「Package Firewall」公開…GHEC限定

> GitHubがCIランナーやコーディングエージェントによる不正パッケージのインストールを遮断するPackage Firewallのプレビューを開始した。GHEC向けで、現在はnpmのみに対応する。

- URL: https://roobrief.com/ja/posts/github-package-firewall
- Language: ja
- Published: 2026-10-22T01:00:00.000Z
- Tags: dev
- Source: https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/

**GitHubがCIランナーやコーディングエージェントによる悪意あるコードのダウンロードを阻止する「Package Firewall」のパブリックプレビューを開始したが、GitHub Enterprise Cloud限定で現在はnpmのみに対応する。**

GitHubは2026年10月20日付の公式ブログで、サプライチェーンセキュリティ機能「Package Firewall」のパブリックプレビュー（公開試用版）を開始したと発表した。この機能は、開発者のPCやCI（継続的インテグレーション）ランナー、コーディングエージェントが依存パッケージをインストールする際に悪意あるスクリプトが実行される攻撃を防ぐインライン検査レイヤーだ。データレジデンシー（特定地域でのデータ保管）オプションを利用する組織を含む、GitHub Enterprise Cloud（GHEC）の全顧客に提供される。

## 誰が使えて料金はどうなるか

Package Firewallは、すべてのGitHubユーザーが使えるわけではない。対象はエンタープライズ向けのGHECに限られ、個人アカウント（FreeやPro）やGitHub Teamプランは対象外だ。

| プラン | Package Firewall対応 | プレビュー料金 | 正式提供（GA）時の料金 | 対応エコシステム |
|---|---|---|---|---|
| GitHub Free / Team | 未対応 | 対象外 | 対象外 | 対象外 |
| GitHub Enterprise Cloud（GHEC） | 対応（データレジデンシー含む） | 無料 | 従量課金制（予定） | npm（単一対応） |

現在公開されているパブリックプレビュー期間中は、追加料金なしで利用できる。GitHubはインフラを強化し機能を追加したうえで、正式提供（GA）の段階でGitHub Actionsのように使用量に応じた従量課金制へ移行する方針を示している。ただし、正式提供の時期や具体的な課金単価は公表されていない。

## 何を検査し何が制限されるか

これまでのパッケージセキュリティは、リポジトリにコミットされたコードを後からスキャンしたり脆弱性通知を送ったりする手法が中心だった。しかし最近の攻撃者は、パッケージのインストール時（`preinstall`スクリプトなど）に環境変数やAPIキーを盗み出す手口を頻繁に用いる。特にコーディングエージェントやCIランナーは、人間の確認を待たずに自律的にパッケージをインストールして処理を完了しようとするため、こうしたインストール時の攻撃に狙われやすい。

Package Firewallは、エンドポイントと公式レジストリ（`registry.npmjs.org`）の間に配置され、パッケージ一覧のメタデータと実際にダウンロードされるアーカイブファイル（tarball）の両方をリアルタイムで検査する。管理者が設定できる中核ポリシーは以下の4点だ。

1. **既知のマルウェア遮断**：GitHub Advisory Database（脆弱性情報データベース）に登録された悪意あるパッケージを即座にブロックする。
2. **脆弱性アラートに基づく遮断**：報告されている脆弱性の深刻度（CriticalやHigh以上など）に応じて、危険なバージョンのダウンロードを制限する。
3. **アテステーションのダウングレード遮断**：以前のバージョンにはビルド出所の真正性を証明する暗号署名（アテステーション）が存在したのに、新たに要求されたバージョンで署名が消えている場合、改ざんのリスクがあると判定して遮断する。
4. **新規バージョンのクールダウン**：公開されたばかりのパッケージバージョンを一定時間インストール不可に設定し、オープンソースコミュニティが検証や報告を行うための猶予期間を設ける。

現在の最大の制限は、**npmパッケージのみに対応している点**だ。PythonのPyPIやJavaのMaven、RustのCargoといった他の言語エコシステムは保護の対象外となっている。

## 導入手順と例外申請の注意点

Package Firewallを有効にするには、管理者がポリシー設定画面で機能を有効化した後、開発端末やCIランナーのパッケージマネージャー設定（`.npmrc`）でレジストリの接続先をファイアウォールのURLに切り替える。

正常な社内パッケージや緊急リリースされたライブラリがクールダウンなどのポリシーで誤って遮断（誤検知）された場合は、ターミナル出力やCIログに専用の例外申請URLが表示される。開発者がそのリンクから理由を添えて申請すると、GitHub Advanced Security（GHAS）に似た承認フローを通じて管理者が個別許可を出せる仕組みだ。

ただし、複数の自律エージェントがバックグラウンドで並行稼働している環境では、誤検知が発生した際に人間が確認して承認するまでパイプライン全体が停止する恐れがある。クールダウン期間を長く設定しすぎると日常的なライブラリ更新作業が滞るため、導入初期は待機時間を短めに設定し、例外承認を担当するメンバーをあらかじめ決めておく運用が推奨される。

## 今後の注目点

GitHubはフィードバックを受けながらインフラを拡大し、対応機能を順次広げていくと説明している。PyPIをはじめとする他の言語レジストリへいつ対応が広がるか、そして正式提供時に適用される従量課金が大規模なCI環境の運用コストにどの程度影響するかが今後の焦点となる。

## 出典

- [GitHub package firewall in public preview](https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/) (The GitHub Blog)
- [Protecting endpoints with package firewall](https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/protecting-endpoints-with-package-firewall) (GitHub Docs)