GitHub package firewallとは?npmの悪いパッケージを入れる前に止める仕組みと、使える人・料金・設定方法(パブリックプレビュー)

GitHub package firewallで、npmの悪いパッケージを止める仕組みを示す図。パブリックプレビューとして公開。インストール時に止める(企業ごとに決めたポリシーに照らして調べる)、使える人を確かめる(GitHub Enterprise Cloudの契約者。今はnpmだけ)、管理者がポリシーを決める(npmがファイアウォールを通るようにする)の3つ

GitHubは2026年10月20日、npmパッケージのインストール時に悪いパッケージを止める「GitHub package firewall」をパブリックプレビューとして公開しました。使えるのはGitHub Enterprise Cloud(データレジデンシー版を含む)を契約したエンタープライズで、エンタープライズに入っていない個人のアカウント(個人の無料プランだけで使っている場合など)では使えません。

GitHub ActionsのランナーやAIのコーディングエージェントでnpmを使うチームは、Enterprise Cloudを契約していれば、インストール時に危ないパッケージを止めるポリシーを企業単位でかけられます。プレビュー期間中は無料で、正式提供後は使った量に応じた課金になります。

目次

GitHub package firewallでできること

GitHubによると、パッケージをインストールする時点で仕掛けるマルウェア攻撃が増えています。CI/CDのホストや開発者のPCで、パッケージのコードを実行しなくても認証情報を集められてしまう例があるとしています。

package firewallは、Actionsのランナーやコーディングエージェントなどのエンドポイントとnpmなどのパッケージレジストリーのあいだに入ります。パッケージ一覧を取得するメタデータの問い合わせと、パッケージ本体のダウンロードの両方が、ファイアウォールを通るようになります。ファイアウォールは企業ごとに決めたポリシーに照らして調べ、条件に合わないダウンロードを止めます。

GitHub Docsでは、守る対象としてCIのビルド、AIエージェントのセッション、ローカルでの開発の3つを挙げています。

使える人・料金・対応しているパッケージ

  • 使える人:GitHub Enterprise Cloud(データレジデンシー版を含む)を契約したエンタープライズ。ポリシーはエンタープライズ アカウント単位で決め、ファイアウォールに送るトークンも、エンタープライズのメンバーであるユーザーかボットのものが必要です。エンタープライズ アカウントは、GitHub Enterprise Cloudで作れるアカウントです。
  • 提供の段階:パブリックプレビュー。機能は今後変わる可能性があります。
  • 料金:プレビュー期間中は無料です。正式提供になったあとは、Actionsの課金と同じように使った量に応じた課金になります。
  • 対応しているパッケージ:今はnpmだけです。

止められるもの(ポリシーの項目)

ポリシーは企業(Enterprise)単位で決め、ファイアウォールを通るすべてのリクエストに適用されます。GitHub Docsにある項目は次の5つです。

項目名 内容 初期値
Block known malware GitHub Advisory Databaseにマルウェアの勧告が出ているパッケージを止める オン
Block vulnerability advisories 指定した深刻度以上の脆弱性があるバージョンを止める。Critical only、High or higher、Medium or higher、Any severityから選ぶ Critical only
Block attestation downgrades 以前のバージョンにはSLSAの証明(attestation)があったのに、求めたバージョンにはない場合に止める オン
Block newly-introduced install scripts preinstallやpostinstallなど、インストール時に動くスクリプトを最近追加したパッケージを止める オン
Minimum package age 公開されてから決めた日数がたっていない新しいバージョンを止める(cooldown)。1〜365日で設定し、0にするとオフ 1日

証明が途中でなくなる場合について、GitHub Docsは「公開の手順が乗っ取られたしるしの可能性がある」と説明しています。インストール時に動くスクリプトは、システム上で任意のコマンドを実行でき、認証情報を盗むのに使われることがあるとしています。Minimum package ageは、新しく公開されたバージョンの危険が見つかるまでの時間を取るための設定です。

設定の流れ

設定は2段階です。まず企業の管理者がポリシーを決め、次にnpmを使う各エンドポイントがファイアウォール経由でパッケージを取りに行くようにします。

1. ポリシーを決める(企業の管理者)

ポリシーを変えられるのは、エンタープライズ管理者とエンタープライズ セキュリティ マネージャーです。

  1. GitHub.comで自分のEnterpriseを開く(たとえばEnterprisesのページから)
  2. ページ上部の「Policies」をクリックする
  3. サイドバーの「Package firewall」をクリックする
  4. 上の表の各項目を設定する

ほかの人にもポリシーの閲覧と変更を任せたい場合は、カスタムロールに「Edit enterprise-level package firewall policy」という細かい権限を加え、そのロールをチームや個人に割り当てます。

2. npmがファイアウォールを通るようにする

ファイアウォールのレジストリーURLは企業ごとに決まっています。リクエストには、Enterpriseのメンバーであるユーザーかボットのアカウントのトークンを付けます。GitHub Docsによると、トークンに必要な権限は、公開リポジトリーの読み取りだけです。

設定はユーザー単位の.npmrcに書きます。次の例の「ENTERPRISE」は自分のEnterpriseのスラッグに置き換えます。環境変数GITHUB_TOKENには、Enterpriseにアクセスできるトークンを入れておきます。

registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}

同じ設定は、コマンドでも入れられます。

npm config set registry \
  https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
npm config set \
  '//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}'

2つ目のコマンドは「${GITHUB_TOKEN}」をシングルクォートで囲んでいます。こうすると、トークンの値そのものではなく「${GITHUB_TOKEN}」という文字が.npmrcに書き込まれます。.npmrcに書いた「${変数名}」は、npmが環境変数の値に置き換えます(npm公式の.npmrcの説明)。GitHub Docsは、トークンをCIのシークレットなど安全な場所に保管し、リポジトリーにコミットしないよう求めています。

JFrog Artifactoryを使っている場合

JFrog Artifactoryから、ファイアウォール経由でパッケージを取りに行くようにもできます。エンドポイントはこれまでどおりArtifactoryを使い、公開パッケージと社内のパッケージを組み合わせたまま、ファイアウォール経由の公開パッケージにポリシーをかけられます。GitHub Docsでは、Artifactoryへの対応は試験的なものとしています。

手順の要点は、npmの「Remote」リポジトリーを作り、URLにファイアウォールのレジストリーURLを入れることです。そのうえで、仮想(virtual)リポジトリーにこのリモートと社内のnpmリポジトリーを含めます。公開npmレジストリーから直接取りに行くリモートは仮想リポジトリーから外し、ファイアウォールを通らない経路を残さないようにします。細かい手順はGitHub Docsにあります。

必要なパッケージが止められたとき(例外の申請)

必要なパッケージが止められることもあります。たとえば、セキュリティの修正を含む新しいバージョンが、Minimum package ageの設定で止められる場合です。そのときは、ポリシーの例外を申請できます。

止められたときは、npmの出力やCI/CDのログに、例外を申請するためのURLが出ます。GitHub Docsには次の出力例があります。

npm notice testcontainers: 1 version blocked by package-firewall due to security policies (version cooldown). Request an override: https://github.com/enterprises/octocats/security/bypass-requests/package-firewall/new?ecosystem=npm&package=testcontainers

このURLをブラウザーで開くと、申請フォームが表示されます。入っている内容を確かめ、足りない所を足して申請します。

申請を確かめて承認するのは、エンタープライズ管理者とエンタープライズ セキュリティ マネージャーです。Enterpriseのページ上部の「Security and quality」から、サイドバーの「Package firewall bypass」を開くと、申請の一覧が出ます。承認された例外はポリシーに加わり、「Policies」→「Package firewall」の「Package overrides」で確かめたり、不要になったものを外したりできます。

承認するときに「Version or range to allow」を「*」にすると、そのパッケージのすべてのバージョンを許可できます。GitHub Docsは、例外の範囲が申請されたバージョンより広がる点に触れたうえで、使い道の例として、自社のパッケージで新しいバージョンのたびに申請しなくて済むようにする場合を挙げています。

導入する前に確かめておくこと

  • 自分の組織がGitHub Enterprise Cloudを契約しているか
  • 守りたいエンドポイント(Actionsのランナー、コーディングエージェント、開発者のPC)がnpmを使っているか。今はnpm以外のパッケージには対応していません
  • Minimum package ageの初期値は1日です。公開直後の修正版が止められたときは、例外を申請できます
  • パブリックプレビューの期間は無料ですが、正式提供後は使った量に応じた課金になります

GitHubのほかのセキュリティ機能は、AI Scan for pull requestsの記事とCopilotのローカルサンドボックスの記事にもあります。

参考にした公式情報

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

社内エンジニアとして、SREとセキュリティの仕事をしています。サーバーの構築や運用、クラウド環境の設計にも関わってきました。趣味はゲームと漫画・アニメ。

コメント

コメントする

目次