GitHubのセキュリティ運用を再設計する：PR・依存関係・シークレットの三層防御

GitHubのセキュリティ機能は、問題を見つける場所をリポジトリの奥から開発者の手元とプルリクエスト（PR）へ移しつつあります。
重要なのは、新しい検知機能を有効にすることではなく、検知後の確認、修正、承認までを一つの運用として設計することです。

GitHubが公表した更新では、GitHub Copilotアプリの/security-review、PR上に表示されるAIセキュリティ検知、Dependabotの通常更新に対する既定のクールダウンが加わりました。
本稿では、これらをシークレットスキャンや人手レビューと組み合わせ、開発速度を落としすぎずに防御を厚くする方法を整理します。

三つの更新で変わるセキュリティ確認のタイミング

開発中の変更を確認する/security-review

GitHub Copilotアプリの/security-reviewは、作業中の変更を対象に、インジェクション、クロスサイトスクリプティング、不安全なデータ処理、パストラバーサル、弱い暗号などの問題を調べます。
GitHubの説明では、重要度と確信度を付けた指摘と修正案を返し、修正後の再確認まで同じ作業環境で進められます。

この機能はパブリックプレビューで、Copilot Free、Pro、Business、Enterpriseの利用者に提供されています。
ただし、開発者が自発的に実行するだけでは確認漏れが生じるため、認証、決済、個人情報、ファイル操作などの高リスク変更では、PR作成前のチェック項目として明文化する必要があります。

PRに現れるAIセキュリティ検知

GitHub code scanningのAIセキュリティ検知は、PRが作成または更新されたときに実行され、結果にはAIラベルが付きます。
CodeQLが標準で分析できない言語やフレームワークへ範囲を広げられる点は有用ですが、CodeQLの代替ではありません。

利用には、GitHub Code Security（GitHub Advanced Security）、リポジトリでのCodeQL既定セットアップ、企業レベルと組織レベルの許可が必要です。
パブリックプレビュー中はGitHub CopilotライセンスとAIクレジットも必要で、検知結果は情報提供にとどまり、自動的にはマージをブロックしません。

Dependabotの通常更新に入る三日間の待機

Dependabotは、通常のバージョン更新について、パッケージがレジストリで公開されてから少なくとも三日間待ってPRを作る動作を既定にしました。
公開直後に判明する破損やサプライチェーン攻撃の兆候を取り込む時間を確保する考え方です。

この待機は通常のバージョン更新だけに適用され、脆弱性対応のセキュリティ更新は直ちに作成されます。
必要に応じて.github/dependabot.ymlのcooldownで期間を変えたり、対象から外したりできますが、短縮する場合は自動マージの条件やテスト範囲も同時に見直すべきです。

新機能を三層の防御として組み合わせる

三つの更新は、同じ問題を重複して探す機能ではありません。
守る対象とタイミングが異なるため、次の三層に分けると役割が明確になります。

1. 作業中の変更を早く確認する層：/security-reviewで、PRになる前のコードに対して開発者が初期確認を行います。
2. 共有された変更を組織として確認する層：CodeQL、AIセキュリティ検知、テスト、人手レビューをPRに集約します。
3. コード以外の侵入経路を抑える層：Dependabot、dependency review、secret scanning、push protectionで依存関係と認証情報を守ります。

この構成なら、一つの検知が見逃しても別の層で気付ける可能性が残ります。
一方で、すべての通知を同じ重要度で扱うとレビューが停滞するため、マージを止める条件と、後で調査する条件を分けることが欠かせません。

導入前に確認する四つの前提

1. 対象リポジトリと料金条件を棚卸しする

公開リポジトリと非公開リポジトリでは、利用できる機能や必要なプランが異なります。
組織内のリポジトリを、公開範囲、扱うデータ、インターネット公開の有無、デプロイ権限、主要言語で分類し、どこから試すかを決めます。

AIセキュリティ検知は実行時にAIクレジットを消費するため、全リポジトリへの一括展開より、顧客データや認証を扱う代表的なリポジトリで検知精度と費用を測る方が安全です。
利用条件は変更される可能性があるので、展開時にはGitHubの管理画面と公式文書を再確認します。

2. CodeQLの分析範囲を把握する

AIセキュリティ検知を使う場合も、リポジトリではCodeQLの既定セットアップが必要です。
まずCodeQLがどの言語を分析し、生成コード、モノレポ内の複数アプリ、独自ビルドがどこまで対象になっているかを確認します。

AIによる検知範囲の拡張を理由に、既存の静的解析やテストを外してはいけません。
決定的なルールで再現できる検査と、文脈を見て候補を示す検査を併用する方が、見逃しと誤検知の両方を管理しやすくなります。

3. 誰が判断し、いつ直すかを決める

通知先だけを設定しても、担当者と期限がなければアラートは残り続けます。
重大度、外部公開の有無、攻撃可能性、修正による影響を基準に、即時対応、マージ前対応、期限付き対応、受容の四つ程度へ分類すると運用しやすくなります。

検知を却下する場合は、理由と承認者をPRまたはセキュリティ管理画面に残します。
同じ種類の誤検知が続くなら、個別に無視するのではなく、クエリ、除外範囲、開発ガイドを見直します。

4. シークレット漏えいの初動を決める

secret scanningは、コードだけでなく、Git履歴、Issue、PR、Discussion、Wikiなども対象にできます。
認証情報が見つかった場合は、履歴から文字列を消すことより先に、その認証情報を失効またはローテーションして悪用を止めます。

push protectionを有効にすると、対応するシークレットがリポジトリへ入る前にブロックできます。
ただし、社内固有のトークン形式や設定文字列は標準パターンに含まれないことがあるため、必要に応じてカスタムパターンを用意します。

実装を進める五つの手順

手順1：高リスクな変更を定義する

認証と認可、支払い、個人情報、ファイルアップロード、外部コマンド実行、暗号、GitHub Actionsの権限変更を高リスク変更として一覧化します。
該当するPRでは/security-review、専門知識を持つレビュアー、関連テストを必須にします。

手順2：開発者向けチェックをPRテンプレートに組み込む

任意のツールは、使う場面が曖昧だと定着しません。
PRテンプレートに「高リスク変更の有無」「セキュリティレビュー実施結果」「未解決の指摘」を記入する欄を設け、実施した事実ではなく結果と判断を共有します。

手順3：PR上の情報をマージ規則へ接続する

AIセキュリティ検知は、それ自体ではマージを止めないため、誰が指摘を確認するかをCODEOWNERSやレビュー規則で補います。
高重大度の未解決アラート、必須テストの失敗、必要な承認の不足をブロック条件にし、低確信度の候補は調査キューへ送る設計が現実的です。

GitHubとCopilotを組織で運用する際の権限、監査、レビュー設計は、既存記事のGitHubとCopilotの運用ポイントでも整理しています。
今回の三層防御は、その運用統制をコード変更と依存関係の入口まで具体化するものです。

手順4：Dependabotを「待つ仕組み」と「急ぐ仕組み」に分ける

通常のバージョン更新はクールダウンとテストで慎重に取り込み、脆弱性対応は迅速に処理します。
この違いをチームが理解していないと、三日間の待機をセキュリティ修正の遅延と誤解したり、反対にすべての更新を無条件で自動マージしたりします。

依存関係のPRでは、ロックファイルの差分、メンテナーや公開元、リリースノート、実行されるインストールスクリプト、CI結果を確認します。
重要な実行環境ではdependency reviewも使い、直接依存だけでなく推移的依存の変化を確認します。

手順5：一か月単位で検知品質を見直す

見るべき指標は、アラート数の多さではありません。
マージ前に修正できた件数、重大な見逃し、誤検知率、初回確認までの時間、修正までの時間、AIクレジット消費、開発者が手作業で補った検査を記録します。

検知が多すぎる場合は、対象リポジトリ、生成コード、テスト用フィクスチャ、重大度しきい値を見直します。
検知が少なすぎる場合は、分析対象の言語、ビルドの成功、PRイベント、権限設定を確認し、静かな状態を安全と決めつけないことが重要です。

小規模チームでも優先すべき順序

予算や担当者が限られるチームは、すべてを同時に導入する必要はありません。
まず多要素認証、最小権限、ブランチ保護またはruleset、必須レビュー、Dependabot alerts、secret scanningとpush protectionを整えます。

次にCodeQLの既定セットアップを有効にし、外部公開される主要リポジトリでPR上の検知を試します。
最後に/security-reviewを高リスク変更の早期確認へ組み込み、検知品質と費用が見合う範囲で対象を広げると、機能を増やすこと自体が目的になりません。

よくある質問

AIセキュリティ検知を有効にすればCodeQLは不要ですか

不要にはなりません。
AIセキュリティ検知の利用にはCodeQLの既定セットアップが前提であり、両者は検知方式と得意範囲が異なります。

/security-reviewだけで人手レビューを省けますか

省けません。
ツールの指摘はレビュー材料であり、要件、権限設計、業務上の悪用可能性、修正による副作用は担当者が判断する必要があります。

Dependabotの三日間の待機で脆弱性修正も遅れますか

GitHubの説明では遅れません。
既定のクールダウンは通常のバージョン更新に適用され、セキュリティ更新のPRは直ちに作成されます。

最初に試すリポジトリはどう選べばよいですか

外部公開され、認証や顧客データを扱い、CIとテストが安定している中規模のリポジトリが適しています。
リスクが高すぎる本番中枢や、ビルド自体が不安定なリポジトリを最初に選ぶと、検知品質を評価しにくくなります。

参考資料

• GitHub Changelog: Security reviews now available in the GitHub Copilot app
• GitHub Changelog: Code scanning shows AI security detections on pull requests
• GitHub Changelog: Dependabot version updates introduce default package cooldown
• GitHub Docs: Quickstart for securing your repository
• GitHub Docs: Secret scanning
• GitHub Docs: Dependabot options reference