2026 年 4 月 14 日、GitHub が Code Security Risk Assessment を無料で公開しました（GitHub Blog）。ワンクリックで組織配下の全リポジトリに横断して脆弱性を可視化する機能で、無償で利用できる点が大きなインパクトです。
同時期、Movable Type の深刻な脆弱性、30 個の WordPress プラグインへの一斉バックドア混入、Axios 開発ツール侵害など、サプライチェーン攻撃が加速しています。「自社コードは大丈夫か？」を経営層から問われる場面が、この 1 年で急増しました。
本記事では、Code Security Risk Assessment を受託開発・内製支援の棚卸しツールとして使い倒す方法をまとめます。
Code Security Risk Assessment の要点
GitHub の発表から要点を 3 つに整理します。
- 組織（Organization）単位で全リポジトリを一括スキャン。リポジトリ数が 100 を超える大規模組織でも数分で結果が出る
- 脆弱性を Critical / High / Medium / Low で分類し、修正難易度と露出度を掛け合わせたリスクスコア で優先度を表示
- 無料プランでも利用可能で、課金アップグレードなしで “現状認識” ができる
従来も Dependabot や CodeQL 個別機能はありましたが、“経営層に 1 枚で見せられるダッシュボード” が標準で用意された意味は大きいです。
受託開発で “見えていない脆弱性” が発生する 3 つの場面
場面 1：納品済み案件の長期保守
納品から 1〜3 年経った案件で、依存ライブラリが放置されているケース。ランタイム（Node / PHP / Ruby）の EOL を過ぎていると、OS / ミドルウェアのセキュリティパッチが当たらなくなります。
場面 2：派遣・外注エンジニアが残したリポジトリ
人の入れ替わりが激しい現場では、誰も中身を把握していないリポジトリ が組織配下に点在します。Risk Assessment はこれを”地図化”できます。
場面 3：M&A やグループ会社統合
買収先・子会社の GitHub Organization を統合した直後、技術資産の棚卸しが必須になります。脆弱性の全体像を数分で出せるのは DD（デューデリジェンス）の強い武器です。
実行手順 ― 30 分でできるコード脆弱性の初回棚卸し
ステップ 1：Organization の “Security” タブを開く
- GitHub で対象 Organization にアクセス
- 「Security」→「Code Security Risk Assessment」を選択
- 「Start assessment」をクリック
Organization オーナーまたは Security Manager 権限が必要です。
ステップ 2：スキャン対象の範囲を指定
- 全リポジトリ / アクティブなもののみ / 特定リストなど選択可能
- プライベート・パブリックの切替
- アーカイブ済みの除外（原則 ON）
初回はアクティブなリポジトリに絞るのがおすすめです。
ステップ 3：結果レポートを確認
数分後、次の 4 ビューが表示されます。
| ビュー | 用途 |
|---|---|
| Overall Risk Score | 組織全体の相対リスク（経営層向け） |
| Repository Breakdown | リポジトリ別の脆弱性数・重大度 |
| Top CVE List | 組織内で影響の大きい CVE トップ 10 |
| Dependency Graph | 脆弱な依存関係とその利用箇所 |
ステップ 4：優先度付け
「Critical × 本番稼働中 × 外部公開」の交差点を最優先に対応します。後述のトリアージ表を使うとブレません。
優先度判定 ― 「修正難易度 × 露出度 × 重大度」の三軸
全ての脆弱性をいきなり潰す必要はありません。トリアージが鉄則です。
| 重大度 | 露出度（本番/外部公開） | 修正難易度 | 推奨対応 |
|---|---|---|---|
| Critical | 高 | 低〜中 | 即時対応（当日中） |
| Critical | 高 | 高 | 緊急パッチ + 代替策検討 |
| High | 高 | 低 | 週次対応 |
| High | 低（社内のみ） | 中 | 月次対応 |
| Medium | 高 | 低 | 月次対応 |
| Medium | 低 | 中 | 四半期対応 |
| Low | 低 | 高 | 次回リファクタ時に一括 |
SSL 証明書完全ガイド や Web アクセシビリティ対応ガイド と同様、セキュリティも “全てを今すぐ” ではなく “何を先に” が本質 です。
受託開発の納品物に組み込む運用
提案フェーズ
- 提案書に「納品後 3 ヶ月の脆弱性診断レポート同梱」を明記
- 保守契約に「四半期ごとの Risk Assessment 実行」を組み込む
- 顧客に対する定期レポートテンプレートを用意
開発フェーズ
- CI に Dependabot / CodeQL / Secret scanning を組み込む
- PR テンプレートに「依存追加時はバージョンを固定、Renovate / Dependabot で更新」を明記
- GitHub Stacked PRs で小さくマージ する運用を組み合わせるとパッチ適用が迅速
保守フェーズ
- Organization 単位で月次スキャン → 顧客向けサマリレポート
- Critical 検出時の 1 次対応 SLA（24h 以内の連絡）を契約に含める
- 3〜5 年サイクルでのプラットフォーム刷新計画を年次で提案
顧客説明のコツ ― 経営層に届く言い換え
脆弱性診断は、技術者には刺さっても経営層には伝わらないことが多い領域です。以下の言い換えをテンプレ化しておくと有効です。
| 技術用語 | 経営層向けの言い換え |
|---|---|
| Critical 脆弱性 | 「外部から不正アクセスされる可能性が極めて高い 危険度の穴」 |
| 依存ライブラリの脆弱性 | 「利用している 部品メーカーから届いた部品に欠陥 があった」 |
| EOL ランタイム | 「メーカーがサポートを終了した OS を使い続けている状態」 |
| サプライチェーン攻撃 | 「信頼していた取引先を経由した 攻撃」 |
| SBOM | 「成分表（どの部品を使っているかのリスト）」 |
Movable Type 脆弱性対応と CMS 移行 の記事で触れたように、“パッチ適用か移行か” の判断は経営判断マターなので、経営層が理解できる言葉で説明することが不可欠です。
まとめ ― 無料ツールが変えた “現状認識” のハードル
Code Security Risk Assessment の無料化は、セキュリティ診断の入口コストがゼロになったことを意味します。受託開発・内製支援の現場で押さえるべきは次の 3 点：
- “まず見る” を月次運用に組み込む（30 分で可能）
- “何を先に直すか” をトリアージ表で共有する（全部はやらない）
- 経営層向けの翻訳レイヤーを用意する（技術用語のまま渡さない）
弊社 GleamHub では、受託案件の納品物・既存システムのコード脆弱性診断を含む Web セキュリティ監査パッケージ を提供しています。Organization の初回スキャン実施、重大度別の対応優先度付け、経営層向けレポート作成まで、2 週間の短期診断プログラムからご相談いただけます。「何年も放置していて現状が把握できていない」状態の棚卸しが、最も費用対効果の高い出発点です。
