組織全体のセキュリティを効率化
1. はじめに
組織が成長するにつれて、セキュリティ管理の複雑さは指数関数的に増加します。数十、数百のリポジトリに対して、それぞれ個別にセキュリティ設定を行うのは現実的ではありません。GitHubは、この課題に対する包括的なソリューションとして「Security Configurations」を提供しています。
本記事では、GitHubの組織レベルセキュリティ機能の全体像と、実際の運用における具体的な活用方法を解説します。
2. Security Configurationsとは何か
Security Configurationsは、GitHubのセキュリティ機能の有効化設定を一元管理するための仕組みです。組織内の任意のリポジトリに適用できる設定のコレクションとして機能します。
2.1 2つのタイプ
GitHub推奨構成の特徴:
- GitHubのセキュリティ専門家が作成・管理
- 最速で全リポジトリに展開可能
- 低インパクト・高インパクト両方のリポジトリを効果的に保護
カスタム構成の特徴:
- 機能ごとに有効化設定を編集可能
- 異なるセキュリティニーズを持つリポジトリごとに構成を作成
- コストと利用状況を制御可能
3. 主要セキュリティ製品の理解
GitHubは3つの主要なセキュリティ製品を提供しています。
3.1 GitHub Secret Protection
シークレット（APIキー、トークン、パスワードなど）の漏洩を検出・防止するための機能群です。
主要機能:
| 機能 | 説明 |
|---|---|
| Secret Scanning | リポジトリの全Git履歴、Issue、PR、Discussion、Wikiをスキャン |
| Push Protection | シークレットを含むコミットをブロック |
| Validity Checks | パートナーパターンの有効性を検証 |
| Non-provider Patterns | 一般的なシークレット形式を検出 |
| Generic Password Scanning | Copilotによる汎用パスワード検出 |
| Custom Patterns | 組織固有のシークレットパターンを定義 |
3.2 GitHub Code Security
コードの脆弱性を発見・修正するための機能群です。
主要機能:
| 機能 | 説明 |
|---|---|
| Code Scanning | コードの脆弱性とエラーを分析 |
| Copilot Autofix | 自動修正提案の生成 |
| Dependency Graph | 依存関係の可視化 |
| Dependabot Alerts | 依存関係の脆弱性を通知 |
| Dependabot Security Updates | 脆弱性のある依存関係を自動更新 |
| Dependency Review | PRでの依存関係レビュー |
3.3 GitHub Advanced Security
上記2製品を統合した従来の製品です。
4. セキュリティ構成の作成と適用
4.1 GitHub推奨構成の適用
最もシンプルな開始方法は、GitHub推奨構成を全リポジトリに適用することです。
適用手順:
- 組織のSettingsタブを開く
- Security > Advanced Security > Configurationsを選択
- 「GitHub recommended」行のApply toドロップダウンメニューを選択
- 「All repositories」または「All repositories without configurations」を選択
- ライセンス消費の詳細を確認
- Applyをクリック
4.2 カスタム構成の作成
より細かい制御が必要な場合は、カスタム構成を作成します。
基本的なワークフロー:
設定例（Secret Protection）:
name: "高セキュリティ構成"
description: "本番環境リポジトリ向けの厳格なセキュリティ設定"
secret_protection:
enabled: true
validity_checks: enabled
non_provider_patterns: enabled
generic_passwords: enabled
push_protection: enabled
bypass_privileges:
# バイパス権限を持つチームを指定
- team: "セキュリティチーム"
- team: "シニアエンジニア"
prevent_alert_dismissals: enabled
code_security:
enabled: true
code_scanning:
default_setup: enabled
runner_type: "GitHub-hosted"
query_suite: "extended"
dependency_scanning:
dependency_graph: enabled
dependabot_alerts: enabled
security_updates: enabled
policy:
default_for_new_repos: "private_and_internal"
enforce: true
4.3 リポジトリへの適用
カスタム構成を作成したら、対象リポジトリに適用します。
フィルタリング機能:
リポジトリテーブルでは、様々な条件でフィルタリングが可能です。
便利なフィルタ例:
-
visibility:public- パブリックリポジトリのみ -
language:python- Python言語のリポジトリ -
props.Environment:production- カスタムプロパティで本番環境指定 -
config-status:failed- 構成適用に失敗したリポジトリ
5. グローバル設定によるカスタマイズ
Security Configurationsがリポジトリレベルの設定を管理するのに対し、グローバル設定は組織レベルの動作をカスタマイズします。
5.1 Dependabotのグローバル設定
自動トリアージルール:
Dependabotアラートを自動的に却下、スヌーズ、またはPRを作成するルールを設定できます。
ランナータイプの設定:
# Dependabotのself-hosted runnerを設定する例
dependabot:
runner_type: "labeled"
runner_label: "dependabot-runner"
runner_group: "production-runners" # オプション
5.2 Code Scanningのグローバル設定
Copilot Autofix:
組織全体でCopilot Autofixを有効化できます。これにより、CodeQLのdefault setupまたはadvanced setupを使用する全リポジトリで自動修正提案が生成されます。
Extended Query Suite:
デフォルトでは「Default」クエリスイートが実行されますが、「Extended」クエリスイートを推奨することもできます。
5.3 Secret Scanningのグローバル設定
ブロックされたコミットのリソースリンク:
開発者がコミットをブロックされた際に、なぜブロックされたかの詳細情報へのリンクを表示できます。
# 設定例
secret_scanning:
blocked_commit_resource_link: "https://wiki.example.com/security/secret-leak-prevention"
カスタムパターンの定義:
正規表現を使用して組織固有のシークレットパターンを定義できます。
# 社内APIキーのパターン例
[Cc][Oo][Mm][Pp][Aa][Nn][Yy]_[Aa][Pp][Ii]_[Kk][Ee][Yy]_[0-9a-fA-F]{32}
Push Protectionパターンの制御:
エンタープライズおよび組織レベルで、どのシークレットパターンをPush Protectionに含めるかを制御できます。
| 項目 | 説明 |
|---|---|
| Name | パターンまたはシークレットの名前 |
| Alert total | パターンのアラート総数（割合と絶対数） |
| False positives | 偽陽性の割合 |
| Bypass rate | バイパスの割合 |
| GitHub default | GitHubが推奨するデフォルト動作 |
| Organization setting | 組織での現在の有効化状態 |
6. プライベートレジストリへのアクセス設定
組織がプライベートレジストリを使用している場合、Code ScanningとDependabotにアクセス権を付与することで、コード分析の精度が向上します。
6.1 Code Scanning Default Setupの場合
設定後の再有効化:
プライベートレジストリを初めて設定する場合、既存のリポジトリでCode Scanning default setupを無効化してから再度有効化する必要があります。
6.2 Dependabotの場合
Dependabotは組織レベルのプライベートレジストリと、リポジトリのdependabot.ymlファイルで定義されたプライベートレジストリの両方を使用できます。
7. シークレット漏洩リスクの評価
7.1 Secret Risk Assessmentの実行
組織のシークレット漏洩状況を無料で評価できます。
レポートの解釈:
- Total secrets - 組織全体で検出されたシークレット総数
- Public leaks - パブリックリポジトリで発見された個別シークレット
- Preventable leaks - Push Protectionで防げたはずの漏洩
- Private leaks - Total secrets - Public leaksで計算
優先順位付け:
7.2 CSV エクスポート
詳細な分析のため、レポートをCSV形式でエクスポートできます。
CSV構造:
| 列 | 項目名 | 説明 |
|---|---|---|
| A | Organization Name | シークレットが検出された組織名 |
| B | Name | シークレットのトークン名 |
| C | Slug | トークンの正規化文字列 |
| D | Push Protected | Push Protectionで検出・ブロック可能か |
| E | Non-Provider Pattern | 非プロバイダーパターンに一致するか |
| F | Secret Count | アクティブ・非アクティブのシークレット集計 |
| G | Repository Count | シークレットが見つかったリポジトリ数 |
7.3 ROI計算ツール
Push Protectionの費用対効果を試算できます。
計算式:
潜在的節約額 = (防止されたシークレット数) × (修復時間) × (時給)
時給 = 年間給与 ÷ 2080
入力パラメータ:
- Preventable leaks (P) - 防止可能な漏洩数（自動表示）
- Average developer annual compensation (C) - 開発者の平均年間報酬（USD）
- Time to remediate (T) - 1シークレットあたりの修復時間（時間）
修復時間の目安:
| シナリオ | 推奨時間 |
|---|---|
| シンプルなローテーション | 1-1.5時間 |
| 分散チームでの対応 | 2-3時間 |
| 規制・監査環境 | 3-4時間 |
8. 脆弱性への露出管理
8.1 Dependabotメトリクスによる優先順位付け
推奨されるワークフロー:
-
Critical/High重大度のアラートに焦点
severity:critical OR severity:high -
悪用可能性の評価（EPSS）
epss_percentage>=0.10 -
Direct dependenciesを優先
relationship:direct -
Runtime dependenciesに注力
scope:runtime -
古いアラートのレビュー
- 「Older」ソートオプションを使用
8.2 本番環境コンテキストの活用
本番環境に実際にデプロイされている成果物のアラートに焦点を当てることで、実際のリスクに対処できます。
JFrog Artifactoryの統合例:
JFrog Artifactoryを使用している場合、カスタム統合は不要です。Artifactory設定で統合を有効化するだけで、自動的にStorage Record APIにイベントが送信されます。
フィルタの組み合わせ例:
epss > 0.5 AND artifact-registry-url:my-registry.example.com
has:deployment AND runtime-risk:internet-exposed
9. セキュリティキャンペーンによる大規模修正
9.1 キャンペーンの概要
セキュリティキャンペーンは、アラートをグループ化し、開発者と協力して脆弱性を修正するための機能です。
制限事項:
- アクティブキャンペーン：最大10件
- 1キャンペーンあたり：最大1,000アラート
- クローズされたキャンペーンには制限なし
9.2 キャンペーンの作成
便利なフィルタ例:
コードスキャニング用:
# ログインジェクション（Java）
is:open autofilter:true autofix:supported rule:java/log-injection
# CWE-117（ログの不適切な無害化）
is:open autofilter:true autofix:supported tag:external/cwe/cwe-117
# Critical重大度
is:open autofilter:true autofix:supported severity:critical
シークレットスキャニング用:
# Azureプロバイダー
is:open provider:azure
# 特定のシークレットタイプ
is:open secret-type:azure_ai_services_key,azure_cognitive_services_key
# カスタムプロパティでフィルタ
is:open props.BusinessPriority:Urgent
9.3 ベストプラクティス
9.3.1 関連アラートのグループ化
同じタイプの脆弱性をグループ化することで、開発者は1つのアラートを修正する過程で得た知識を他の修正に活用できます。
9.3.2 教育コンテンツの提供
campaign:
name: "XSS脆弱性修正キャンペーン"
description: |
このキャンペーンでは、クロスサイトスクリプティング（XSS）脆弱性を修正します。
# 参考資料
- OWASPガイド
- 修正例集
- テスト方法
resources:
training_session: "2025年1月15日 14:00-15:00"
office_hours: "毎週火曜日 13:00-14:00"
9.3.3 キャンペーンマネージャーの選定
キャンペーンマネージャーは以下の条件を満たす必要があります：
- 組織オーナーまたはセキュリティマネージャーの役割を持つユーザー
- または、これらの役割を持つチームのメンバー
役割:
- 開発者からの質問対応
- 難しい修正への協力
- PRのレビュー
- 進捗の監視
9.3.4 自動issue作成の活用
キャンペーン作成時に自動issue作成を有効化すると、各リポジトリにトラッキングissueが作成されます。
メリット:
- プロジェクトボードでの作業管理
- チームへのアサイン
- キャンペーン詳細の自動更新
- 期限到達時の自動コメント
9.3.5 現実的な期限設定
9.4 キャンペーンのトラッキング
組織全体のビュー:
個別キャンペーンのトラッキング:
| メトリクス | 説明 |
|---|---|
| Campaign progress | クローズ済み（修正または却下）、進行中、レビュー待ち |
| Status | 期限までの残り日数 |
| Copilot Autofix | 自動修正が生成可能なアラート数 |
リポジトリレベルの詳細:
各リポジトリを展開すると、以下の情報が表示されます：
- リポジトリ内のアラート数
- 各アラートのステータス
- アサインされた担当者
- 進行中のブランチやPR
9.5 アラートのアサインとCopilot Coding Agent
アサイン可能な対象:
- リポジトリへの書き込み権限を持つユーザー
- シークレットスキャンの場合、アラートリスト表示権限があれば一時的に権限昇格
Copilot Coding Agentへのアサイン:
Autofixが生成されているアラートは、Copilot coding agentにアサインできます。
10. ライセンスとコスト管理
10.1 ライセンス要件
ライセンス消費の理解:
- 組織のSettings > Security > Advanced Security > Configurationsを開く
- 「Apply configurations」セクションで現在の使用状況を確認
- メータリング課金：現在の使用量
- ボリューム/サブスクリプション：利用可能ライセンス数
10.2 Secret Protectionの価格見積もり
価格計算ツールの使用:
計算のポイント:
- アクティブコミッター：過去90日間のコミッター数
- 2つのリポジトリが同じコミッターを共有する場合、2つ目は追加コスト0
- 実際の課金は課金期間中のアクティブコミッター数に基づく
10.3 コスト削減のためのライセンス管理
Secret ProtectionまたはCode Securityを無効化する必要がある場合：
カスタム構成の作成:
name: "Secret Protection & Supply chain のみ"
description: "Code Securityを含まない構成"
secret_protection:
enabled: true
# Secret Protection設定
code_security:
enabled: false # Code Securityを無効化
dependency_scanning:
dependency_graph: enabled
dependabot_alerts: enabled
# Dependabotは引き続き利用可能
対象リポジトリに適用:
ライセンスを解放したいリポジトリにこの構成を適用します。
11. トラブルシューティング
11.1 構成適用の失敗
11.2 Advanced Setup競合の解決
問題:
Code Scanning default setupを有効にした構成を、Advanced setupを使用しているリポジトリに適用しようとしている。
Advanced setupが有効と見なされる条件:
- 最新のCodeQL分析が90日以内
- CodeQL設定が存在
- ワークフローファイルが存在し有効
解決方法:
オプション1: GitHub Enterprise Server 3.19以降
code_security:
code_scanning:
default_setup: "enabled_with_advanced_setup_allowed"
# Advanced setupが有効な場合、そのまま維持
# 無効または90日以上更新なしの場合、default setupを有効化
オプション2: Default setupへの移行
リポジトリレベルで：
- Settings > Code security and analysis
- Code scanning > Configure
- Default setupを選択
オプション3: 専用構成の作成
Advanced setupを使用するリポジトリ用に、Code Scanningを含まない構成を作成します。
11.3 Default SetupによるAdvanced Setupの上書き
問題:
「Enabled with advanced setup allowed」を適用したが、一部のリポジトリでAdvanced setupが無効化された。
原因:
Advanced setupが非アクティブと判定された（90日以上分析なし、設定削除など）。
解決策:
定期的な分析の実行:
# .github/workflows/codeql-analysis.yml
on:
schedule:
- cron: '0 0 1 * *' # 毎月1日に実行
構成の再適用:
すべての対象リポジトリで分析が実行されたことを確認後、構成を再適用します。
11.4 ライセンス不足エラー
問題:
プライベートリポジトリにGHAS機能を有効化しようとしたが、ライセンスが不足している。
影響:
- パブリックリポジトリ：正常に適用
- プライベートリポジトリ：無料機能のみ適用、構成は未アタッチ
確認方法:
12. 実践的なワークフロー例
12.1 ケーススタディ1: 新しい組織のセキュリティ設定
シナリオ:
100個のリポジトリを持つ組織で、初めてセキュリティ機能を有効化する。
ステップ:
12.2 ケーススタディ2: XSS脆弱性修正キャンペーン
シナリオ:
150個のXSS（クロスサイトスクリプティング）アラートを3ヶ月で修正する。
実装:
準備フェーズ（1週目）
# 教育コンテンツの作成
resources:
- title: "XSS基礎ガイド"
type: "documentation"
- title: "修正例集"
type: "examples"
- title: "トレーニングセッション録画"
type: "video"
キャンペーン作成（2週目）
# フィルタ設定
is:open autofilter:true autofix:supported tag:external/cwe/cwe-79
# キャンペーン設定
name: "XSS脆弱性修正キャンペーン 2025 Q1"
due_date: "2025-03-31"
managers:
- user: "yamada_taro"
- team: "セキュリティチーム"
contact: "https://github.com/orgs/example/discussions/123"
create_issues: true
実行フェーズ（3-12週目）
週次チェックリスト:
- 進捗レビュー（トラッキングページで確認）
- 停滞しているリポジトリの特定
- 開発者へのフォローアップ
- PRレビューと承認
- 週次レポート作成
完了フェーズ（13週目）
12.3 ケーススタディ3: 段階的なSecret Protection展開
シナリオ:
500個のリポジトリを持つ大規模組織で、段階的にSecret Protectionを展開する。
フェーズ1: パイロット（1ヶ月）
target:
repositories: 10
criteria:
- "アクティブに開発中"
- "セキュリティ意識の高いチーム"
- "代表的な技術スタック"
configuration:
secret_protection:
enabled: true
push_protection: enabled
bypass_privileges:
- team: "シニアエンジニア"
フェーズ2: 拡大展開（2-3ヶ月）
フェーズ3: 全体展開（4-6ヶ月）
rollout_schedule:
week_1_2:
target: "本番環境関連リポジトリ（残り）"
count: 100
week_3_4:
target: "マイクロサービス群"
count: 150
week_5_8:
target: "フロントエンドアプリケーション"
count: 120
week_9_12:
target: "その他全リポジトリ"
count: 100
13. まとめ
GitHubのSecurity Configurationsは、組織レベルでのセキュリティ管理を劇的に効率化します。
重要なポイント:
13.1 段階的なアプローチ
- GitHub推奨構成から開始
- メトリクスを収集・分析
- ニーズに応じてカスタマイズ
13.2 データドリブンな意思決定
- Secret Risk Assessmentで現状把握
- Dependabotメトリクスで優先順位付け
- 本番環境コンテキストで実リスクに焦点
13.3 開発者との協力
- セキュリティキャンペーンで明確な目標設定
- 教育コンテンツの提供
- Copilot Autofixで修正を支援
13.4 継続的な改善
- 定期的なレビューと調整
- グローバル設定の最適化
- フィードバックループの確立
これらの機能を活用することで、組織全体のセキュリティ態勢を持続的に向上させることができます。まずはSecret Risk Assessmentから始めて、自組織の現状を把握することをお勧めします。