Skip to main content
Skip to content

GitHub パッケージ ファイアウォールを使用したエンドポイントの保護

GitHub package firewallを使用して、開発者のマシン、AI エージェント、CI ランナー上での依存関係のインストールを保護します。

メモ

この機能は現在 パブリック プレビュー であり、変更される可能性があります。

GitHub package firewall の概要

GitHub package firewallは、エンドポイントとパッケージ レジストリの間に配置されます。 パッケージ公開後の最低経過期間やマルウェアアドバイザリなどのポリシーに対してパッケージのダウンロードを評価し、それらのポリシーを満たしていないダウンロードをブロックします。 これを使用して、CI ビルド、AI エージェント セッション、ローカル開発での依存関係のインストール処理を保護できます。

ファイアウォールを使用するには、企業のポリシー制御を構成し、パブリック レジストリから直接ではなく、ファイアウォール経由でパッケージを要求するようにエンドポイントを構成します。 カスタム ロールを使用してポリシーを管理するためのアクセス権を付与することもできます。

ポリシー制御の構成

エンタープライズ セキュリティ マネージャーとエンタープライズ管理者は、ポリシー制御を構成できます。

  1. 企業ページに移動してください。 たとえば、GitHub.com の [Enterprise] ページから。
  2. ページの上部にある [ポリシーの] をクリックします。
  3. サイドバーで、[ Package firewall] をクリックします。
  4. 次のセクションで説明するポリシー コントロールを構成します。 これらの制御は、ファイアウォールを通過するすべての要求に適用されます。

既知のマルウェアをブロックする

有効にすると、このコントロールは、GitHub Advisory Database でアクティブなマルウェア アドバイザリをチェックし、一致するアドバイザリを持つパッケージをブロックします。 このコントロールの既定値は [オン] です。

脆弱性アドバイザリのブロック

このコントロールは、GitHub Advisory Database に、要求されたパッケージ バージョンに影響する脆弱性がないかをチェックします。 インストールをブロックする最小アドバイザリ重要度を選択します。重大のみ、高以上、中以上、または任意の重大度。 このコントロールの既定値は Critical のみです。

ブロック証明のダウングレード

このコントロールは、要求されたパッケージ バージョンのアテステーションと以前のバージョンのアテステーションを比較します。 パッケージに以前は SLSA 構成証明があったものの、要求されたバージョンには SLSA 構成証明がない場合、ファイアウォールはダウンロードをブロックします。 証明情報がない場合は、改ざんされた発行プロセスを示している可能性があります。 構成証明書の詳細については、「アーティファクト証明書」を参照してください。 このコントロールの既定値はオンです。

新しく導入されたインストール スクリプトをブロックする

このコントロールは、 preinstall や postinstall スクリプトなど、インストール中に実行されるスクリプトをパッケージが最近追加したかどうかを確認します。 これらのスクリプトは、システム上で任意のコマンドを実行でき、資格情報を盗むために使用できます。 このコントロールの既定値は オン です。

パッケージの最小経過時間

このコントロールは、新しく発行されたパッケージ バージョンのクールダウン期間を設定します。 ファイアウォールは、設定された最小経過期間よりも新しいバージョンをブロックし、それらをインストールする前に脅威が発見される時間を確保します。

最小日数を 1 ~ 365 日の値に設定するか、0 に設定してコントロールを無効にします。 既定値は 1 日です。

エンドポイントがPackage firewallを使用するように構成する

既定のパブリック レジストリではなく、ファイアウォールの URL からパッケージをフェッチするようにパッケージ マネージャーを構成します。

認証トークン

レジストリ URL は、お客様の企業に固有です。 各要求には、企業のメンバーであるユーザーまたはボット アカウントに関連付けられている認証トークンが含まれている必要があります。 トークンには、 パブリック リポジトリへの読み取り専用アクセスを超える昇格されたアクセス許可は必要ありません。 詳細については、「個人用アクセス トークンを管理する」を参照してください。

npm の構成

npm を構成するには、ユーザー レベルの .npmrc ファイルを使用します。 例では、ENTERPRISE をあなたのエンタープライズ スラッグに置き換えます。 GITHUB_TOKEN を、エンタープライズにアクセスできる GitHub トークンに設定します。 CI シークレットなどにトークンを安全に格納し、リポジトリにコミットしないでください。

  1. ユーザー レベルの .npmrc ファイルに次の構成を追加してください。

    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}'

Artifactoryの設定

ファイアウォールを介してパッケージを取得するように JFrog Artifactory を構成できます。 エンドポイントは引き続き Artifactory を使用します。これにより、パブリック パッケージとプライベート パッケージを組み合わせて、ファイアウォール経由で取得されたパッケージにファイアウォール ポリシーを適用できます。

Artifactory インスタンスで管理者特権を持っている必要があります。

メモ

Artifactory のサポートは試験的です。 Artifactory のサポートに関する提案や懸念事項を共有するには、 コミュニティのディスカッションを参照してください。

  1. Artifactory で、[ 管理 ] タブをクリックし、[ リポジトリの作成] をクリックします。
  2. リポジトリの種類として リモート を選択し、パッケージの種類として npm を選択します。
  3. [リポジトリ キー] フィールドに、gh-package-firewall のような名前を入力します。
  4. [URL] フィールドに「https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE」と入力し、ENTERPRISE をご自身のエンタープライズ スラッグで置き換えます。
  5. [パスワード/アクセス トークン] フィールドに有効な personal access tokenアクセス トークンを貼り付け、[トークン認証を有効にする] を選択します。
  6. Artifactory 構成に基づいて、ファイアウォールを使用する ステージ を選択してください。
  7. [パターン] フィールドに、「 **/* 」と入力して、すべてのパッケージ パスを含めます。
  8. 保存 をクリックします。
  9. 仮想 npm リポジトリを作成または更新して、このリモートおよびプライベート npm リポジトリを含めます。 ファイアウォールをバイパスできないように、パブリック npm レジストリからパッケージを直接フェッチするリモートを除外します。
  10. 仮想リポジトリのSet me upの手順に従って、エンドポイントを構成します。

きめ細かいアクセス許可

既定では、エンタープライズ管理者とエンタープライズ セキュリティ マネージャーはファイアウォール ポリシーを変更できます。 ポリシーを表示および変更するためのアクセス権を他のユーザーに付与するには、"エンタープライズ レベルのパッケージ ファイアウォール ポリシーを編集する" きめ細かいアクセス許可をカスタム ロールに追加し、そのロールをチームまたは個人に割り当てます。

例外の管理

ファイアウォールで必要なパッケージがブロックされている場合は、ポリシーに例外を要求できます。 たとえば、セキュリティ修正を含む新しいパッケージ バージョンは、最小パッケージ有効期間ポリシーによってブロックされる可能性があります。

例外を申請中

ファイアウォールがパッケージをブロックすると、npm 出力または CI/CD ログに例外を申請するための URL が含まれます。 例えば次が挙げられます。

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
  1. ブラウザーで URL を開きます。

  2. 事前入力されたフィールドを確認し、不足している情報を入力してください。

    • "Repository": ブロックが発生したリポジトリ
    • "エコシステム": パッケージ エコシステム (現在、npm のみがサポートされています)
    • "パッケージ名": @scope プレフィックス (該当する場合) を含むパッケージ名
    • "バージョン": インストールしようとしたバージョン
    • "Reason": パッケージのブロックを解除する必要がある理由
    • "コメントの追加": レビュー担当者の追加コンテキスト
  3. 要求を送信します。

例外要求の確認と承認

エンタープライズ管理者とエンタープライズ セキュリティ マネージャーは、例外要求を確認できます。

  1. 企業ページに移動してください。 たとえば、GitHub.com の [Enterprise] ページから。
  2. ページの上部にある [ Security and quality] をクリックします。
  3. サイドバーで、Package firewallバイパス をクリックします。
  4. [Package firewall bypass requests] リストで、検索バーを使用して要求を検索し、要求をクリックします。
  5. [Review package allow override] ダイアログで、要求された例外申請を確認します。
  6. 必要に応じて、パッケージのすべてのバージョンを許可するには、[許可するバージョンまたは範囲] フィールドで要求されたバージョンを * に置き換えます。 これにより、要求されたバージョンを超えて例外が広がります。
  7. 決定を説明するコメントを追加し、[リクエストを承認] をクリックします。

たとえば、最小パッケージ経過時間ポリシーが新しいバージョンをブロックするたびに個別の例外を必要とするのではなく、組織所有のパッケージのすべてのバージョンを許可できます。

承認の管理

承認されたバイパス要求がファイアウォール ポリシーに追加されます。 エンタープライズ管理者とエンタープライズ セキュリティ マネージャーは、手動で追加された例外を含め、古い例外や不要な例外を確認して削除できます。

  1. 企業ページに移動してください。 たとえば、GitHub.com の [Enterprise] ページから。
  2. ページの上部にある [ポリシーの] をクリックします。
  3. サイドバーで、[ Package firewall] をクリックします。
  4. [オーバーライド] で、[パッケージのオーバーライド] をクリックします。
  5. ポリシーから例外を削除するには、例外の横にある [ ] をクリックします。

詳細については、次を参照してください。