1.2セキュア SDLC とアラート戦略・ガバナンス

GHAS の真価は、機能を SDLC 全体 に組み込み「シフトレフト（早期に防ぐ）」する点にあります。コードを書く段階から、PR、マージ、デプロイまで各所でセキュリティを効かせ、検知 → 優先順位付け → 修復 のサイクルを回します。GH-500 では、戦略の選択（予防優先かゲートか）、キャンペーンによる大規模修復、そして役割とガバナンスが問われます。

1.2.1予防優先 vs ゲートベース

予防優先（prevention-first） は、問題を そもそも入れない 戦略です——たとえば Push Protection で秘密のコミットを源流で止める（第2章）。ゲートベース は、PR マージや デプロイの前に検査 を置いて通過を制御する戦略です——Code Scanning や Dependency Review を 必須チェック にして、脆弱性があればマージをブロックします。両者は排他ではなく、組み合わせて 多層 にします。「混入を防ぐ（予防）」と「混入を通さない（ゲート）」の役割の違いを押さえます。

1.2.2セキュリティキャンペーン

セキュリティキャンペーン は、多数のリポジトリにまたがる 既存アラートを束ねて計画的に修復 する仕組みです。セキュリティチームが「この種の脆弱性を期限までに直す」と対象を選び、各リポの担当者に修復を割り当て、進捗を追跡します。個別対応では追いつかない 大規模な技術的負債（リスク）の削減 に有効で、PR ベースの修復や自動化と組み合わせます。

1.2.3アラートの管理・役割・委譲バイパス

アラートには 役割ごとの責任 があります——開発者 は自分のコード/PR のアラートを修復、セキュリティ担当（security manager） は方針・優先順位・例外を管理、管理者 は機能の有効化とポリシーを統制します。アラートの 却下/無視（dismiss） は慎重に行い、理由を記録します（不用意な dismiss はリスクを見逃す）。委譲バイパス（delegated bypass） は、Push Protection 等のブロックを 承認制で一時的に回避 できる仕組みで、誰がバイパスを承認できるかを アクセス管理と強制 で制御します。

1.2.4この節のまとめ

• 予防優先（源流で防ぐ）とゲートベース（マージ/デプロイ前にブロック）を組み合わせて多層に
• セキュリティキャンペーンで多リポの既存アラートを束ねて計画的に大規模修復
• 役割：開発者（修復）/security manager（方針・例外）/管理者（有効化・ポリシー）
• dismiss は理由記録＋慎重に、委譲バイパスは承認制の例外（承認者を統制）