組織全体のセキュリティを可視化
1. はじめに
組織内に複数のリポジトリが存在すると、セキュリティアラートの管理が煩雑になります。各リポジトリを個別に確認し、どこに優先的に対応すべき脆弱性があるのかを把握するのは困難です。
GitHub Security Overviewは、この課題を解決するための統合ダッシュボードです。組織やエンタープライズ全体のセキュリティ状況を一元的に可視化し、データに基づいた意思決定を可能にします。
本記事では、Security Overviewの機能を体系的に解説し、実務での活用方法を紹介します。
2. 利用可能な対象
Security Overviewは以下のアカウントで利用できます。
- GitHub Teamアカウント(GitHub Secret ProtectionまたはGitHub Code Securityを購入)
- GitHub Enterpriseアカウント
無料のSecret Risk Assessmentは、すべてのGitHub Teamアカウントで利用可能です。
3. アクセス権限
Security Overviewへのアクセスには、以下のいずれかの権限が必要です。
組織レベル
- 組織のオーナー
- セキュリティマネージャー
- リポジトリへのwrite以上のアクセス権を持つメンバー(制限あり)
エンタープライズレベル
- 組織のオーナーまたはセキュリティマネージャー
アクセス権限に応じて、表示されるデータの範囲が変わります。
4. 主要なビューの概要
Security Overviewは、目的に応じて複数のビューを提供しています。
それぞれのビューについて、詳しく見ていきましょう。
5. Overview(概要ダッシュボード)
Overviewダッシュボードは、組織のセキュリティ状況を俯瞰するための中心的なビューです。3つのタブで構成されています。
5.1. Detection(検出)タブ
検出タブでは、現在のアラート状態を把握できます。
主要なメトリクス
-
Open alerts over time(時系列のオープンアラート数)
- 選択した期間におけるオープンアラートの推移
- デフォルトでは深刻度別にグループ化
- 新規アラートと既存アラートを区別して表示
-
Age of alerts(アラートの経過時間)
- 期間終了時点でオープンなアラートの平均経過日数
- 再オープンされたアラートは元の作成日から計算
-
Reopened alerts(再オープンされたアラート数)
- 選択期間中に再オープンされ、期間終了時点でオープンなアラート数
-
Secrets bypassed or blocked(バイパス/ブロックされたシークレット)
- Push protectionでブロックされたシークレットに対するバイパス率
- 成功したブロック数も表示
Impact Analysis Table(影響分析テーブル)
3つのタブで構成されています。
-
Repositories(リポジトリ)
- オープンアラート数が最も多い上位10リポジトリ
- 深刻度別の内訳を表示
-
Advisories(アドバイザリ)
- 最も多くのDependabotアラートを引き起こしたCVE上位10件
- 深刻度評価を含む
-
SAST vulnerabilities(SAST脆弱性)
- 最も多くのCode scanningアラートを引き起こした脆弱性上位10件
- 深刻度評価を含む
5.2. Remediation(修復)タブ
修復タブでは、アラートの解決状況を追跡できます。
主要なメトリクス
-
Closed alerts over time(時系列のクローズアラート数)
- 選択期間における修復済みまたは却下されたアラート数の推移
- 期間前にクローズされたアラートも期間開始時点で表示
-
Mean time to remediate(平均修復時間)
- 選択期間中にクローズされたアラートの平均経過日数
- False positiveは除外
-
Net resolve rate(正味解決率)
- アラートがクローズされる速度を測定
- 計算式: クローズされたまま維持されたアラート数 ÷ 新規作成アラート数
-
Alert activity graph(アラート活動グラフ)
- 緑: 新規作成アラート数
- 紫: クローズされたアラート数
- 青点線: 正味アラート活動(新規 - クローズ)
5.3. Prevention(予防)タブ
予防タブでは、開発ワークフロー内での脆弱性検出状況を確認できます。
注意: このタブは、デフォルトブランチのアラートではなく、マージされたプルリクエスト内のCodeQLアラートに関する情報を提供します。
主要なメトリクス
-
Introduced versus prevented(導入vs予防)
- 予防された脆弱性: プルリクエストで検出され、修正された後にマージされたアラート
- 導入された脆弱性: 「Risk accepted」として却下、または未解決のままマージされたアラート
-
Vulnerabilities fixed in pull requests(プルリクエストで修正された脆弱性)
- マージされたプルリクエストで「Fixed」としてクローズされたアラート数
-
Pull request alerts fixed with Copilot Autofix suggestions(Copilot Autofixで修正されたアラート)
- Copilot Autofix提案の受諾率
- Code scanningアラートに対する比率
6. Risk(リスクビュー)
Riskビューは、現在のセキュリティリスクを評価するためのビューです。
6.1. 機能
-
Repository-level risk assessment(リポジトリレベルのリスク評価)
- すべてのアラートタイプを横断的に表示
- 深刻度、影響度別に分類
-
Filtering options(フィルタリングオプション)
- 「NUMBER affected」または「NUMBER unaffected」をクリックして、該当するリポジトリのみを表示
- アラートの種類やカテゴリーで絞り込み(例: 「1 critical」をクリックしてcriticalなDependabotアラートのみ表示)
6.2. 使用例
最も危険な脆弱性を特定し、優先的に対処すべきリポジトリを把握できます。
# フィルタリング例
severity: "critical,high"
has: "patch"
epss_percentage: ">=0.01"
7. Coverage(カバレッジビュー)
Coverageビューは、セキュリティ機能の有効化状況を確認するためのビューです。
7.1. 機能
-
Feature enablement tracking(機能有効化の追跡)
- Code scanning、Dependabot、Secret scanningの有効化状況
- リポジトリごとの詳細情報
-
Team-based filtering(チームベースのフィルタリング)
- 特定のチームが所有するリポジトリのみを表示
7.2. 活用方法
すべてのリポジトリでSecret scanningとPush protectionを有効にするなど、組織全体のセキュリティポリシーを実装する際に役立ちます。
Enablement Trendsビューも利用可能で、時系列での有効化状況の推移をグラフと詳細テーブルで確認できます。
8. Alerts(アラートビュー)
各セキュリティ機能専用のアラートビューが用意されています。
8.1. Code Scanning Alerts
フィルタオプション
-
is: オープン/クローズ状態 -
resolution: クローズ理由(false-positive、fixed、used-in-tests、wont-fix) -
rule: 特定のルールで検出されたアラート -
severity: 深刻度(critical、high、medium、low) -
tool: 検出ツール(CodeQL、サードパーティツールなど)
8.2. Dependabot Alerts
フィルタオプション
-
ecosystem: パッケージエコシステム(Maven、npmなど) -
epss_percentage: EPSSスコア(例:>=0.01) -
has: パッチの有無(patch)、脆弱な関数呼び出しの検出(vulnerable-calls) -
package: 特定のパッケージ -
scope: development依存関係またはruntime依存関係 -
severity: 深刻度
8.3. Secret Scanning Alerts
フィルタオプション
-
bypassed: Push protectionのバイパス状況 -
provider: シークレット発行者(例: adafruit) -
secret-type: シークレットのタイプ -
validity: 有効性(active、inactive、unknown) -
results: デフォルトまたはジェネリックアラート
9. Metrics(メトリクスビュー)
より詳細な分析のための専門的なメトリクスビューです。
9.1. Dependabot Dashboard
脆弱性の優先順位付けと修復追跡のための統合ダッシュボードです。
主要機能
-
Vulnerability Prioritization Funnel(脆弱性優先順位付けファネル)
- デフォルトの順序:
has:patch→severity:critical,high→epss_percentage>=0.01 - ファネルの順序はカスタマイズ可能
- デフォルトの順序:
-
Alerts closed(クローズされたアラート)
- Dependabotによる自動修正
- 手動での却下
- 自動却下
- 過去30日間の増加率も表示
-
Most vulnerabilities(最も多くの脆弱性を持つパッケージ)
- 組織内で最も脆弱性が多い依存関係
- 関連アラートへのリンク
-
Repository-level breakdown(リポジトリレベルの内訳)
- 深刻度別のオープンアラート数
- 悪用可能性(例: EPSS > 1%)
- 各列でソート可能
ファネルのカスタマイズ
組織のニーズに合わせて、優先順位付けの基準を調整できます。
9.2. CodeQL Pull Request Alerts
プルリクエストにおけるCodeQLのパフォーマンスを評価します。
メトリクス
- マージされたプルリクエストで検出・修正された脆弱性の総数
- Copilot Autofixによる修正数
- 未解決のままマージされたアラート数
- False positiveまたはRisk acceptedとして却下されたアラート数
詳細グラフ
- 最も多くのアラートを引き起こしているルール
- Copilot Autofixの有無による修復率の比較
- Copilot Autofixの有無による平均修復時間の比較
9.3. Secret Scanning Push Protection Metrics
Push protectionの効果を測定します。
メトリクス
- ブロックされたプッシュ数
- バイパスされた回数
- 最もブロック/バイパスされたシークレットタイプ
- 最もブロックが多いリポジトリ
- 最もバイパスが多いリポジトリ
- バイパス理由の分布
10. Filtering(フィルタリング)
Security Overviewの強力な機能の一つが、柔軟なフィルタリングシステムです。
10.1. フィルタ論理
論理演算子
-
ANDロジック(デフォルト): 複数のフィルタを適用すると、すべての条件を満たす結果のみ表示
- 例:
is:public dependabot:enabled→ publicかつDependabotが有効なリポジトリ
- 例:
-
NOTロジック(
-演算子): 特定の条件を除外- 例:
-repo:test-repo→ test-repo以外のすべてのリポジトリ
- 例:
-
ORロジック(
,演算子): いずれかの条件を満たす結果を表示- 例:
is:public,private→ publicまたはprivateなリポジトリ - 例:
severity:critical,high→ criticalまたはhighの深刻度
- 例:
10.2. フィルタ方法
-
Interactive search box(対話型検索ボックス)
- 検索ボックスをクリックしてスペースキーを押すと、利用可能なフィルタオプションが表示される
- マウスまたはキーボードで選択
-
Dropdown selectors(ドロップダウンセレクタ)
- 検索ボックスの末尾またはデータテーブルのヘッダーに配置
- 選択すると検索ボックスのフィルタが自動更新
-
Advanced filters dialog(高度なフィルタダイアログ)
- Filterボタンをクリック
- Qualifier、Operator、Valuesをドロップダウンリストから選択
10.3. 主要なフィルタ
リポジトリフィルタ
# リポジトリ名
repo: "リポジトリ名"
# 可視性
visibility: "public,private,internal"
is: "public,private,internal"
# アーカイブ状態
archived: "true,false"
チームとトピックフィルタ
# チーム
team: "チーム名"
# トピック
topic: "トピック名"
カスタムプロパティフィルタ
# カスタムプロパティ(例: データ機密性)
props.data_sensitivity: "high"
セキュリティ機能有効化フィルタ
# Code scanning
code-scanning-alerts: "enabled,not-enabled"
# Dependabot
dependabot-alerts: "enabled,not-enabled"
# Secret scanning
secret-scanning-alerts: "enabled,not-enabled"
# いずれかの機能
any-feature: "enabled"
アラート数フィルタ
# Code scanning(100件以上)
code-scanning-alerts: ">100"
# Dependabot(10件以下)
dependabot-alerts: "<=10"
# Secret scanning(ちょうど10件)
secret-scanning-alerts: "=10"
Production Contextフィルタ
# Artifact registry
artifact-registry: "jfrog-artifactory"
artifact-registry-url: "my-registry.example.com"
# デプロイメント
has: "deployment"
# ランタイムリスク
runtime-risk: "internet-exposed"
11. Requests(リクエストビュー)
委譲された承認プロセスを管理するためのビューです。
11.1. Push Protection Bypass Requests
概要
組織が委譲されたバイパスを設定している場合、指定されたレビュワーがバイパスリクエストを承認または拒否します。
ステータス
| ステータス | 説明 |
|---|---|
| Approved | 承認済みだが、まだコミットがプッシュされていない |
| Cancelled | 貢献者によってキャンセルされた |
| Completed | 承認されてコミットがプッシュされた、または拒否された |
| Denied | レビューされて拒否された |
| Expired | 期限切れ(リクエストは7日間有効) |
| Open | 未レビュー |
レビュープロセス
- Security → Requests → Push protection bypassに移動
- レビューしたいリクエストをクリック
- リクエストの詳細を確認
- コメントを追加(オプション)
- 「Approve bypass request」または「Deny bypass request」をクリック
11.2. Alert Dismissal Requests
前提条件
委譲されたアラート却下を有効にする必要があります。
- Code scanningの委譲された却下
- Secret scanningの委譲された却下
- Dependabotの委譲された却下
レビュープロセス
- Security → Requests → 該当する却下リクエストビューに移動
- フィルタを使用してリクエストを絞り込み(オプション)
- レビューしたいリクエストをクリック
- アラートの内容と却下理由を確認
- アラートタイムラインの「Review request」をクリック
- コメントを入力し、「Deny request」または「Approve request」を選択
- 「Submit review」をクリック
12. Data Export(データエクスポート)
Security Overviewのデータは、CSV形式でエクスポートできます。
12.1. エクスポート可能なデータ
- Overview dashboard
- Risk view
- Coverage view
- CodeQL pull request alerts
12.2. エクスポート方法
- 該当するビューに移動
- フィルタを適用(エクスポートデータに反映される)
- 「Export CSV」ボタンをクリック
- CSVファイルが自動的にダウンロード開始
注意事項
- Teamsカラムには、write以上のアクセス権を持つ最大20チームまで記載
- 20チーム以上の場合はデータが切り捨てられる
12.3. 活用例
エクスポートしたデータは以下の用途に使用できます。
- セキュリティ研究
- 詳細なデータ分析
- 外部データセットとの統合
- コンプライアンスレポート作成
13. 実践的な活用シナリオ
13.1. シナリオ1: 緊急対応が必要な脆弱性の特定
# 以下のフィルタを組み合わせる
severity: "critical,high"
has: "patch"
epss_percentage: ">=0.01"
このフィルタで、以下の条件をすべて満たすアラートを抽出できます。
- 深刻度がcriticalまたはhigh
- パッチが利用可能
- 悪用可能性が1%以上
13.2. シナリオ2: セキュリティ機能の展開状況確認
Coverageビューで以下を確認します。
- Secret scanningが有効化されていないリポジトリを特定
- 「NUMBER not enabled」をクリック
- チームごとにフィルタリング
- 各チームと有効化計画について協議
13.3. シナリオ3: 修復パフォーマンスの測定
Overviewダッシュボードの Remediationタブで以下を確認します。
- Mean time to remediate(平均修復時間)のトレンド
- Net resolve rate(正味解決率)の推移
- 期間を変えて比較し、改善を測定
13.4. シナリオ4: Dependabot Dashboardでの優先順位付け
ファネルを使用することで、1500件のアラートから優先的に対応すべき80件を効率的に特定できます。
14. ベストプラクティス
14.1. 定期的なレビュー
週次または隔週でSecurity Overviewを確認し、以下を実施します。
- 新規アラートの確認
- 長期間オープンなアラートの特定
- 修復の進捗確認
14.2. フィルタの保存と共有
よく使用するフィルタをドキュメント化し、チーム内で共有します。
14.3. データ駆動の意思決定
メトリクスを活用して、以下の判断を行います。
- リソースの配分
- セキュリティポリシーの改善
- ツールの導入判断
14.4. 段階的な展開
新しいセキュリティ機能を導入する際は、以下の手順を推奨します。
- パイロットチームで試験運用
- Coverageビューで有効化状況を確認
- フィードバックを収集
- 組織全体に展開
14.5. アラート疲労の回避
False positiveやノイズを減らすために、以下を実施します。
- カスタムルールの調整
- 除外パスの設定
- 委譲された却下プロセスの活用
15. 制限事項と注意点
15.1. データの一貫性
Overview、Coverage、Riskビューは、以下を除外します。
- サードパーティツールによるCode scanningアラート
- 非プロバイダパターンのSecret scanningアラート
- 無視されたディレクトリのSecret scanningアラート
そのため、個別のアラートビューの方が、より多くのアラートを表示する場合があります。
15.2. パフォーマンス
組織メンバーの場合、組織レベルのSecurity Overviewページは、最新の3,000リポジトリのみを表示します。組織オーナーとセキュリティマネージャーはすべてのリポジトリを表示できます。
15.3. データの時系列性
Overviewページのデータは、時間経過により変化する可能性があります。
- リポジトリの削除
- セキュリティアドバイザリの変更
- アーカイブ状態でフィルタする場合、現在の状態が反映される
コンプライアンスレポートなど、データの一貫性が重要な場合は、監査ログを使用することを推奨します。
16. まとめ
GitHub Security Overviewは、組織全体のセキュリティ状況を可視化し、データに基づいた意思決定を可能にする強力なツールです。
主要な利点
- 複数のリポジトリを横断したセキュリティリスクの把握
- 優先順位付けによる効率的な脆弱性対応
- メトリクスによる改善の測定
- チーム間のコラボレーション促進
効果的な活用のために
- 各ビューの特性を理解する
- フィルタリング機能を使いこなす
- 定期的なレビューを習慣化する
- データエクスポートで詳細分析を実施
Security Overviewを活用することで、組織のセキュリティ成熟度を継続的に向上させることができます。まずは自分の組織でOverviewダッシュボードを開き、現在のセキュリティ状況を確認してみてください。