GitHub Advanced Security trial from a risk assessmentは、GitHubのセキュリティ機能を試したい企業管理者にとって、評価開始までの手順を短縮する更新です。結論からいうと、対象となるEnterprise管理者は、Secret ProtectionまたはCode Securityのリスク評価画面から、そのままGitHub Advanced Securityのトライアルを開始できるようになりました。これは検出機能そのものの大幅変更というより、リスク確認から導入判断までの動線を改善するアップデートです。(The GitHub Blog)
2026年5月19日のGitHub公式Changelogでは、対象となるEnterprise管理者が、Secret ProtectionまたはCode Securityのrisk assessmentからGitHub Advanced Security trialを直接開始できるようになったと案内されています。セルフサーブトライアルの対象外でも、リスク評価画面からSecret ProtectionやCode Securityを有効化するか、GitHubへ相談できる導線は用意されています。(The GitHub Blog)
GitHub Advanced Security trial from a risk assessmentの変更点
今回の変更で重要なのは、「リスクを見てから、すぐ試す」流れがGitHub上でつながった点です。
従来は、リスク評価でシークレット漏えいや脆弱性の状況を確認した後、GitHub Advanced Securityのトライアル開始やライセンス確認に別の画面・手続きへ移る必要がありました。今回の更新により、Secret ProtectionまたはCode Securityのリスク評価を見たEnterprise管理者が、その文脈のままトライアル開始に進めます。
| 項目 | これまで | 変更後 |
|---|---|---|
| トライアル開始の動線 | BillingやLicensingなど別画面で確認する流れが中心 | リスク評価画面から直接トライアル開始が可能 |
| 判断材料 | 機能説明やライセンス情報を見て判断 | 実際のリスク評価結果を見て判断しやすい |
| 対象 | 条件を満たすEnterprise管理者 | 条件を満たすEnterprise管理者 |
| 対象外の場合 | 別途有効化や営業相談が必要 | リスク評価画面から機能有効化またはGitHub相談へ進める |
この変更は、セキュリティ担当者にとっては特に実用的です。たとえば「どのリポジトリにシークレット漏えいリスクがあるのか」「Code Securityを試す価値があるほど脆弱性リスクが見えているのか」を確認した直後に、トライアルへ進めます。稟議やPoCの説明でも、「なんとなく試す」ではなく「評価結果に基づいて試す」と説明しやすくなります。
影響範囲：対象になる管理者・組織・開発チーム
今回のアップデートで直接影響を受けるのは、GitHub Enterprise環境でセキュリティ機能の導入可否を判断する管理者です。GitHub Docsでは、GitHub Advanced Securityのトライアル設定に関して、Enterprise accountのownerであること、支払い方法や過去の購入・トライアル状況などの条件が示されています。(GitHub Docs)
| 立場 | 影響 | 確認すべきこと |
|---|---|---|
| Enterprise管理者 | リスク評価からトライアルを開始しやすくなる | トライアル資格、支払い方式、過去のGHAS利用履歴 |
| Organization owner | リスク評価の実行・結果確認に関わる | Security and qualityタブ、Assessments画面、通知設定 |
| Security manager | リスク評価と優先順位付けに関わる | シークレット漏えい、脆弱性、対象リポジトリ |
| 開発リーダー | トライアル対象リポジトリの選定に関わる | CI負荷、CodeQL設定、修正担当の割り当て |
| 開発者 | アラート対応やpush protectionの影響を受ける | 誤検知対応、バイパス申請、修正フロー |
リスク評価自体は、Organization ownersとsecurity managersが利用でき、GitHub TeamおよびGitHub Enterpriseの組織では無料で利用できるとGitHub Docsに記載されています。Secret risk assessmentは漏えいしたシークレットへの露出を、code security risk assessmentはコードの脆弱性リスクを把握するためのレポートです。(GitHub Docs)
管理者が最初に確認すべき設定
リスク評価画面からトライアルを始められるようになったからといって、すぐ全リポジトリに展開するのはおすすめできません。まずは、次の順番で確認すると失敗しにくくなります。
トライアル資格と課金条件を確認する
GitHub Docsでは、セルフサーブでGitHub Advanced Securityのトライアルを設定する条件として、Enterprise accountのownerであること、クレジットカードまたはPayPalで支払っていること、過去にGitHub Advanced Securityを購入していないこと、GitHub Advanced Securityのmetered billingを利用中でないことなどが挙げられています。過去にトライアルを利用したことがある場合の条件もあるため、画面上の表示だけでなく、社内の契約履歴も確認してください。(GitHub Docs)
特に請求書払いの企業では、セルフサーブではなく営業担当への相談が必要になる場合があります。トライアル開始ボタンが表示されない場合は、権限不足だけでなく、支払い方式や過去の契約状況も疑うべきです。
リスク評価レポートを先に読む
GitHub Docsによると、Secret ProtectionとCode Securityのリスク評価レポートは、Organizationの「Security and quality」タブから「Assessments」を開き、「Scan your organization」を実行して生成します。Secret risk assessmentを初めて実行するとcode security risk assessmentも開始され、逆にcode security risk assessmentを初めて実行した場合もsecret risk assessmentが開始されると説明されています。(GitHub Docs)
ここで確認したいのは、単なる件数ではありません。次のような観点で読むと、トライアル対象を絞り込みやすくなります。
- 外部公開に近いリポジトリでリスクが出ているか
- 本番サービスに直結するリポジトリでアラートが出ているか
- シークレット漏えいと脆弱性の両方が同じ領域に集中していないか
- 修正担当者が明確なリポジトリか
- CI/CDの負荷増加を許容できるか
件数が多いリポジトリを優先するのではなく、影響度が高く、修正まで動かせるリポジトリから始めるのが実務上は有効です。
リスク評価の再実行タイミングを把握する
Secret risk assessmentとcode security risk assessmentは、どちらも再生成に制限があります。GitHub Docsでは、各リスク評価レポートを再生成できるのは90日に1回と説明されています。(GitHub Docs)
そのため、トライアル開始直前に再スキャンするか、既存レポートを使うかを決めておく必要があります。たとえば、大規模なリポジトリ整理やセキュリティ設定変更を実施した直後であれば、評価結果が古く見える可能性があります。一方で、90日制限を考えずに再実行すると、トライアル終了後の改善効果を同じ画面で確認しにくくなる場合があります。
トライアル開始後に見るべき設定と展開ポイント
GitHub Advanced Securityのトライアルを始めた後は、機能を有効にするだけでなく、どの範囲に、どの強さで適用するかを決める必要があります。GitHub Docsでは、トライアル企業に対してenterprise-level configurationを作成し、Secret ProtectionやCode Securityの機能をリポジトリへ適用する流れが案内されています。(GitHub Docs)
まずはセキュリティ構成を作成する
トライアルでは、企業単位のsecurity configurationを作成し、試したい機能やポリシーを設定します。GitHub Docsでは、設定作成時に多くの機能がすでに有効になっている場合があり、「Not set」の機能を確認して、試したい機能を有効化する流れが示されています。(GitHub Docs)
実務では、いきなり「Enforce」で全リポジトリに適用するより、次のように段階を分けると安全です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 初期確認 | 代表的な数リポジトリ | アラート量、誤検知、CI負荷を確認 |
| 小規模展開 | 1〜2組織または重要プロダクト | 修正フロー、通知、担当割り当てを検証 |
| 標準化 | 新規リポジトリまたは全社標準構成 | セキュリティ設定のばらつきを減らす |
| 強制適用 | 高リスク領域や本番系リポジトリ | ポリシー逸脱を防ぐ |
トライアルの目的が「導入可否の判断」なら、最初から完璧な設定を作る必要はありません。むしろ、誤検知対応、開発者の負荷、修正までの時間を測れる構成にすることが重要です。
既存リポジトリと新規リポジトリの扱いを分ける
GitHub Docsでは、enterprise-level applicationとorganization-level applicationの両方が案内されています。全Enterpriseの全リポジトリに適用する方法もあれば、既存構成がないリポジトリだけに適用する方法、Organization単位や一部リポジトリに適用する方法もあります。(GitHub Docs)
既存リポジトリには、すでにCodeQL workflow、Dependabot設定、独自のセキュリティツール連携が入っている場合があります。新しい設定を一括適用すると、重複スキャンや通知過多が起きることがあります。
おすすめは、次のように分ける運用です。
- 新規リポジトリ：標準セキュリティ構成をデフォルトで適用
- 既存の重要リポジトリ：個別に棚卸ししてから適用
- 実験用・検証用リポジトリ：誤検知やCI負荷の確認用に限定
- 外部公開・本番系リポジトリ：リスク評価結果を見て優先的に展開
「全社標準を作ること」と「全リポジトリへ即時適用すること」は別です。標準構成を作ったうえで、適用範囲は段階的に広げるのが現実的です。
Actions minutesの消費に注意する
GitHub Advanced Securityのトライアル自体は無料で利用できると案内されていますが、code scanningのdefault setupやその他ワークフローで使うGitHub Actions minutesについては課金・消費が発生する可能性があります。GitHub Docsでも、トライアル中のSecret ProtectionとCode Securityは無料である一方、Actions minutesの割り当てを使い切っている場合は、default code scanning setupで使うActions minutesに対して料金が発生する旨が説明されています。(GitHub Docs)
大規模組織では、ここを見落とすと「セキュリティ評価のためにCIコストが増えた」という問題になりがちです。特にモノレポ、大規模なJava・C#・C/C++プロジェクト、ビルド時間が長いリポジトリでは、トライアル前にActions利用量とスキャン頻度を確認してください。
開発者側で起きやすい変化
開発者にとって今回の変更は、ボタンの追加そのものよりも、トライアル開始後にアラートや保護機能が身近になる点が重要です。
Secret Protectionを有効にすると、シークレット検出やpush protectionの運用が関わります。Code Securityを有効にすると、code scanningのアラート、依存関係レビュー、CodeQL関連の結果確認などが開発フローに入ってくる場合があります。
開発チームには、トライアル開始前に次の3点を伝えておくと混乱を減らせます。
- アラートは「開発者を責めるため」ではなく、リスクを可視化するために出る
- 修正優先度は件数ではなく、影響度と悪用可能性で決める
- push protectionのバイパスや例外申請には、理由と承認フローが必要になる
特にシークレット検出では、過去に埋め込まれたトークンや検証用キーが見つかることがあります。削除だけでなく、キーの失効・再発行・影響調査まで含めて対応する必要があります。
移行・展開で失敗しやすいポイント
GitHub Advanced Security trial from a risk assessmentは導入の入口を簡単にしますが、展開設計まで自動で最適化してくれるわけではありません。次の失敗はよく起きます。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| リスク評価を読まずに全適用する | アラート過多で対応が止まる | 高リスク・高影響のリポジトリから開始 |
| 開発者に事前説明しない | アラートをノイズ扱いされる | 目的、優先度、対応ルールを共有 |
| 既存CIを確認しない | スキャン重複やActions消費増 | 既存workflowとCodeQL設定を棚卸し |
| Enforceを急ぎすぎる | 一部チームで開発フローが詰まる | 最初は検証用構成で運用を確認 |
| トライアル終了条件を確認しない | 評価前に期間が終わる | 開始日、評価日、購入判断日を決める |
GitHub Docsでは、GitHub Advanced Securityのトライアルは30日終了時点で購入していなければ期限切れになると説明されています。購入判断に必要な材料を集めるには、開始前に「何を見れば導入判断できるか」を決めておくことが重要です。(GitHub Docs)
管理者向けの実践チェックリスト
トライアルを始める前に、次の順番で確認してください。
トライアル開始前
- Enterprise管理者または必要な権限を持つユーザーでログインしている
- セルフサーブトライアルの条件を満たしているか確認した
- 支払い方式がクレジットカード、PayPal、請求書払いのどれか確認した
- 過去のGitHub Advanced Security購入・トライアル履歴を確認した
- Secret ProtectionとCode Securityのリスク評価を確認した
- 対象リポジトリを「重要度」「修正担当」「CI負荷」で分類した
トライアル開始直後
- EnterpriseまたはOrganization単位のsecurity configurationを作成した
- 新規リポジトリへのデフォルト適用方針を決めた
- 既存リポジトリへの適用範囲を限定した
- Actions minutesの消費見込みを確認した
- アラート対応者とエスカレーション先を決めた
- 開発チームに通知・アラート・例外申請のルールを共有した
評価期間中
- アラート数だけでなく、修正完了率と対応時間を記録する
- 誤検知、重複スキャン、CI遅延の有無を確認する
- シークレット検出時は削除だけでなく、失効・再発行まで確認する
- トライアル終了前に、継続利用する機能と不要な機能を整理する
今回の更新をどう活用すべきか
今回のGitHub Advanced Security trial from a risk assessmentは、セキュリティ製品を「機能一覧から選ぶ」のではなく、「自社のリスクを見てから試す」流れを作るアップデートです。管理者は、リスク評価画面で見えた課題をもとに、Secret ProtectionとCode Securityのどちらを優先するか、どのリポジトリから始めるかを決めるべきです。
まず実行すべきことは、リスク評価レポートの確認です。次に、トライアル資格と課金条件を確認し、影響度の高いリポジトリを数本選んで小さく試します。そこでアラート量、開発者の対応負荷、Actions minutesの消費、修正までの流れを測定すれば、30日間のトライアルを単なる検証で終わらせず、導入判断に使える材料へ変えられます。
コメント