記事

GitHub、シークレットが残ったプルリクエストのマージを自動ブロックする新ルールを公開

GitHubはリポジトリルールセットに新しいルールを追加し、シークレットスキャンのアラートが未解決のプルリクエストをマージできないようにしました。GitHub公式ブログをもとに、push protectionとの違いや設定方法を紹介します。

GitHubは公式ブログで、リポジトリルールセットに新しいルールを追加し、シークレットスキャンのアラートが未解決のプルリクエストをマージできないようにする機能を発表しました。これまでのpush protectionが「シークレットをリポジトリに到達させる前に止める」仕組みだったのに対し、今回のルールはプルリクエストの段階でもう一段階のチェックを加えるものです。GitHub Secret ProtectionまたはGitHub Advanced Securityを契約している顧客向けに、パブリックプレビューとして本日から利用できます。

新ルールでプルリクエストの段階でも検出

今回追加されたのは「require secret scanning alerts are resolved on pull requests」という新しいルールで、対象リポジトリごとに有効化できます。このルールが有効なリポジトリでは、バイパス権限を持たない開発者は、プルリクエストに含まれる各アラートを解決しない限りマージのブロックを解除できません。ルールは大きく分けて2つの条件をチェックします。1つは対象コミットに対してシークレットスキャンが完了していること、もう1つはプルリクエストのコミットによって新たに持ち込まれたシークレットのアラートが残っていないことです。デフォルトでは、オープン状態のプルリクエストに対して動作し、プロバイダーのパターンで検出されたシークレットをブロック対象とします。カスタムパターンや汎用パターンなど、他のカテゴリーのシークレットもブロック対象に含めるよう追加で設定することも可能です。

緑を基調としたGitHubのセキュリティ機能を紹介するバナー画像

画像引用元: GitHub Blog

push protectionとの違いはチェックのタイミング

GitHubはブログの中で、既存のpush protectionと今回のルールの違いを明確に説明しています。push protectionは、シークレットがリポジトリに到達する前、つまりプッシュの時点で検出してブロックする仕組みです。一方、今回のルールはプルリクエストのレイヤーにもう一段の保護を追加するもので、push protectionでは捕捉できない、あるいはpush protectionの設定上捕捉するように構成されていないケースを拾い上げる役割を担います。例えば、汎用パターンのシークレットについてはpush protectionを無効にしたままにしておきつつ、そのカテゴリーのシークレットについてはプルリクエストの段階でマージをブロックするルールセットを維持する、といった使い分けが可能になります。この二段構えの仕組みにより、開発フローの早い段階と、マージ直前の最終チェックの両方でシークレットの混入を防げるようになります。

新ルール名: require secret scanning alerts are resolved on pull requests
チェック内容: 対象コミットのスキャン完了、および新規シークレットアラートの未解決確認
提供形態: パブリックプレビュー(GitHub Secret Protection / GitHub Advanced Security契約者向け)
push protectionとの違い: プッシュ時点のブロックか、プルリクエスト時点のブロックか
設定方法: リポジトリ・組織・エンタープライズ設定のRulesetsタブから有効化

設定方法とAPIからの操作

新しいルールを有効にするには、リポジトリ、組織、またはエンタープライズの設定画面から「Repository」内の「Rulesets」タブを開き、保護したいブランチを対象とするルールセットを新規作成するか、既存のルールセットを編集します。そのうえで「Require secret scanning alerts are resolved」を選択すれば設定は完了です。画面から操作するだけでなく、REST APIではrequire_secret_scanning_alert_resolutionというルールタイプにシークレットの種類を指定するsecret_typesパラメーターを渡すことで、GraphQL APIではREQUIRE_SECRET_SCANNING_ALERT_RESOLUTIONを指定することで、それぞれプログラムからルールを設定することも可能です。組織単位で多数のリポジトリを管理している場合は、APIを使って一括で設定を展開する運用が現実的な選択肢になりそうです。

開発チームに求められる運用の見直し

シークレットの漏えいは、APIキーや認証トークンが公開リポジトリはもちろん、プライベートリポジトリ内でも意図せずコミットされてしまうことで発生します。今回のルールは、そうした漏えいをプルリクエストのレビュー段階という、開発者が最後に変更内容を確認するタイミングで食い止められる点が特徴です。バイパス権限を持つメンバー以外は原則としてマージ前に必ずアラート解消を求められる形になるため、チームによってはレビュープロセスの一部として「シークレット解消」の手順を明示的に組み込む必要が出てくるでしょう。パブリックプレビューの段階ではありますが、GitHub Advanced SecurityやGitHub Secret Protectionを導入済みの組織は、まず一部のリポジトリで有効化して挙動を確認しておくとよさそうです。