GitHub Advanced Security のアラートが多すぎて、「結局どれから直せばいいのか」が決めにくい。2026年4月7日に GitHub が公開した Dynatrace 連携の強化は、この悩みにかなり直結するアップデートです。Dynatrace のランタイム コンテキストが GitHub に入ることで、Dependabot と code scanning のアラートを「実際にデプロイされているか」「インターネット公開や機密データ資産へのアクセスといった runtime risk があるか」で優先順位付けできるようになりました。対象は GitHub Enterprise Cloud で、前提は Dynatrace が監視する Kubernetes 環境です。 (The GitHub Blog)
要するに、重大度だけでなく「本番で本当に危ないものから直す」運用に近づけるのが今回の本質です。この記事では、GitHub Advanced Security と Dynatrace の統合で何が変わるのか、実務での使いどころ、導入時のチェックポイントまでまとめて整理します。
GitHub と Dynatrace の統合で何が変わったのか
GitHub Advanced Security の文脈では、Dependabot alerts は依存パッケージの脆弱性を知らせる仕組みで、code scanning はコード中の脆弱性や危険な実装を検出する仕組みです。今回の変更は、この2種類のアラートに対して、GitHub の linked artifacts page にある deployment records の metadata を使い、has:deployment や runtime-risk で絞り込めるようにした点にあります。Dynatrace は監視している Kubernetes workloads のコンテナイメージをリポジトリにマッピングし、その実行時情報を deployment records として GitHub に送ります。 (GitHub Docs)
実務的に言うと、脆弱性の「検出件数」が増えるのではなく、既存アラートの「並べ方」と「直す順番」の精度が上がる、と理解するのが正確です。GitHub 公式ドキュメントも、production context を紐付けることで、本番に出ていないコードではなく、本当に production を危険にさらすアラートへ絞り込めると説明しています。 (GitHub Docs)
| 判断の軸 | 従来の見方 | Dynatrace ランタイム コンテキスト追加後 |
|---|---|---|
| 高 severity だが未デプロイ | 上位に残りやすい | 後回し候補として切り分けやすい |
| 本番デプロイ済みで internet-exposed | 他のアラートに埋もれやすい | 初動の対象として拾いやすい |
| 組織横断の backlog 解消 | repo 単位の個別対応になりやすい | security campaigns でまとめて着手しやすい |
まず試したい絞り込み条件
GitHub が代表例として挙げているのは、has:deployment AND runtime-risk:internet-exposed です。これは「デプロイ済みで、かつインターネットに公開された実行環境に関係するアラートだけを見る」という意味になります。runtime risk としては、少なくとも internet-exposed と sensitive-data が用意されています。 (The GitHub Blog)
公開面を先に潰すなら
has:deployment AND runtime-risk:internet-exposed外部公開されたサービスを多く運用している組織なら、最初に試すべき条件です。静的な severity だけでは埋もれがちな「本番で露出しているアラート」を先に浮かび上がらせやすくなります。 (The GitHub Blog)
データ影響を先に見るなら
has:deployment AND runtime-risk:sensitive-dataこちらは機密データ資産へのアクセスがある実行環境を優先して見たいときに有効です。顧客データや決済系データを扱うサービスでは、severity だけでなく「どのデータに触れるか」で優先度が逆転することがあるため、実務では特に重要です。 (Dynatrace Documentation)
GitHub の production context filters は、artifact registry など他の条件とも組み合わせて使えます。つまり、Dynatrace のランタイム コンテキストは単独で使うよりも、既存の severity・repo・registry 条件と合わせて「自社の運用基準に合う絞り込み」を作るのが実践的です。 (GitHub Docs)
どの画面で効くのか
この GitHub Advanced Security と Dynatrace の統合で追加された production context は、Dependabot alerts view、code scanning alerts view、そして security campaigns で使えます。さらに individual alert ページでは runtime risk が属性として見えるため、一覧での絞り込みだけでなく、個票の判断材料としても使えます。 (The GitHub Blog)
特に実務で効くのは security campaigns です。GitHub の campaigns は organization の Security and quality タブから作成でき、テンプレートだけでなく custom filters でも対象を決められます。つまり「デプロイ済みで internet-exposed な code scanning alerts だけを campaign 化する」といった、現場に近い切り方ができます。 (GitHub Docs)
たとえば、全社で 500 件の Dependabot alerts が残っている場合でも、まず deployed かつ internet-exposed なものだけを抽出し、パッチがある依存関係から security updates で処理する、という流れに変えられます。code scanning でも同様に、広く薄く触るのではなく、production に効くものだけを campaign に載せて開発チームへ渡しやすくなります。 (GitHub Docs)
導入前に確認したい前提条件
ライセンスと対象環境
この機能は GitHub の changelog 上では GitHub Enterprise Cloud customers 向けに一般提供とされています。なお、GitHub Code Security / Secret Protection 自体は GitHub Team と GitHub Enterprise Cloud のアカウントで利用できますが、今回の runtime context 機能の公開範囲はそれより狭い点に注意が必要です。また、Dynatrace 側の説明では、runtime context は Dynatrace が監視する Kubernetes workloads から収集されます。つまり、GitHub Advanced Security を使っていても、GitHub Enterprise Cloud ではない、あるいは Kubernetes ベースで運用していない場合は、期待する効果が出にくいと考えるべきです。 (The GitHub Blog)
認証方式と必要な権限
Dynatrace docs では GitHub App ベース認証が推奨されています。理由は、権限を細かく制御でき、organization レベルの audit logs を扱え、API rate limit も有利だからです。送信側で runtime context を GitHub に書き戻すには、Artifact metadata が Read-and-write、Attestations が Read-only、さらに Dependabot alerts と Code scanning alerts の Read-only 権限が必要です。PAT ベース認証も使えますが、位置付けは「素早い検証向け」です。 (Dynatrace Documentation)
連携精度を左右するのは artifact attestations
いちばん見落としやすいのが、コンテナイメージと GitHub リポジトリのひも付けです。Dynatrace は artifact attestations を推奨しており、これがあるとレジストリに依存せず、より確実に runtime context をリポジトリへ結び付けられます。逆に attestation がない場合の代替は、基本的に ghcr.io の image name 解析です。つまり、他社レジストリを使っていて attestation もない、という構成だと、ここが最初のつまずきどころになりやすいです。 (Dynatrace Documentation)
runtime risk を出したいなら RVA も確認する
デプロイ情報だけなら deployment visibility で見られますが、internet-exposed や sensitive-data といった runtime risk を GitHub 側に渡すには、Dynatrace Runtime Vulnerability Analytics（RVA）の設定が重要です。RVA が無効だと、「デプロイ済み」は分かっても、「外部公開されている」「機密データに到達できる」といった優先判断の材料が不足しやすくなります。 (Dynatrace Documentation)
導入から確認までの流れ
最短で検証するなら、流れは次の5段階です。まず Dynatrace で GitHub Advanced Security extension をインストールし、次に GitHub App か PAT で認証を設定します。そのうえで、対象の build workflow に artifact attestations を入れ、必要なら RVA を有効化し、最初は namespace を絞って pilot するのが安全です。最後に GitHub で Packages → Linked artifacts を開き、deployment record が作成されていることを確認します。Dynatrace docs でも、deployment record が見えれば runtime context の共有成功と判断できると案内されています。 (Dynatrace Documentation)
ここで見るべきなのは、通常の repository Deployments ダッシュボードではありません。GitHub docs では、linked artifacts の deployment records は repository の deployment activity とは別ソースだと明記されています。画面を間違えると、「連携できていない」と誤判定しやすいので要注意です。 (GitHub Docs)
失敗しやすいポイント
severity だけで優先順位を決め続ける
今回の連携は severity を不要にする機能ではありません。GitHub 自身も、production context filters は他の filters と組み合わせて使えると説明しており、修正フェーズでは Dependabot security updates や code scanning の targeted campaign と組み合わせるのが前提です。現場では「high/critical だから先」ではなく、「deployed か」「internet-exposed か」「fix があるか」を重ねて見るのが失敗しにくい運用です。 (GitHub Docs)
GitHub 側にアラートはあるのに runtime context が付かない
この場合は、Dynatrace が Kubernetes workload を見ていない、artifact attestations がない、ghcr.io 以外で image name からの推定に頼っている、あるいは連携に使っている GitHub App / user が対象 repository を見られない、のどれかであることが多いです。Dynatrace は user access permissions に基づいて image と repository を関連付けるため、権限不足は意外と見落とされます。 (Dynatrace)
runtime-risk が出ないのに連携失敗だと思ってしまう
deployment record が見えているのに runtime-risk が付かないなら、まず RVA の設定を疑うべきです。Dynatrace docs では、internet exposure と sensitive data assets の assessments は RVA によって deployment records に含まれると説明しています。デプロイ可視化と runtime risk は、同じようでいて別の確認ポイントです。 (Dynatrace Documentation)
この機能が向いている組織
GitHub Advanced Security と Dynatrace の統合が特に効くのは、GitHub 上の Dependabot / code scanning backlog が多く、Kubernetes 上の本番ワークロードを Dynatrace で継続監視している組織です。複数チームで同じ platform を使っていて、AppSec、開発、SRE が「どれが本番で危ないか」を同じ画面で見たい場合、この runtime context はかなり相性が良いです。Dynatrace 側も、この統合を DevSecOps 間のサイロを減らし、prioritization と automation を改善する位置付けで説明しています。 (Dynatrace)
一方で、Kubernetes ではない運用が中心、artifact attestation をまだ導入していない、あるいは GitHub 側で organization 単位の security campaign 運用まで踏み込んでいない場合は、効果が限定的になりやすいです。この機能は「すべての脆弱性管理を置き換える」ものではなく、「本番影響の大きいアラートから触る」ための現実的な補助線だと考えると失敗しません。 (The GitHub Blog)
まず何をすべきか
最初の一歩は、全社展開ではなく 1つの本番 namespace と 1つの代表的なリポジトリ で pilot することです。build workflow に artifact attestations を入れ、Dynatrace 側で GitHub App 連携と RVA を整え、GitHub の Security and quality で次の条件を試してください。 (Dynatrace)
has:deployment AND runtime-risk:internet-exposedこの一覧で「いま直す意味があるアラート」が見えてきたら、次は campaign 化か、Dependabot security updates への接続です。今回のアップデートの価値は、アラートを増やすことではなく、修正の順番を production 基準に変えられること にあります。GitHub Advanced Security と Dynatrace の統合を使うなら、まずは severity の山を見るのではなく、本番で露出しているものから並べ替える運用に切り替えるのが正解です。 (The GitHub Blog)
コメント