GitHub Code Security Risk Assessment は、GitHub Organization のコード脆弱性リスクを無料で素早く把握するための評価機能です。結論から言うと、セキュリティチームやエンジニアリング基盤チームが「どのリポジトリ、どの言語、どの種類の脆弱性から手を付けるべきか」を判断する初期診断には有効です。一方で、全リポジトリの完全監査、侵入テスト、依存関係やシークレット漏えいの網羅確認を置き換えるものではありません。
GitHub は 2026年4月14日、Organization 向けに無料の Code Security Risk Assessment を発表しました。日本語圏の読者向けには、2026年4月15日時点の最新動向として押さえておきたいアップデートです。この機能は CodeQL を使い、選択した最大20リポジトリをスキャンして、脆弱性の件数、深刻度、影響を受ける言語、検出ルール、Copilot Autofix の対象になり得る件数をダッシュボードで確認できます。(The GitHub Blog)
GitHub Code Security Risk Assessment とは
GitHub Code Security Risk Assessment は、GitHub Organization のコードに潜む脆弱性リスクを把握するための無料セルフサービス型スキャンです。対象は GitHub Team または GitHub Enterprise Cloud の Organization で、実行できるのは Organization owner と security manager です。GitHub Code Security のライセンス料金は発生せず、スキャンに使われる GitHub Actions minutes も課金対象にならないと説明されています。(GitHub Docs)
重要なのは、この機能が「組織全体のセキュリティ姿勢を一瞬で完全評価する魔法のボタン」ではない点です。デフォルトでは、過去90日間のコミット活動をもとに最大20件の private / internal リポジトリが事前選択されます。実行前に選択は変更できますが、選べるのは code scanning が対応する言語を少なくとも1つ含むリポジトリです。スキャンには1時間のタイムアウトがあり、リポジトリ内の全言語がスキャンに失敗した場合は失敗扱いになります。(GitHub Docs)
つまり、GitHub Code Security Risk Assessment は「全社のリスクを概観するためのサンプル診断」として使うのが現実的です。特に、まだ本格的な SAST や code scanning を展開できていない組織にとっては、最初の優先順位付けに向いています。
1クリックの組織リスクスナップショットで分かること
GitHub Code Security Risk Assessment で得られる価値は、単に「脆弱性が何件見つかったか」ではありません。セキュリティリーダーや platform owner が見るべきなのは、修正の順番、影響範囲、組織的な弱点です。
| 確認できる項目 | 分かること | 実務での使い方 |
|---|---|---|
| 総脆弱性数と深刻度 | Critical / High / Medium / Low の分布 | 経営層や開発責任者にリスクの大きさを説明する |
| 言語別の脆弱性 | どの技術スタックにリスクが偏っているか | JavaScript/TypeScript、Python、Java/Kotlin などの担当チーム単位で対策する |
| 検出ルール | どの種類の問題が繰り返し出ているか | セキュアコーディング標準やレビュー観点に反映する |
| 脆弱性が多いリポジトリ | 最初に着手すべきコードベース | 事業重要度や外部公開状況と合わせて優先順位を決める |
| Copilot Autofix 対象件数 | 自動修正候補になり得る範囲 | 短期で修正効果を出せる領域を見積もる |
GitHub のドキュメントでは、結果の見方として、ダッシュボード指標、言語別の脆弱性、影響の大きいリポジトリ、検出ルール、修正優先度を順に確認する流れが示されています。特に Critical / High のルールが複数リポジトリに出ている場合は、単発のバグではなく、設計・レビュー・共通ライブラリ・教育の問題として扱うべきです。(GitHub Docs)
GitHub Code Security Risk Assessment で分からないこと
この評価機能を過信すると、かえってリスクを見落とします。特に「スキャン結果が少ない＝安全」と受け取るのは危険です。
全リポジトリの完全な安全性は証明できない
最大20リポジトリの評価であるため、数百、数千のリポジトリを持つ組織では、あくまで一部のコードベースを見た結果です。デフォルト選択は直近90日間のコミット活動をもとにしますが、攻撃リスクが高いのは必ずしも最も活発なリポジトリとは限りません。たとえば、長年触られていない認証基盤、決済関連 API、古い管理画面のほうが実害につながる場合があります。
CodeQL 非対応の言語や領域は評価しきれない
CodeQL は C/C++、C#、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby、Rust、Swift、GitHub Actions workflows などに対応しています。一方、GitHub のドキュメントでは、PHP や Scala など、一覧にない言語は CodeQL の対象外であり、不完全な分析やアラートなしの結果につながる可能性があると説明されています。(GitHub Docs)
そのため、PHP 製の古い管理画面、Terraform や Kubernetes manifest、Dockerfile、クラウド設定、サードパーティ SaaS 設定などを含めた総合的なリスク評価には、別の検査も必要です。
依存関係、シークレット、実行環境の問題までは一括で解決しない
Code Security Risk Assessment はコード脆弱性の把握に焦点を当てた機能です。漏えいした API キーやトークンの検出は Secret Risk Assessment や secret scanning、脆弱なライブラリの検出は Dependabot alerts や SCA、コンテナイメージやクラウド設定の問題は別の仕組みと組み合わせる必要があります。
GitHub は code security risk assessment と secret risk assessment を別々の評価として提供し、それぞれの結果を Assessments view の別タブで確認できると説明しています。つまり、コード脆弱性とシークレット漏えいは近い問題ですが、見るべきレイヤーは異なります。(GitHub Docs)
悪用可能性や事業影響は自動では判断できない
Critical や High の検出結果が出ても、それが今すぐ外部から悪用可能とは限りません。逆に Medium の問題でも、認証前に到達できる API や個人情報を扱う処理にあるなら、優先度は上がります。
評価結果を見るときは、次の情報を必ず足してください。
- そのリポジトリは外部公開サービスか
- 認証前のリクエストで到達できるか
- 個人情報、決済情報、認証情報を扱うか
- 本番環境にデプロイ済みか
- 同じ脆弱な実装がテンプレートや共通ライブラリから広がっていないか
GitHub Code Security Risk Assessment は「危険そうな場所」を示しますが、「事業にとってどれほど危険か」は組織側が判断する必要があります。
セキュリティリーダーと platform owner はどう使うべきか
セキュリティリーダーにとって、この機能は予算化と優先順位付けの材料になります。platform owner にとっては、どのチームに code scanning、Copilot Autofix、PR ガードレール、セキュアコーディング支援を展開すべきかを決める入口になります。
| 状況 | 使い方 | 判断ポイント |
|---|---|---|
| まだ組織的な SAST がない | まず最大20リポジトリで現状把握する | Critical / High が出るか、特定言語に偏るか |
| ツールがチームごとにばらばら | 共通の GitHub 上の指標として比較する | 同じルールが複数リポジトリに出ていないか |
| 脆弱性対応の予算が必要 | ダッシュボードを根拠に投資判断を作る | 修正対象、対象チーム、期待効果を数字で示せるか |
| 緊急でコード脆弱性を探したい | 初動の絞り込みに使う | 特定 CVE や依存関係調査は別途行う |
| GitHub Code Security の導入を検討中 | 試験導入前のベースラインとして使う | Copilot Autofix 対象件数と修正工数を見積もる |
特に、無料のセキュリティ評価ツールを探している組織では、「今すぐ全社の弱点を見たい」という緊急性が高いことがあります。その場合でも、GitHub Code Security Risk Assessment は最終回答ではなく、次に詳しく調べる対象を絞るための入口として扱うのが安全です。
実行前に決めておきたいリポジトリ選定基準
デフォルトで選ばれたリポジトリをそのままスキャンしても有益ですが、実務では選定を見直したほうがよいケースがあります。最大20件という制約があるため、選び方で結果の意味が大きく変わります。
優先して含めたいリポジトリ
- 外部公開されている Web アプリケーションや API
- 認証、認可、セッション管理を扱うサービス
- 個人情報、決済情報、契約情報、医療・金融系データなどを扱うコード
- 複数チームが再利用する共通ライブラリ
- 古いフレームワークや保守担当が曖昧なリポジトリ
- 最近大きな改修が入ったリポジトリ
- インシデントや監査で過去に指摘を受けた領域
あえて外してもよいリポジトリ
- サンプルコード、検証用、廃止予定のコード
- CodeQL 非対応言語が中心で、有効な結果が期待しにくいもの
- 事業影響が小さい社内限定ツール
- すでに別の厳格なスキャンが継続運用されているもの
ただし、社内限定ツールでも管理者権限や顧客データに触れるものは例外です。「外部公開されていないから安全」とは判断しないほうがよいでしょう。
結果を見た後の優先順位付け
GitHub Code Security Risk Assessment の結果を見たら、件数の多い順だけで直すのではなく、深刻度、影響範囲、事業重要度、修正しやすさを掛け合わせて判断します。
| 優先度 | 対応すべきもの | 理由 |
|---|---|---|
| 最優先 | Critical / High が複数リポジトリに出ているルール | 組織的な実装パターンの問題である可能性が高い |
| 高 | 外部公開・認証前到達・重要データ処理に関わる検出 | 実害につながる可能性が高い |
| 中 | Copilot Autofix 対象で短期修正できる検出 | 修正速度を上げ、リスクを早く下げられる |
| 中 | 1つの重要リポジトリに集中する検出 | 所有チームを明確にして集中的に直せる |
| 低 | Low / Medium で到達性が低いもの | バックログ化し、定期的に消化する |
GitHub の結果解釈ガイドでも、Critical / High のルールが複数リポジトリに出ている場合は優先度が高く、同じルールが多くのリポジトリに出ている場合は、個別修正だけでなくトレーニングやコーディング標準の更新が必要になる可能性があると説明されています。(GitHub Docs)
緊急の脆弱性調査で使うときの注意点
「特定の脆弱性が自社コードにないか今すぐ知りたい」という場面では、GitHub Code Security Risk Assessment だけに頼らないでください。たとえば、特定フレームワークの CVE、依存ライブラリの脆弱性、認証バイパスの疑い、ログに出た攻撃試行を調べる場合は、別の確認が必要です。
実務では、次のように組み合わせます。
| 調べたいこと | 主に使う手段 |
|---|---|
| 自社コードに危険な実装パターンがあるか | Code Security Risk Assessment、CodeQL、code scanning |
| 脆弱な依存ライブラリを使っているか | Dependabot alerts、SBOM、SCA ツール |
| API キーやトークンが漏れていないか | Secret Risk Assessment、secret scanning |
| 本番環境で外部から到達できるか | ASM、クラウド設定確認、WAF/ログ分析 |
| 実際に悪用可能か | 手動レビュー、脅威モデリング、ペネトレーションテスト |
Code Security Risk Assessment は、緊急調査の「起点」としては有効です。しかし、特定 CVE の影響確認や侵害有無の判断には、依存関係、実行環境、ログ、ネットワーク到達性を含めた調査が必要です。
実行手順の概要
GitHub のドキュメントでは、Organization のページから Security and quality タブを開き、Security の Assessments から Scan your organization を選ぶ流れが示されています。初めて security risk assessment を実行する場合は、secret risk assessment も開始されると説明されています。(GitHub Docs)
実務上は、次の順で進めると失敗しにくくなります。
| 手順 | 作業 | ポイント |
|---|---|---|
| 事前準備 | 実行権限を確認する | Organization owner または security manager が必要 |
| 対象選定 | 最大20リポジトリを確認・変更する | 事業重要度と外部公開状況を加味する |
| スキャン実行 | Assessments から実行する | スキャン失敗やタイムアウトの有無を確認する |
| 初回レビュー | Critical / High、言語別、ルール別に見る | 件数だけでなく広がりを見る |
| 修正計画 | チーム別の対応バックログに分解する | 期限、担当、検証方法を決める |
| 継続運用 | code scanning や GitHub Code Security の導入を検討する | 1回限りの評価で終わらせない |
再実行は90日に1回とされているため、継続的に新規コードを検査したい場合は、通常の code scanning や GitHub Code Security の有効化を検討する必要があります。(GitHub Docs)
Copilot Autofix 対象件数はどう見ればよいか
ダッシュボードに表示される Copilot Autofix 対象件数は、修正スピードを見積もるうえで便利です。GitHub の発表では、2025年に Copilot Autofix を使って修正された security alerts が 460,258 件あり、脆弱性アラートの50%が pull request 内で解決され、平均修正時間も手動修正より短かったと紹介されています。(The GitHub Blog)
ただし、Autofix 対象であることは「そのままマージしてよい」という意味ではありません。AI が提案する修正は、テスト、コードレビュー、仕様確認、セキュリティレビューを通して判断する必要があります。特に認証、認可、暗号、入力検証、権限昇格に関わる修正では、機能要件を壊していないかを慎重に確認してください。
よくある失敗と避け方
| 失敗 | なぜ問題か | 避け方 |
|---|---|---|
| スキャン結果が少ないので安全と判断する | 対象外リポジトリや非対応言語のリスクを見落とす | 対象範囲と失敗したスキャンを必ず確認する |
| 件数の多い Low から直す | 重要な High / Critical が後回しになる | 深刻度、到達性、事業影響を優先する |
| デフォルト選択だけで全社判断する | 活発なリポジトリと重要リポジトリは一致しない | 外部公開・重要データ・認証系を意図的に含める |
| Copilot Autofix の提案を無検証でマージする | 仕様破壊や別の不具合を生む可能性がある | 自動テスト、レビュー、段階的リリースを通す |
| 経営層に件数だけ報告する | 対応判断につながらない | 影響、優先順位、必要な投資、期限をセットで示す |
| 1回実行して終わる | 新しいコードで再発する | PR 時点の code scanning や開発標準に組み込む |
次に取るべき行動
GitHub Code Security Risk Assessment は、無料で使える組織向けのコード脆弱性リスク診断として、初動の可視化に強い機能です。特に、セキュリティ施策を始めたいが「どこから手を付けるべきか分からない」組織には向いています。
まずは Organization owner または security manager が対象リポジトリを見直し、最大20件を選んでスキャンします。結果が出たら、Critical / High、複数リポジトリに広がるルール、外部公開サービス、Copilot Autofix 対象の順に確認し、30日以内に着手する修正計画へ落とし込みます。
一方で、この評価だけで「安全」と判断してはいけません。依存関係、シークレット、クラウド設定、実行環境、手動レビューを組み合わせて、継続的な DevSecOps の仕組みに変えることが重要です。GitHub Code Security Risk Assessment はゴールではなく、組織のコードセキュリティを動かし始めるための現実的な出発点です。
コメント