2026年4月8日、GitHubは GitHub Code Security のリスク評価を組織向けに提供開始しました。結論から言うと、GitHub Team または GitHub Enterprise Cloud の組織なら、Organization の所有者とセキュリティマネージャーが無料で最大20リポジトリを診断し、脆弱性の重大度・ルール種別・言語・Copilot Autofix の適用可能件数をまとめて把握できます。これにより、「どのリポジトリから直すべきか」「GitHub Code Security をどこまで有効化するか」を、勘ではなくレポートで判断しやすくなりました。(The GitHub Blog)
この GitHub Code Security のリスク評価は、無料で始めやすい一方で、最大20リポジトリ、再実行は90日ごと、1時間のタイムアウトありという前提があります。つまり、便利だからこそ「何を見る機能か」と「何はまだ見切れないか」を最初に理解しておくのが大切です。ここでは、機能の要点、組織での使い方、結果の読み方、実務で失敗しにくい進め方まで整理します。(GitHub Docs)
GitHub Code Security のリスク評価で何が変わったのか
今回のアップデートで大きいのは、GitHub Code Security を本格導入する前でも、組織のコード脆弱性を無料で俯瞰できるようになったことです。レポートには、見つかった脆弱性の概要に加えて、重大度、ルール種別、プログラミング言語ごとの傾向、Copilot Autofix で修正候補を出せる件数が含まれます。しかも、この評価自体は無料で、GitHub Code Security のライセンス料金も、評価スキャンで使う GitHub Actions minutes も課金対象ではありません。(The GitHub Blog)
| 項目 | 内容 |
|---|---|
| 利用できる人 | Organization の所有者、セキュリティマネージャー |
| 対象プラン | GitHub Team、GitHub Enterprise Cloud |
| 費用 | 無料。評価用スキャンにライセンス課金なし、Actions minutes も無料 |
| スキャン対象 | 最大20リポジトリ。既定では直近90日のコミット活動を基に候補が事前選択される |
| 実行条件 | code scanning 対応言語を1つ以上含むリポジトリが対象 |
| 再実行 | 90日ごと |
| レポートで分かること | 脆弱性、重大度、ルール種別、言語別傾向、Copilot Autofix 対象件数 |
ここまでが、GitHub の changelog と公式ドキュメントから確認できる基本仕様です。GitHub.com ではすでに利用でき、GitHub Enterprise Server 3.22 でも提供予定と案内されています。(The GitHub Blog)
なお、この機能は Secret risk assessment と別物です。同じ Assessments 画面に並びますが、コード脆弱性を見るレポートと、漏えいシークレットを見るレポートは別タブで管理され、個別に再実行します。コードの問題を見たいのにシークレット側だけ見ていた、という混同は起きやすいので要注意です。(GitHub Docs)
GitHub Code Security で組織のリスク評価を実行する手順
実行手順は難しくありません。GitHub 側での操作は次の流れです。(GitHub Docs)
- 組織のメインページを開く
Security and qualityタブを開く- サイドバーの
SecurityからAssessmentsを開く Code SecurityタブでScan your organization（日本語環境では「組織のスキャン」）を実行する- 既存レポートがある場合は
Rerun scan（「スキャンの再実行」）を使う
最初の実行で、まだ組織のセキュリティリスク評価を一度も走らせていない場合は、Secret risk assessment も同時に開始されます。レポート確認時は Code Security と Secret Protection の両タブを見て、コード脆弱性とシークレット漏えいの両面を把握しておくと判断がぶれません。(GitHub Docs)
ここで重要なのが、最初の20リポジトリの選び方です。既定では直近90日のコミット活動を基に候補が事前選択されるため、更新頻度が低いリポジトリは外れやすくなります。実務では、認証、決済、個人情報、共通ライブラリ、基幹業務など、変更頻度より事業影響が大きいリポジトリを手動で含めるほうが安全です。公式仕様は「直近90日の活動ベースで事前選択」ですが、優先順位そのものは自動で決めてくれません。(GitHub Docs)
| 優先して含めたいリポジトリ | 実務上の理由 |
|---|---|
| 認証・権限管理まわり | 1件の不備でも影響範囲が広い |
| 決済・個人情報を扱うアプリ | 事業リスクと説明責任が大きい |
| 共通ライブラリ・基盤コード | 1つの欠陥が複数サービスへ波及しやすい |
| 最近大きな改修を入れた基幹系 | 新しい不備が混ざりやすい |
| 更新頻度は低いが止めにくいシステム | 自動選定から漏れても手動で見る価値が高い |
レポートは「件数」より「偏り」で読む
GitHub の公式チュートリアルでも、レポートは単純な件数確認ではなく、どこに偏っているかを見て優先順位を付ける前提で説明されています。特に見るべきなのは、ダッシュボード上部の主要指標、言語別の偏り、リポジトリ別の偏り、ルール別の偏りです。(GitHub Docs)
まず見るべき3つの指標
最初に確認したいのは、スキャンされたリポジトリ総数、検出された脆弱性総数、Copilot Autofix の対象件数です。ここで大事なのは、単に数が多い少ないを見ることではありません。
「重要なリポジトリがきちんとスキャンできているか」「いまの組織でどれくらいの修復負荷があるか」「自動修正で初速を出せそうか」を判断する材料として使います。GitHub Code Security を有効化すると、Copilot Autofix の対象アラートには自動修正提案を使えるようになります。(GitHub Docs)
言語別の偏りは、個別不具合より“構造的な問題”を疑う
言語別の脆弱性グラフで、ある言語に脆弱性が集中している場合は、その言語を使うチームの実装パターンや、採用しているフレームワーク、共通部品、レビュー観点に課題がある可能性があります。これは、単発の修正チケットを切るより、セキュアコーディングのガイドライン見直しやテンプレート整備を先にやるべきサインです。GitHub 公式も、言語への偏在は特定の弱点や、対象チームへのガイダンス不足を示す可能性があると説明しています。(GitHub Docs)
リポジトリ別の偏りは、着手順を決めるのに使う
Repositories scanned テーブルと、上部の 最も脆弱なリポジトリ 指標は、どこから直すかを決めるのに直結します。脆弱性が多いリポジトリは、まずそこから着手するのが基本です。逆に、脆弱性が一部のリポジトリにだけ集中しているなら、組織全体の横断施策よりも、そのチームに修復を集中的に割り当てるほうが速く改善できます。(GitHub Docs)
ルール別の偏りは、組織横断で直すべきテーマを教えてくれる
Rules detected テーブルでは、どのルールが、どれくらいの重大度で、何リポジトリに広がっているかが分かります。ここで最優先に見るべきなのは、複数リポジトリにまたがって現れる Critical / High のルールです。GitHub 公式も、こうしたルールは最大のリスクになりやすいと案内しています。たとえば、同じ入力検証の不備が複数の API リポジトリで出ているなら、個別修正だけではなく、共通ライブラリやレビュー基準の見直しまで含めて考えるべきです。(GitHub Docs)
組織で優先順位を付ける実務的な判断基準
GitHub の公式チュートリアルをそのまま現場向けに言い換えると、判断基準はかなりシンプルです。複数リポジトリにまたがる重大・高リスクのルールを最優先にし、次に言語偏在や特定リポジトリ集中を見て、修正の打ち手を変えるのが基本です。(GitHub Docs)
| 状況 | まず取る行動 | 理由 |
|---|---|---|
| Critical / High の同一ルールが複数リポジトリに出る | 横断対応を最優先する | 影響範囲が広く、再発しやすい |
| 特定言語に脆弱性が偏る | ガイドライン、テンプレート、共通部品を見直す | チームや実装パターンに原因がある可能性が高い |
| 脆弱性が1〜2リポジトリに集中する | 担当チームを決めて短期集中で直す | 最短で改善効果を出しやすい |
| Copilot Autofix 対象が多い | GitHub Code Security の有効化候補を先に決める | 修正スピードを上げやすい |
GitHub 公式でも、重大度の高いルール、影響リポジトリ数、言語偏在、Autofix 対象数を見ながら修復優先度を決める流れが示されています。さらに、レポート画面からは、個別リポジトリ単位でも、組織全体でも GitHub Code Security を有効化でき、確認前に概算コストも見られるため、まず無料評価で実態をつかみ、その後に導入範囲を決める進め方が現実的です。(GitHub Docs)
導入前に知っておきたい注意点
この GitHub Code Security のリスク評価は便利ですが、誤解したまま使うと判断を誤ります。公式情報から見えてくる注意点を、実務目線で整理すると次の通りです。(GitHub Docs)
| 注意点 | ありがちな誤解 | 実務での対策 |
|---|---|---|
| 最大20リポジトリ | 組織全体を完全に網羅できる | 重要資産を手動で含める |
| 再実行は90日ごと | 週次・月次の定点観測に向く | 四半期レビュー向けと割り切る |
| 1時間タイムアウトあり | 検出数が少ないから安全 | 失敗したリポジトリや言語を確認する |
| Code と Secret は別評価 | 片方を見れば全体像が分かる | Assessments の両タブを確認する |
| code scanning 対応言語が必要 | どのリポジトリでも選べる | 対象言語の有無を先に確認する |
特に見落としやすいのが、スキャン失敗や部分成功の扱いです。公式ドキュメントでは、全言語のスキャンに失敗したリポジトリは失敗扱いになりますが、1つでも言語のスキャンに成功すれば、その結果はレポートに含まれるとされています。つまり、結果が少ないときは「安全だった」ではなく、「うまく測れなかった」可能性も考えるべきです。(GitHub Docs)
まず何をすべきか
今すぐ動くなら、やることは明確です。GitHub Team または GitHub Enterprise Cloud の組織で、所有者かセキュリティマネージャーの権限があるなら、まず Security and quality > Assessments から1回スキャンすることです。そこで、事業影響の大きいリポジトリが20件に入っているかを確認し、Critical / High の横断ルール、言語偏在、Autofix 対象件数を見て、修復順と導入範囲を決めてください。(GitHub Docs)
その結果、GitHub Code Security を有効化する価値が見えたら、選択したリポジトリだけ先に有効化するのがおすすめです。いきなり全社一括より、効果が出やすい領域から始めたほうが、予算説明もしやすく、運用も安定します。その後は Security and quality の Risk や Overview を使って継続監視に移すと、初回評価で終わらない運用にしやすくなります。(GitHub Docs)
今回のアップデートで、GitHub Code Security は「導入してから評価する」だけでなく、無料のリスク評価で現状を見てから導入範囲を決める進め方が取りやすくなりました。最初の20リポジトリ選定と、レポートの偏りの読み方さえ外さなければ、組織のセキュリティ投資判断はかなり速くなります。まずは1回走らせて、どこに本当にリスクが集中しているかを見にいくのが最短です。(The GitHub Blog)
コメント