目次
GitHubは2026年10月20日、Package Firewallの公開プレビューを発表しました。開発端末、CI、コーディングエージェントとパッケージ配布元の間に置き、メタデータ要求と実体のダウンロードをポリシーで検査する機能です。現時点で対象はnpmに限られ、GitHub Enterprise Cloud向けに提供されています。
AIがコードだけでなく依存関係も追加する環境では、レビュー前にインストール処理が走る場面が増えます。今回の変化は、その取得段階を組織の管理対象にできる点です。本稿では10月21日に確認した提供条件を整理し、CIとAIエージェントへ安全に導入する判断を解説します。性能や検出率を独自に測定したものではありません。
一次資料：GitHub package firewall in public preview（GitHub）、Protecting endpoints with GitHub package firewall（GitHub Docs）。以下の運用手順と仮想例は本サイトの提案です。
スポンサーリンク
コードを読む前に実行される処理を管理する
パッケージ導入では、アプリがその機能を呼ぶ前でもインストールスクリプトが動く場合があります。秘密情報を持つCIや開発端末で、取得元を間違えた依存関係を入れると、アプリのテストとは別の段階で問題が起き得ます。GitHubの発表も、導入時に資格情報を狙う攻撃を背景に挙げています。
Package Firewallは、上流レジストリーを直接指定する代わりに、管理された取得先を利用する構成です。リポジトリーで機能を見つけて有効化するだけで、すべての端末の通信が自動的に切り替わるわけではありません。ポリシーを設定した上で、各endpointがその経路を使う必要があります。
AIエージェントにも同じ問題があります。依存関係を追加するツールがnpm設定を使うのか、別のシェルを起動するのか、独自の取得先を使うのかで適用範囲は変わります。エージェントの名前だけで防御済みとせず、実際にパッケージを取得するプロセスと通信経路を確認します。
利用条件と費用を先に確認する
公式発表では、データ所在地を指定する環境を含むGitHub Enterprise Cloudの利用者が対象です。公開プレビュー中は無料ですが、一般提供時にはActionsに似た従量課金を予定しています。プレビューの無料提供を恒久的な料金条件として見積もると、導入後の運用費を見誤ります。
現時点ではnpmのみをサポートします。Python、Maven、OSパッケージ、コンテナイメージなども同じ機能で検査されると仮定してはいけません。利用している言語と配布経路を一覧にし、今回の試行対象と既存対策で扱う範囲を明確にします。
プレビューは仕様が変更される可能性があります。本サイトでは、組織全体の必須経路にする前に、小さなチームと代表的なCIで試し、障害時の窓口、例外の担当、料金情報の見直し時期を決めることを勧めます。公開プレビューの導入を、安定性が保証された一般提供と同じ判断で進めないためです。
スポンサーリンク
ポリシーごとに違う意味を持たせる
公式ドキュメントには既知のマルウェア、脆弱性アドバイザリ、attestationの後退、新たに追加されたインストールスクリプト、公開からの日数といった検査が示されています。これらはそれぞれ異なる信号です。すべてのブロックを単に危険判定として扱うと、例外判断の根拠を残せません。
クールダウンは新しい版を一定期間待たせ、危険が発見される時間を確保する考え方です。公式では最小日数を1〜365日、0で無効、既定は1日としています。しかし、時間が経てば安全になる保証はありません。緊急のセキュリティ修正版まで待たせる可能性があるため、例外と既知の問題の優先順位を設計します。
脆弱性の閾値を厳しくすれば止まるビルドも増えます。対象の版が実際に使う機能へ影響するか、修正先があるか、直接依存か推移依存かを調べる担当が必要です。理由を見ずに全ブロックへ例外を許可する運用では、検査を追加した価値が失われます。
attestationが以前の版にはあるのに新しい版では消える変化は、公開工程の異常を調べる手掛かりになります。ただし、証明情報があること自体がコードの安全性を保証するわけではありません。出所の確認と、コード内容や依存先の評価を別の確認事項として管理します。
CIへ入れる前に取得経路を図にする
導入対象のジョブについて、パッケージマネージャー、ロックファイル、レジストリー設定、認証情報、キャッシュ、runnerの再利用を一覧にします。リポジトリー設定、利用者設定、環境変数が上書きし合う場合もあるため、実行時にどの設定が選ばれるかを確認します。
説明用の仮想例として、通常のCIは管理されたnpm設定を使う一方、AIが作った補助ジョブが別のコマンドで公開レジストリーを直接参照する環境を考えます。この場合、主ジョブだけの成功を見て全経路が保護されたと報告できません。ログには秘密を出さず、要求先と検査結果が対応することを確かめます。
キャッシュが温まった状態では、パッケージ取得が発生せず、経路の不備を見落とすことがあります。試行環境では空のキャッシュと通常のキャッシュを両方使い、初回構築、依存更新、既存ロックファイルの再現ビルドを確認します。本番のキャッシュを無計画に削除する必要はありません。
スポンサーリンク
例外承認は期限と対象版を持たせる
誤検知や緊急更新で例外が必要なら、対象パッケージ、版、ブロック理由、承認者、利用するプロジェクト、終了条件を記録することを提案します。パッケージ名全体へ無期限で例外を出すと、将来の別の危険な版まで通す結果につながり得ます。実際の製品が提供する例外単位を確認して運用票へ反映します。
例外申請の経路には、開発担当とセキュリティ担当の応答時間も必要です。深夜の障害修正で申請を誰も見ないなら、利用者は別の取得経路を作りがちです。緊急時の当番、承認できる条件、後日の見直しを先に決め、正規の手順が業務の中で使える状態にします。
AIエージェントがブロックを受けた場合にも、制限を解除する判断をそのエージェントへ一任しません。別の版を選ぶ、不要な依存を取り除く、人へ申請するなど、承認された次の行動を設計します。例外申請文にツール出力を貼るときは、レジストリーのトークンや社内パッケージの秘密を含めないようにします。
導入試験の合格条件を決める
本サイトが提案する試験は、通常の依存導入が成功すること、ポリシーに合わない試験対象が期待どおり止まること、例外が監査可能であることの三つです。実際のマルウェアを持ち込まず、提供元が案内する検証方法や許可されたテスト用パッケージを使います。
計測するのはビルド時間だけではありません。誤ったブロックの件数、例外の処理時間、適用されていないendpoint、失敗時に利用者が取った行動も記録します。ビルドの成功率が下がった理由が検知によるものかサービス障害かを区別できれば、閾値や運用を改善できます。
試行導入で残すポリシーごとの結果
仮想のチームで、日常のWeb開発と緊急の脆弱性更新を同じCIが処理しているとします。新規版を待たせるポリシーが通常開発には有効でも、修正版へすぐ上げたい場面では競合します。この場合、すべての待機制限を無効にするより、対象版と理由を確認して必要な例外を通す運用を用意します。
試行の記録は、要求したパッケージと版、適用されたポリシー、結果、待ち時間、例外の理由を中心にします。秘密を含むURLや認証ヘッダーを丸ごと集める必要はありません。チーム外へ集計を出すときは、社内パッケージ名などの扱いも決め、検査を追加したことが情報の拡散につながらないようにします。
既に取得済みの依存を使う場合と、新たに取得する場合で結果が違えば、その差を記録します。ロックファイルには版の固定だけでなく取得元の情報が残る場合もあるため、設定を変えた後も想定する経路が使われるかを確認します。コマンドの成功だけで全ダウンロードの検査を証明しないことが大切です。
業務上必要な例外が多すぎる場合は、閾値の設定、依存の古さ、更新頻度、開発手順のどこが原因かを調べます。例外の数を減らすために申請を禁止すると、表に出ない迂回が増える可能性があります。開発者が使える手順と防御の目標を合わせ、試行の結果から段階的に調整します。
一般提供後の料金へ備えるには、ジョブ数だけでなく、キャッシュの有無、依存更新頻度、開発端末やエージェントのセッション数を把握します。正式な課金単位が公表されたら、その仕様へ合わせて見積もりを更新してください。現時点で具体的な単価や将来の無料枠を推測する必要はありません。
試行の終了時には、導入するendpointと保留するendpointを明確にします。保留の理由が機能未対応か、性能か、管理権限かで次の対処は違います。プレビューを一度試した事実だけで全社導入済みと報告せず、実際に検査を通っている経路と、その証拠を残します。
通知を受ける担当には、マルウェアの検知と、公開からの日数が足りないブロックを区別して伝えます。後者を攻撃発見として扱うと不要な調査が増え、前者を単なる待機と扱うと対応が遅れます。判定理由ごとの連絡先と解除条件を運用に組み込み、ポリシーの結果を開発者が理解できる形で表示することが大切です。
防御は取得経路を通る要求へ適用されます。未発見のマルウェア、別の配布経路、既に侵害されたCI、承認された例外まで自動的に解消するものではありません。秘密を少なくしたrunner、ソースレビュー、配備承認、成果物検証と組み合わせて運用します。
今回の機能は、依存関係の危険をアプリ完成後に探すだけでなく、持ち込む入口で扱える変化です。導入判断では対応パッケージ、適用経路、例外、費用、障害時の扱いを一緒に確認してください。AIによる依存追加が増える現場ほど、インストール前に何を止めるかを具体化する価値があります。
