セキュリティ負債への対応に GitHub Security Overview を活用する方法

2025年6月23日 // 1 min read

image

GitHub Security Overview は、組織の脆弱性監視を支援し、その修復とセキュリティ確保措置を容易に行なえるようにします。

GitHub エグゼクティブ インサイトで公開

開発者は多くの仕事を抱えているため、セキュリティの脆弱性の修正が必ずしも最優先事項であるとは限りません。セキュリティ問題は積み重なり、既知でありながら修復されない脆弱性のバックログが発生します。このようなバックログのことを“セキュリティ負債”と呼びます。この負債を測定し追跡することは、安全かつコンプライアンスに準拠した開発環境を維持し、違反を防止する上で極めて重要です。これを怠った場合、金銭的損失、評判の低下、コンプライアンス違反による罰則につながる恐れがあります。

GitHub Security Overview は、組織の脆弱性監視を支援し、その修復とセキュリティ確保措置を容易に行なえるようにします。このガイドでは、セキュリティ負債の測定方法、データをフィルタリングおよびスライスして優先事項に焦点を当てる方法、GitHub Copilot Autofix を使用して脆弱性をより迅速に修復する方法について説明します。

この記事では以下のことを学びます。

  • 脆弱性を監視、追跡、対処するために GitHub Security Overview を使いこなす。 *セキュリティ負債を測定するための主要な指標を特定する。 *セキュリティ負債が増加または減少している兆候を認識する。 *優先順位に基づく Security Overview データをフィルタリングする。 *セキュリティ監視のスケーリングにおけるベストプラクティスを適用する。 *GitHub Copilot Autofix を活用して、平均修復時間 (MTTR) を大幅に短縮する。

Security Overview へのアクセス

Security Overview に表示される機能は、ご利用の GitHub のプランおよびサブスクリプションによって異なります。

組織で GitHub Enterprise または GitHub Team を使用している場合は、漏洩した秘密情報への露出を評価する Secret Risk Assessment を無料でご利用いただけます。プライベート リポジトリで Security Overview を利用できるようにするには、コード セキュリティまたはシークレット保護のアドオンを購入する必要があります。

Dependabot やシークレット スキャン アラートなどのパブリック リポジトリデータは、プランに関係なく、Security Overview で常にアクセス可能です。ただし、有料のアドオンを 1 つ (たとえばシークレット保護) しか購入していない場合、閲覧できるのは、その機能に関するプライベート リポジトリ データと、無料サービスのパブリック リポジトリ データのみになります。例:

  • __シークレット保護__のプランでは、プライベート リポジトリのシークレット スキャン データは閲覧できますが、パブリック リポジトリ以外のコード スキャン データは閲覧できません。
  • __コード セキュリティ__のプランも同様の動作になりますが、コード スキャンの機能に焦点が置かれます。

この階層化された可視性により、組織のニーズに最適なサービスを優先的に選択することができます。

セキュリティ負債を測定するための主要な指標

Security Overview にアクセスするには、GitHub.com の組織ページに移動し、[セキュリティ] タブをクリックします。[セキュリティ] タブが表示されない場合は、[...] のドロップダウン メニューを選択して [セキュリティ] をクリックします。ここから、組織内の全てのリポジトリの Dependabot、コード スキャン、シークレット スキャンからのアラートを確認できます。

Security Overview は、チームの進捗状況とリスク態勢を簡単に評価できるチャートと指標を提供します。多くの組織は、これらの分析情報を四半期レビュー、コンプライアンス報告、さらには取締役会でのプレゼンテーションにも活用しています。

セキュリティ負債を追跡するために使用できる一般的な指標をいくつか紹介します。

  • 未解決の警告の合計: 未解決の脆弱性の総数です。 *重大度レベル: 重大、高、中、低に分類されたアラートです。 *再開されたアラート: 以前解決されたが再開されたアラートで、ポリシーや教育上のギャップの可能性を示します。これは見過ごされがちな指標です。 *アラートの経過時間: 未解決のアラートの平均経過時間です。全体的な対応時間の変化を追跡できます。 *影響分析表: この表は、未解決のアラートの数が最も多いリポジトリを強調表示して、修復作業の出発点を明確にします。

また、[修復] タブにある指標も監視する必要があります。これらの指標は、以下に挙げる脆弱性への対応におけるチームの有効性に関する詳細情報を提供します。

  • 時系列での解決済みアラート数: チームが指定期間内に解決したアラートの数を追跡し、修復の速度を把握するのに役立ちます。 *平均修復時間 (MTTR): アラートを解決するのにかかる平均時間を測定し、チームが脆弱性に対処する速度を示します。これは、チームの問題解決効率を測る良い指標になります。 *正味解決率: 解決されたアラート数と新規発生したアラート数を比較し、チームが新たに発見される脆弱性に対応できているかどうかを示します。

セキュリティ負債増加の可能性を示す兆候:

  • 正味解決率の低下。これは、新しい脆弱性が、その修復作業を上回っていることを示します。 *重大度が重大または高のアラート件数の増加。 *再開されたアラートの増加。 *アラートの平均経過時間が上昇し、脆弱性の修復が遅れていることを示します。 *平均修復時間の増加。脆弱性の解決に時間がかかることを示します。

以下の場合、セキュリティ負債が減少している可能性があります。

  • 特に重大度の高い問題において、アラートの解決が新しいアラートの発生を上回るトレンドが一貫して見られます。 *正味解決率の向上と平均修復時間の短縮は、チームがセキュリティ負債を効果的に管理し、削減していることを示します。

Security Overview データのフィルタリングとスライス

Security Overview は、データをフィルタリングして分析する柔軟性をもたらし、チームにとって最も関連性の高い情報に集中することができます。

Security Overview のデータをフィルタリングする方法には、次のようなものがあります。

  • 重大度: アラートを重大、高、中、低の重大度でフィルタリングします。 リポジトリの可視性: リポジトリの種類 (公開、非公開、アーカイブなど) に基づいて表示範囲を絞り込みます。 Teams:* 特定のチームによって管理されているリポジトリを識別するには、修飾 team を使用します。 *カスタム プロパティ:* ビジネスユニット、製品、コンプライアンス フレームワークなどのカスタム メタデータでリポジトリをグループ化します。

データをよりよく理解するには、各ツールに固有のフィルターを適用する必要があります。例:

  • Dependabot アラート: 修復の優先順位を効果的に決定するには、現実世界での悪用可能性を予測する EPSS (Exploit Prediction Scoring System) スコアと、脆弱性の重大度を測定する CVSS (Common Vulnerability Scoring System) スコアを組み合わせてください。この 2 つのスコアを併用することで、深刻かつ悪用される可能性の高い脆弱性を迅速に特定し、対処することができます。さらに、Security Overview の並べ替えオプション"最重要"を活用すれば、リポジトリ全体の悪用可能性、重大度、依存関係の使用状況などの要因に基づいて、即座に対応が必要と GitHub が特定するアラートを自動的に表示させることができます。 *シークレット スキャン アラート： 組織にとって最重要のプロバイダー (クラウド サービス、支払いゲートウェイ、ID プロバイダーなど) に関連するシークレットに関するアラートをフィルタリングします。これらの漏洩は直接的に侵害や許可されていないアクセスにつながる可能性があるためです。公に漏れ出てしまった秘密情報には特に注意してください。これらは即座に重大なセキュリティ リスクをもたらすため、悪用を防ぐために早急な修復が必要です。

複数のフィルターを一度に追加して、データを任意の方法で詳細に分析したり切り分けたりできます。たとえば重大度: 重大、可視性: 公開を適用すると、パブリック リポジトリ内の重大なアラートのみ表示することができます。

スケーリングのベスト プラクティス

組織が成長するにつれて、セキュリティ態勢の複雑さも増大します。セキュリティ対策を効果的にスケーリングするには、アラートの監視だけでなく、リポジトリの整理、一貫した慣行の維持、チーム間のワークフローの合理化も必要です。

  • カスタム プロパティ: 一貫した命名規則またはメタデータを使用してリポジトリを論理的にグループ化すれば、関連するリポジトリ間の管理、検索、およびポリシーの適用が容易になります。多くのマイクロサービスやその他の小さなリポジトリを持つ組織では、カスタム プロパティを使用して、マイクロサービスや製品ごとにリポジトリをグループ化することができます。 *フィルタリングしたビューのブックマーク: Security Overview は、フィルターの保存はまだ対応していませんが、フィルターの URL をブックマークに登録することで、フィルターを毎回再適用することなく、お好みのビューにすばやくアクセスできます。 *エクスポートと API オプション: CSV エクスポートまたは REST API を使用すると、フィルタリングしたデータを独自のレポート ツールにプルしたり、ツール間でデータを同期したりして、既存のプロセスに Security Overview のデータを追加できます。 *重要なリポジトリの優先順位付け: セキュリティ キャンペーン機能を使用すると、優先度の高いリポジトリの脆弱性をターゲットして、限られた開発リソースを最大限活用できます。

ブランチはどうなりますか

GitHub は、複数のブランチを以下の方法で処理します:

  • Dependabot: デフォルト ブランチのみをスキャンします。
  • シークレット スキャンとコード スキャン: デフォルト ブランチをスキャンしますが、ブランチ間でアラートの重複を除去し、影響を受ける場所を示す単一のアラートとして表示できます。

長期間維持されるブランチを管理するチームでは、これによってトリアージが簡素化され、重複が削減されて、リスクの明確な伝達が確実になります。

GitHub Copilot Autofix でセキュリティ負債を削減

GitHub Copilot Autofix は、通知機能に留まらず、アラートの詳細な説明を含む脆弱性分析を自動的に生成し、最も重要な点として、開発者が脆弱性を発見次第迅速に修復するための推奨修正策も提案します。Autofix は、CodeQL がサポートする言語およびフレームワークのすべてに対応しています。

経験豊富なセキュリティ人材が不足している場合でも、コード スキャン Autofix を使用すれば、すべての開発者がいつでも必要なときに GitHub Copilot のセキュリティに関する専門知識の恩恵を受けられます。Autofix を使用しているチームでは、脆弱性の修正が平均 60% 迅速化され、平均修正時間 (MTTR) が大幅に短縮されていることがわかっています。

GitHub Copilot Autofix を使用すると、チームはターゲットを絞ったキャンペーンを通じて、長年にわたるセキュリティ負債を解消することができます。GitHub の Security Campaigns 機能は、Autofix を活用して、セキュリティ チームが複数のリポジトリにわたって集中的な修復作業を行うことを可能にしています。Security Campaigns を使用すると、関連する脆弱性をグループ化し、修復の進捗状況を集中管理することができます。Security Campaigns と Autofix を組み合わせることで、組織に蓄積されたセキュリティ負債を体系的かつ効率的に解決することができます。

その仕組みは以下の通りです。　

  • プルリクエストにおいて: 新しい脆弱性が発見されると、GitHub Copilot Autofix が問題の修正に役立つ説明とコード提案を生成します。 *既存のアラートについて: アラートを開いて“修正を生成”ボタンを押します。

GitHub Copilot Autofix は、アラート タイプの約 90% に対して説明とコード提案を提供するため、開発チームとセキュリティ チームは、セキュリティ負債を構成するアラートの大部分に迅速に対処できます。

最後に

GitHub Security Overview は、セキュリティ債務の管理、脆弱性の追跡、そして効果的なリスクの優先順位付けを可能にする包括的なツールです。フィルター、キャンペーン、Autofix のいずれを使用する場合でも、重要なのは組織のセキュリティとコンプライアンス目標に合致する指標とワークフローに焦点を当てることです。

詳細な情報や開始の手順については、GitHub Security Overview のドキュメントをご覧いただくか、カスタマイズされたサポートについては、GitHub フィールド サービスまでお問い合わせください。

Tags