GitHubのSecurity alertsを見ても、「この脆弱性は本番に出ているのか」「外部公開サービスに影響するのか」がすぐ分からず、環境情報やデプロイ台帳を行き来しているチームは少なくありません。2026年4月15日時点で注目したいのが、GitHub repository properties / security alerts に deployment context が表示される更新です。結論から言うと、deployable と deployed のコンテキストを使うことで、Security engineers や platform operations teams は、アラートを“コード上の重大度”だけでなく“実際のデプロイ状態”に結び付けて、インシデントトリアージを短縮しやすくなります。GitHubの2026年4月14日のChangelogでは、artifact and deployment context が repository properties と security alert pages の2カ所に表示されるようになったと説明されています。(The GitHub Blog)
GitHub repository properties / security alerts で何が変わったのか
今回の更新のポイントは、GitHub上のリポジトリやセキュリティアラートに対して、「そのコードがデプロイ可能なのか」「実際にデプロイされているのか」という文脈を持たせられるようになったことです。
これまで多くの組織では、Dependabot alerts や code scanning alerts を確認した後、次のような確認作業が発生していました。
- このリポジトリは本番サービスに使われているのか
- 脆弱性を含むアーティファクトはレジストリに存在するのか
- そのアーティファクトは本番環境、ステージング環境、検証環境のどこに出ているのか
- 外部公開、機微データアクセスなど、ランタイム上のリスクはあるのか
- 修正を急ぐべきか、通常のバックログとして扱うべきか
GitHubの更新では、リポジトリプロパティとして deployable と deployed が追加されました。これらは既存の artifact metadata と deployment metadata を反映するもので、どのリポジトリがアクティブにデプロイされているかを手作業で管理する必要を減らせる、とされています。(The GitHub Blog)
さらに、Dependabot と GitHub code scanning のアラートページでは、影響を受ける artifact の runtime risk context を直接確認できるようになりました。アラートを開いた時点で、実行環境に関する追加情報を見られるため、すべてのアラートを同じ緊急度で扱うのではなく、実際のリスクに基づいて優先順位を付けやすくなります。(The GitHub Blog)
deployable と deployed の違いを正しく理解する
deployable と deployed は似ていますが、トリアージでは意味が大きく異なります。混同すると、対応優先度を誤る原因になります。
| プロパティ | 意味 | トリアージでの見方 |
|---|---|---|
deployable:true | linked artifacts page に、そのリポジトリに関連する有効な storage record がある状態 | ビルド成果物やパッケージとして管理対象になっている。今後デプロイされる可能性があるため、放置は危険 |
deployed:true | linked artifacts page に、そのリポジトリに関連する有効な deployment record がある状態 | 実際にどこかの環境へデプロイされている。特に本番や外部公開環境なら優先度を上げる |
GitHub Docsでは、organization が linked artifacts page にレコードを追加している場合、deployable:true と deployed:true を使ってリポジトリ一覧をフィルタリングできると説明されています。deployable:true は有効な storage record があるリポジトリ、deployed:true は有効な deployment record があるリポジトリを指します。(GitHub Docs)
実務では、次のように考えると判断しやすくなります。
deployable:true は「本番に行く可能性がある資産」です。まだデプロイされていないとしても、リリースパイプラインに乗る前に対策しておく価値があります。
deployed:true は「すでに環境上で動いている資産」です。特に production、internet-exposed、sensitive data access といった文脈がある場合は、インシデント対応に近い扱いが必要になります。
アラートと実際のデプロイ状態をつなぐとトリアージが短くなる理由
セキュリティアラートのトリアージが長引く主な原因は、アラートそのものよりも「影響範囲の確認」にあります。CVSSや重大度だけでは、実際に攻撃可能なのか、ユーザー影響があるのか、どのチームが直すべきなのかが分かりません。
deployment context を使うと、確認の軸が変わります。
| 従来の確認 | deployment context 利用後の確認 |
|---|---|
| リポジトリ名から担当チームを探す | artifact metadata から owning team や build details をたどる |
| 本番デプロイ有無をSlackや台帳で聞く | deployed:true や deployment record を確認する |
| 重大度だけで対応順を決める | runtime risk context と重大度を組み合わせる |
| すべてのHighアラートを同じように扱う | 本番・外部公開・機微データアクセスのあるアラートを先に扱う |
| 環境情報の古い手入力リストに依存する | CI/CDや外部システムから同期されたメタデータを使う |
たとえば、同じHighのDependabot alertが2件あるとします。
1つ目は、社内検証用のツールで、ビルドはされているもののデプロイ実績がありません。2つ目は、顧客向けAPIのコンテナイメージに含まれており、本番Kubernetes環境で稼働し、外部インターネットに公開されています。
アラートの重大度だけを見ると、どちらもHighです。しかし、deployed:true と runtime risk context を見ると、2つ目を先に直すべき理由が明確になります。これが、deployment context がインシデントトリアージを短縮する最大の価値です。
Security alerts 側で確認すべき runtime risk context
今回の更新では、Dependabot と code scanning の alert pages に runtime risk context が表示される点が重要です。GitHub Docsでは、production context を関連付けることで、実際にproductionへ承認されたartifactに影響する脆弱性を優先できると説明されています。(GitHub Docs)
特に確認したいのは、次の情報です。
| 確認項目 | 見る理由 | 優先度が上がる例 |
|---|---|---|
| デプロイ有無 | 実行中のコードかどうかを判断するため | has:deployment が該当する |
| 環境種別 | 本番、ステージング、開発環境で対応速度が変わるため | production環境に出ている |
| 外部公開 | 攻撃面が広いかを判断するため | internet-exposed なワークロード |
| 機微データアクセス | 侵害時の被害が大きいかを判断するため | 顧客情報、認証情報、決済関連データへのアクセス |
| artifact registry | どの成果物を修正・再ビルドすべきか特定するため | JFrog Artifactory や独自レジストリ上の対象artifact |
GitHub Docsでは、storage record 由来の artifact-registry-url や artifact-registry、deployment record 由来の has:deployment や runtime-risk などのフィルターが使えると説明されています。例として、外部公開されているデプロイ済みコードのアラートに絞る場合は、has:deployment AND runtime-risk:internet-exposed のように組み合わせられます。(GitHub Docs)
実務で使えるアラート優先度の決め方
Security teams が remediation を進めるときは、単に「Criticalだから最優先」「Mediumだから後回し」と決めるより、デプロイ状態を組み合わせる方が現実に合います。
おすすめは、次の4段階で優先度を切る方法です。
| 優先度 | 条件の例 | 対応方針 |
|---|---|---|
| P0 | deployed:true かつ外部公開、または機微データへアクセスする本番サービス | インシデント対応に近い扱い。即時調査、影響範囲確認、修正PR、再デプロイを進める |
| P1 | deployed:true で本番または重要な内部サービスに影響 | スプリントを待たずに修正計画を作る。担当チームと期限を明確にする |
| P2 | deployable:true だが現在のデプロイ実績はない | 次回リリース前に修正。リリースゲートやブランチ保護に組み込む |
| P3 | deployable / deployed の文脈がなく、実行可能性も低い | 通常バックログ。誤検知や不要コードなら整理対象にする |
この分類で重要なのは、P2を無視しないことです。deployable:true のリポジトリは、今は本番に出ていなくても、将来のリリースでそのままデプロイされる可能性があります。CI/CDに乗る成果物なら、修正を後回しにしすぎると、リリース直前にセキュリティレビューで止まる原因になります。
Platform operations teams が先に整えるべきデータ
deployment context は、GitHubが自動的にすべての組織の環境を推測する機能ではありません。前提として、linked artifacts page に storage records と deployment records を連携する必要があります。
GitHub Docsでは、linked artifacts page は GitHub Actions でビルドされた container images、packages、production code のbuildsなどを統合的に表示し、artifact がどのようにビルドされ、どこに保存または実行され、どのようなコンプライアンス・セキュリティメタデータを持つかを示すと説明されています。また、artifact file 自体を保存するのではなく、artifact に関連する metadata の信頼できるソースとして機能します。(GitHub Docs)
導入時は、次の順序で整えると失敗しにくくなります。
| 手順 | やること | 成果 |
|---|---|---|
| 1 | 対象リポジトリと本番サービスを棚卸しする | どのリポジトリをdeployment context対象にするか決まる |
| 2 | artifactの生成元を明確にする | GitHub repository、commit、workflow、container imageなどを結び付けられる |
| 3 | storage record を連携する | deployable:true の判定に使える |
| 4 | deployment record を連携する | deployed:true や has:deployment の判定に使える |
| 5 | runtime risk context を付与する | internet exposed、sensitive data access などで優先度を切れる |
| 6 | Security alerts の運用ルールに組み込む | アラート対応が個人判断ではなくチーム標準になる |
GitHub Docsでは、storage record と deployment record の登録方法として、GitHubの artifact attestations 用アクション、Dynatrace・JFrog Artifactory・Microsoft Defender for Cloud との連携、artifact metadata REST API を使うカスタムスクリプトが挙げられています。(GitHub Docs)
導入後の具体的なトリアージフロー
Security engineers と platform operations teams が共同で使うなら、次のようなフローが現実的です。
アラート発生時
まず、Dependabot alert または code scanning alert を確認します。従来通り、CVE、影響範囲、該当ファイル、推奨修正、利用中バージョンを見ます。
次に、alert page 上の deployment context と runtime risk context を確認します。ここで deployed:true 相当の状態や、production、internet exposed、sensitive data などの情報が見える場合は、通常の脆弱性対応ではなく、実行中サービスへの影響確認として扱います。
優先度を決める
アラートの重大度だけでなく、次の条件を組み合わせます。
- 本番にデプロイ済みか
- 外部公開されているか
- 認証前に到達可能な経路があるか
- 機微データにアクセスするサービスか
- 修正済みバージョンへの更新が容易か
- 再デプロイに必要な承認やメンテナンスウィンドウがあるか
たとえば、外部公開されたAPIに影響するcode scanning alertなら、担当チームへの通知だけで終わらせず、修正PR、リリース手順、ロールバック方針まで一気に確認します。
修正と再確認を行う
Dependabot alert であれば、セキュリティアップデートのPRを作成し、テストを通して再デプロイします。code scanning alert であれば、該当コードを修正し、再スキャン結果を確認します。
重要なのは、修正PRのマージで完了にしないことです。deployed:true のアラートは、実際に修正版のartifactが対象環境へデプロイされるまでリスクが残ります。マージ済み、ビルド済み、デプロイ済みを分けて追跡する必要があります。
repository properties をポリシー enforcement に使う
今回の更新は、セキュリティアラートの見やすさだけでなく、platform governance にも効きます。GitHubのChangelogでは、deployable と deployed を使って、organization 内のリポジトリを deployment context でフィルタリングしたり、rulesets、branch protections、compliance policies を自動適用したりできると説明されています。(The GitHub Blog)
実務では、次のような使い方が考えられます。
| 活用シーン | 具体例 |
|---|---|
| ブランチ保護 | deployed:true のリポジトリでは、mainブランチへの直接pushを禁止する |
| 必須レビュー | 本番デプロイ対象リポジトリでは、CODEOWNERSレビューを必須にする |
| セキュリティチェック | deployable:true のリポジトリでは、dependency review や code scanning の通過を必須にする |
| コンプライアンス | 本番影響のあるリポジトリだけに署名、証跡、承認フローを強制する |
| 棚卸し | deployed:true のリポジトリ一覧をもとに、重要資産台帳を更新する |
ポイントは、「全リポジトリに同じ厳しいルールをかける」のではなく、「実際にデプロイされるリポジトリに重点的にルールをかける」ことです。これにより、開発速度を落としすぎず、本番リスクの高い領域にガバナンスを集中できます。
よくある失敗と注意点
deployment context は強力ですが、導入すれば自動的にトリアージが完璧になるわけではありません。特に注意すべき失敗は次の通りです。
| 失敗しやすい点 | 起きる問題 | 対策 |
|---|---|---|
| storage record だけ連携している | deployable は分かるが、実際に動いているか判断できない | deployment record まで連携する |
| deployment record が古い | すでに停止したサービスを高優先度と誤認する | デプロイ・削除・ロールバック時にメタデータを更新する |
| 環境名が統一されていない | production / prod / prd が混在し、フィルターが効きにくい | 環境名の命名規則を先に決める |
| runtime risk を入れていない | 外部公開や機微データの有無で優先順位を切れない | internet exposure や data sensitivity を連携対象にする |
| チーム所有者が不明 | アラートの責任者を決めるまで時間がかかる | repository owner、CODEOWNERS、service catalog と合わせて整備する |
| マージを完了条件にする | 修正版が本番に出ていないのにクローズされる | 完了条件を「修正版artifactのデプロイ確認」まで広げる |
特に危険なのは、deployment metadata の鮮度を確認しないまま、自動で優先度を決めることです。CI/CDや外部監視ツールとの連携が途中で止まると、deployed:true や runtime risk context が実態からずれる可能性があります。最初の運用設計では、「メタデータが更新されなかった場合に検知する仕組み」も用意しておくべきです。
どのチームが何を担当すべきか
deployment context を使ったセキュリティ運用は、Security team だけでは完結しません。Platform、SRE、開発チーム、コンプライアンス担当の分担を明確にする必要があります。
| 役割 | 主な責任 |
|---|---|
| Security engineers | アラート優先度の基準作成、runtime risk を使ったトリアージ、修正状況の追跡 |
| Platform operations teams | CI/CD、artifact registry、deployment metadata の連携と更新 |
| SRE / Operations | 本番環境、外部公開、データアクセス状況の正確性確認 |
| Application teams | 修正PRの実装、テスト、再デプロイ、影響確認 |
| Governance / Compliance | 本番対象リポジトリへのrulesets、branch protections、証跡要件の適用 |
運用を定着させるには、アラート対応会議で毎回「これは本番に出ていますか」と聞く状態をなくすことが大切です。GitHub上の alert page と repository properties を見れば、少なくとも初動判断に必要な情報がそろう状態を目指します。
まず試すなら本番サービスの上位10件から始める
いきなり全リポジトリに deployment context を適用しようとすると、環境名、レジストリ、所有者、CI/CDの差分でつまずきます。最初は、影響の大きい本番サービスから始めるのが現実的です。
おすすめの進め方は次の通りです。
- 顧客影響が大きい本番サービスを10件選ぶ
- 各サービスのGitHub repository、artifact、registry、production environment を対応付ける
- storage record と deployment record を登録する
deployable:trueとdeployed:trueで対象リポジトリを確認する- Dependabot alerts と code scanning alerts を deployment context 付きで再確認する
- P0〜P3の優先度分類を試す
- 修正完了条件を「PRマージ」ではなく「修正版の本番デプロイ確認」に変更する
この小さな導入だけでも、Security team が手作業で環境確認する時間を減らし、Platform team は「どのメタデータがトリアージに効くのか」を具体的に把握できます。
まとめ：アラート対応は「重大度」から「実行中リスク」へ移す
GitHub repository properties / security alerts に deployment context が表示される更新は、単なるUI改善ではありません。deployable と deployed を使うことで、リポジトリ、artifact、deployment、runtime risk をつなぎ、アラートを実際の運用状態に基づいて判断しやすくなります。
重要なのは、次の3点です。
deployable:trueは、デプロイ可能なartifactに関係するリポジトリとして扱うdeployed:trueは、実際に環境へ出ているリポジトリとして優先的に見る- security alerts では、重大度だけでなく production、internet exposure、sensitive data access などの runtime risk context を組み合わせて対応順を決める
次に取るべき行動は、全社展開ではなく、本番影響の大きいリポジトリを数件選んで、storage record と deployment record の連携から始めることです。アラートと現実のデプロイ状態がGitHub上でつながれば、トリアージは「確認待ち」から「対応判断」へ進みやすくなります。
コメント