GitHubがpackage firewallを公開プレビューへ。npmの取得経路と利用条件を確認しよう

依存パッケージを更新する際、名前とバージョンを確認するだけでは、インストール時の攻撃まで防げるとは限らない。GitHubは10月20日、パッケージの取得経路に検査を挟む「package firewall」を公開プレビューとして発表したよ。

対象はGitHub Enterprise Cloudの利用者で、データ所在地を指定するEnterprise Cloudも含まれる。今回の対応はnpmパッケージに限られるため、すべての言語の依存関係をまとめて保護する新機能、と広げて受け取らないようにしよう。

パッケージを取りに行く途中で、方針を適用する

パッケージレジストリは、ライブラリなどを配布する場所。package firewallは、開発用端末やCIの実行環境、コーディングエージェントなどと、配布元の間に入る仕組みだよ。

公式発表では、パッケージ一覧などのメタデータ取得と、実体のダウンロードの両方を検査すると説明されている。管理者が方針を決め、その方針に合わない取得をブロックする。

使える制御には、新しく公開されたバージョンの待機期間、GitHub Advisory Databaseにあるマルウェア・脆弱性情報の確認、証明情報の格下げなどのサプライチェーン検査が含まれる。導入するだけで、未知の問題を含めてすべて安全だと保証するものではないよ。

待機期間は、更新を遅らせる方針として考える

公式手順では、公開されてからの日数の下限を1〜365日に設定でき、0で無効化する。既定値は1日と案内されている。これは、公開直後のバージョンをすぐ取得しないための制御だよ。

一方で、修正版を急いで使いたいときには、待機期間や別の制御に引っかかることも考えられる。長く待てば常に最適、とは決めず、更新の緊急性と例外の扱いも先に決めたいね。

利用条件と料金は、現在と将来を分ける

一般提供後の単価を、この発表から決めつけることはできない。「プレビュー中は無料」を、今後も無条件で無料だと読み替えないでね。対象契約を新たに申し込むかどうかは、このニュースだけで判断せず、利用範囲と正式な条件を確認しよう。

管理画面の設定だけでは、取得経路は切り替わらない

重要なのは、取得する側の設定も必要な点。公式手順では、npmなどが通常のレジストリへ直接接続する代わりに、firewallのURLを使うよう設定する。認証トークンも安全に扱う必要があるよ。

設定対象から漏れた端末や実行環境があると、そちらは元の取得経路を使う可能性がある。まず、どこで依存関係をインストールしているかを洗い出そう。

ここからは、編集部の試行前チェック案。

1. Enterprise Cloudの対象環境か、管理者と確認する。
2. CI、開発端末、エージェントのうち、試す環境を一つ選ぶ。
3. 現在のレジストリ設定と、秘密情報を含まない範囲の復元手順を記録する。
4. 公式手順に沿って取得先と認証を設定し、必要なパッケージが取得できるか確認する。
5. ブロック時の理由と、誤検知時に例外を申請する担当・手順を確かめる。

トークンを設定ファイルへ直接書いてコミットしないよう、公式例の環境変数やCIのシークレットの扱いも確認しよう。本番の依存関係取得先を、このサイトが変更したわけではないよ。

自動更新の対応バージョンについては、Dependabotのnpm・pnpm・Bun対応も参考になる。Dependabotが更新案を作ることと、今回の取得時の制御は、別の役割として確認しよう。