3.2リポジトリのセキュリティ機能

管理者は、GHAS（GitHub Advanced Security, 第3章は GH-500 が詳細）の各機能を 組織横断で有効化・統制 し、検知から対応までの 仕組み を整えます。GH-100 では、機能の 構成 と、検知された問題への 対応計画 を管理者として用意する力が問われます（深い運用は GH-500 が担う領域で、ここは管理者視点の有効化と統制）。

3.2.1脆弱性アラート・secret scanning・CodeQL

管理者は次を組織/リポジトリで有効化します——脆弱性アラート（依存の既知脆弱性, Dependabot 連携）、secret scanning（Secret Protection）（漏洩した秘密の検出と Push Protection）、CodeQL（Code Security）（コードの静的解析）。デフォルトセキュリティ構成 を使うと、これらをテンプレート化して 多数のリポへ一斉適用＋継承 できます（GH-500 と共通の考え方）。公開リポは多くが無料、プライベート/Enterprise は GHAS ライセンス が要る点も管理者の前提知識です。

3.2.2Dependabot とセキュリティアドバイザリ

Dependabot は依存の脆弱性を検知し、セキュリティ更新（安全な版への PR） や バージョン更新 を行います（GH-500 で詳述）。セキュリティアドバイザリ（GitHub Advisory Database / リポジトリのアドバイザリ）は、脆弱性情報の出所で、リポジトリ管理者は自プロジェクトの脆弱性を 非公開で修正してから公開 できます。管理者は、これらの機能を組織で有効化し、通知やアラートの 受信者/権限 を整え、修復が滞らないようにします。

3.2.3セキュリティ対応計画

検知の仕組みを整えるだけでなく、検知された問題に 誰が・どの優先順位で・いつまでに対応するか の 対応計画（response plan） を定めます——重大度の基準（ルールセットは重大度ベースのマージ保護を強制可。時間SLAの強制は不可）、役割と所有権（開発者/security manager/管理者）、エスカレーション、記録（dismiss の理由）です。これにより、アラートが 放置されず確実に修復 される運用を実現します。リポジトリには SECURITY.md を置いて脆弱性の報告手順（連絡先・対応方針）を公開することもできます。

3.2.4この節のまとめ

• 脆弱性アラート/secret scanning/CodeQL を組織横断で有効化、デフォルト構成で一斉適用＋継承
• Dependabot で依存脆弱性検知＋自動 PR、セキュリティアドバイザリは脆弱性情報源（非公開修正→公開）
• 検知だけでなく対応計画（誰が/優先度/SLA/役割/記録）を定め放置を防ぐ
• プライベート/Enterprise の全機能は GHAS ライセンス、SECURITY.md で報告手順を公開