GitHub code scanning のアラート対応を、セキュリティチームだけの別管理にしていると、開発チームのスプリント計画や優先順位から外れやすくなります。2026-04-15時点の重要な更新として、GitHub code scanning alerts を GitHub Issues に直接リンクできる public preview が登場しました。これにより、AppSec の修正作業を通常のエンジニアリングバックログに載せ、担当者・期限・優先度・進捗を GitHub Issues や Project 上で管理しやすくなります。(The GitHub Blog)
結論から言えば、この機能は「脆弱性アラートを見つける仕組み」ではなく、見つかった脆弱性を開発チームの通常業務に接続するためのワークフロー機能として考えるべきです。Application security team は検出と優先度付けを行い、Engineering manager はそれをスプリントやロードマップに組み込む。両者の間に GitHub Issues を置くことで、セキュリティ修正を“お願いベース”から“管理可能な作業項目”に変えられます。
GitHub code scanning alerts と GitHub Issues 連携で何が変わるのか
GitHub の 2026年4月14日付 Changelog では、code scanning alerts を GitHub Issues にリンクできる機能が public preview として案内されています。アラート画面の「Tracking」セクションから Issue を作成または既存 Issue にリンクでき、Issue 側からも「Relationships」パネル内の「Security alerts」セクションで関連付けられます。(The GitHub Blog)
これまで多くのチームでは、code scanning のアラートは Security タブで確認し、開発チームの作業は Issues や Projects、別のチケット管理ツールで管理する、という分断が起きがちでした。この状態では、脆弱性の重要度は分かっていても、誰がいつ直すのかが曖昧になりやすくなります。
今回の連携で特に重要なのは、次の3点です。
| 変更点 | 実務上の意味 |
|---|---|
| code scanning alert から Issue を作成・リンクできる | セキュリティ指摘を開発チームの通常バックログに載せられる |
| アラート一覧で tracking 状態を確認できる | Issue 化されていない未対応アラートを見つけやすい |
has:tracking / no:tracking でフィルタできる | AppSec チームが「未追跡の脆弱性」だけをレビューできる |
つまり、GitHub code scanning / GitHub Issues 連携は、単なるリンク機能ではありません。セキュリティ修正を、スプリント計画、担当者割り当て、レビュー、進捗確認、完了確認まで含めた一連のバックログ管理に組み込むための入口です。
対象になるチームと利用条件
この機能が特に役立つのは、次のようなチームです。
- code scanning のアラートは出ているが、開発チームの対応状況が追いにくい
- AppSec チームとプロダクト開発チームの間で、修正優先度の認識がずれる
- セキュリティ修正をスプリントに入れる基準が曖昧
- GitHub Issues や GitHub Projects を標準のバックログ管理に使っている
- 複数リポジトリの脆弱性を、中央のセキュリティバックログで管理したい
GitHub Docs によると、code scanning alert tracking using GitHub issues は public preview であり、リポジトリへの write access を持つユーザーがアラートと Issue をリンクできます。また、Issue はアラートが見つかったリポジトリだけでなく、アクセス権があり GitHub Issues が有効な別リポジトリにもリンクできます。(GitHub Docs)
この「別リポジトリにリンクできる」点は、グローバル企業や大規模組織では重要です。たとえば、各サービスのコードは個別リポジトリで管理しつつ、セキュリティ修正の計画は security-remediation のような中央リポジトリの Issues で管理できます。
AppSec remediation を標準バックログに統合する基本ワークフロー
GitHub code scanning alerts を GitHub Issues にリンクできるようになっても、運用ルールがなければ効果は限定的です。重要なのは、アラートを Issue 化するだけで終わらせず、通常の開発プロセスに自然に流し込むことです。
おすすめの基本ワークフローは次の通りです。
| ステップ | 担当 | やること | 判断基準 |
|---|---|---|---|
| アラート確認 | AppSec | code scanning alerts を確認する | severity、影響範囲、該当コードの実行可能性を見る |
| Issue 化・リンク | AppSec または開発リード | 新規 Issue 作成、または既存 Issue にリンク | 1件で管理するか、関連アラートをまとめるか判断 |
| 優先度付け | AppSec + Engineering manager | ラベル、Project field、期限を設定 | 事業影響、悪用可能性、修正コストで決める |
| スプリント投入 | Engineering manager | 通常のバックログとして計画に入れる | Critical/High は早期対応、Medium/Low は計画対応 |
| 修正・PR | 開発者 | 修正ブランチを作り PR を出す | テスト、影響範囲、再発防止を確認 |
| スキャン確認 | AppSec または担当開発者 | code scanning の再実行結果を確認 | アラートが close されたかを見る |
| Issue クローズ | Issue owner | 確認後に Issue を手動で閉じる | アラート解消とレビュー完了を条件にする |
特に注意したいのは、アラートと Issue のステータスは自動同期されない点です。GitHub Docs では、脆弱性が修正されてアラートが自動的に閉じても、リンク済み Issue は手動で閉じる必要があると説明されています。逆に、Issue を閉じてもアラート自体のステータスは変わりません。(GitHub Docs)
この仕様を理解していないと、「Issue は閉じたのにアラートが残っている」「アラートは解消したのにチケットが開いたまま」といった混乱が起きます。運用ルールとして、Issue の完了条件に「次回 code scanning でアラートが解消されたこと」を明記しておくのが安全です。
新規 Issue と既存 Issue、どちらにリンクすべきか
code scanning alert は、新しい Issue を作成することも、既存 Issue にリンクすることもできます。どちらを選ぶかは、アラートの粒度と修正作業の性質で判断します。
| 判断軸 | 新規 Issue が向いているケース | 既存 Issue にリンクするケース |
|---|---|---|
| 修正範囲 | 単独の脆弱性として対応できる | 既存のリファクタリングや認証改善に含める |
| 担当者 | 明確に1人または1チームに割り当てられる | 複数チームが関わる大きな改善に紐づく |
| 優先度 | Critical / High で個別に追跡したい | 同種の Medium / Low をまとめて処理したい |
| 管理目的 | SLA や監査証跡を残したい | 既存のロードマップ作業と一体で管理したい |
| アラート数 | 1件または少数 | 関連する複数アラートをまとめる |
GitHub Docs では、各アラートは1つの Issue にリンクでき、1つの Issue は最大50件のアラートを追跡できると説明されています。(GitHub Docs)
この上限を踏まえると、実務では次のような使い分けが現実的です。
Critical や High のアラートは、個別 Issue として扱うのが基本です。担当者、期限、レビュー観点を明確にしやすく、監査時にも説明しやすいためです。
一方で、同じライブラリ利用パターンや同じ入力検証漏れが複数箇所にある場合は、1つの Issue に関連アラートをまとめる選択肢があります。ただし、まとめすぎると完了条件が曖昧になります。1つの Issue に複数アラートをリンクする場合は、本文に「対象アラート一覧」「修正対象ファイル」「完了条件」を明記しておきましょう。
Issue テンプレートに入れるべき項目
GitHub code scanning alert から Issue を作成すると、脆弱性の詳細を含めた Issue を作れます。ただし、チーム運用に乗せるには、開発者がすぐ判断できる情報を補う必要があります。
AppSec remediation 用の Issue には、最低限次の項目を入れると実務で回しやすくなります。
## 概要
code scanning で検出された脆弱性の修正。
## 対象アラート
- リンク済み code scanning alert を参照
## 影響範囲
- 対象機能:
- 影響を受けるユーザーまたはデータ:
- 本番到達可能性:
## 優先度
- Severity:
- Business impact:
- 推奨対応期限:
## 修正方針
- 期待する修正内容:
- 避けるべき修正:
- 参考実装または関連PR:
## 完了条件
- 修正PRがレビュー済み
- テストが追加または更新済み
- 次回 code scanning で対象アラートが解消済み
- AppSec または指定レビュアーが確認済みポイントは、単に「SQL injection を修正する」のように書かないことです。開発者が知りたいのは、「どの入力が危険なのか」「本番のどこから到達するのか」「どのレベルの修正で完了とするのか」です。
たとえば、入力値をエスケープするだけでよいのか、クエリ組み立てをパラメータ化する必要があるのか、周辺のテストまで追加する必要があるのかで、見積もりも対応方針も変わります。Issue には、セキュリティ上の背景と、開発作業としての完了条件の両方を書くべきです。
ラベルと Project fields で「セキュリティ修正」を見える化する
GitHub Issues にリンクするだけでは、バックログの中で埋もれる可能性があります。Engineering manager がスプリント計画で扱いやすいように、ラベルや Project fields を決めておくことが重要です。
おすすめのラベル例は次の通りです。
| ラベル例 | 用途 |
|---|---|
security | セキュリティ関連 Issue であることを示す |
code-scanning | code scanning alert 由来であることを示す |
severity:critical / severity:high | 技術的な深刻度を示す |
risk:customer-data | 顧客データや機密情報に関わる可能性を示す |
status:awaiting-scan | 修正済みだが、次回スキャン確認待ち |
status:needs-triage | AppSec または開発リードの判断待ち |
remediation-sla:7d | 対応期限の目安を示す |
GitHub Docs でも、修正後にスキャン確認を待つ状態をラベルや Project field で表す運用が推奨されています。(GitHub Docs)
特に status:awaiting-scan のような中間状態は便利です。開発者の修正作業は終わっているが、code scanning の結果がまだ反映されていない場合、Issue を閉じるには早すぎます。この状態を明確にしておくと、AppSec チームは「確認待ち」だけをまとめてレビューできます。
has:tracking と no:tracking の使いどころ
GitHub の Changelog では、code scanning alert list や security campaigns で has:tracking と no:tracking フィルタを使い、追跡済み・未追跡のアラートを絞り込めると説明されています。(The GitHub Blog)
AppSec チームにとって特に重要なのは no:tracking です。これは「アラートは存在するが、まだ Issue として管理されていないもの」を洗い出すために使えます。
実務では、次のようなレビューサイクルが有効です。
| 頻度 | 確認するもの | 目的 |
|---|---|---|
| 毎日 | Critical / High かつ no:tracking | 緊急対応漏れを防ぐ |
| 週次 | Medium 以上の no:tracking | 次スプリント候補を整理する |
| スプリント計画前 | has:tracking の未完了 Issue | 既存バックログの優先度を調整する |
| リリース前 | 主要ブランチの未解消アラート | リリース判断材料にする |
この運用により、セキュリティチームは「アラート一覧を見る人」、開発チームは「Issue を消化する人」という分断を避けられます。未追跡アラートを減らすことは、単なる整理ではなく、修正責任を明確にするための第一歩です。
Engineering manager が決めるべき優先度ルール
AppSec remediation を標準バックログに統合する際、最も揉めやすいのが優先度です。セキュリティチームは「早く直してほしい」と考え、開発チームは「今のスプリントに入れる余裕がない」と考えます。
この衝突を減らすには、severity だけでなく、事業影響と修正コストを含めた判断基準を事前に決めておく必要があります。
| 優先度 | 例 | 対応方針 |
|---|---|---|
| P0 | 本番到達可能な Critical、認証回避、顧客データ漏えいの可能性 | 通常作業を中断して即時対応 |
| P1 | High で外部入力から到達可能、主要サービスに影響 | 次のリリースまたは現行スプリントに組み込む |
| P2 | Medium で到達条件が限定的、修正範囲が明確 | 次回以降のスプリントで計画対応 |
| P3 | Low、テストコード、到達不能に近い箇所 | 技術的負債や関連改修時にまとめて対応 |
ここでの注意点は、code scanning の severity をそのまま事業上の優先度にしないことです。たとえば High のアラートでも、該当コードが未使用の管理機能にあり外部到達性が低ければ、P1 ではなく P2 になる場合があります。逆に Medium でも、決済や認証、個人情報に関わる経路にあれば、優先度を上げるべきです。
Engineering manager は、Issue に入ったセキュリティ修正を「割り込み」ではなく「リスク低減のためのプロダクト作業」として扱う必要があります。そのためには、AppSec チームが技術的リスクを説明し、開発側が修正コストとリリース影響を見積もる場を作ることが大切です。
失敗しやすい運用パターン
GitHub code scanning alerts と GitHub Issues の連携は便利ですが、運用を誤るとバックログが混乱します。特に次のパターンには注意してください。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| すべてのアラートを自動的に Issue 化する | 大量の低優先度 Issue が発生し、開発チームが見なくなる | severity と到達性で triage してから Issue 化する |
| Issue を閉じればアラートも閉じたと誤解する | 実際の脆弱性が残ったまま完了扱いになる | 完了条件に code scanning での解消確認を入れる |
| Critical と Low を同じラベルだけで管理する | スプリント計画で優先順位が判断できない | severity と business impact を分けて記録する |
| 1つの Issue に多すぎるアラートをまとめる | どこまで直せば完了か分からなくなる | 関連性が強いものだけをまとめ、完了条件を明記する |
| AppSec だけが Issue を作り続ける | 開発チームのオーナーシップが生まれない | Engineering manager と共同で優先度を決める |
特に危険なのは、「セキュリティアラートを Issue 化したので対応管理は完了」と考えることです。Issue は作業管理の器であって、修正そのものではありません。担当者、期限、受け入れ条件、確認手順がなければ、単にアラートの場所が変わっただけです。
小規模チームと大規模組織での使い分け
同じ GitHub code scanning / GitHub Issues 連携でも、チーム規模によって設計は変えるべきです。
小規模チームの場合
小規模チームでは、複雑なプロセスを作りすぎないことが重要です。AppSec 専任者がいない場合は、開発リードやテックリードが週1回 code scanning alerts を確認し、対応が必要なものだけ Issue 化します。
運用例は次の通りです。
- Critical / High は必ず Issue 化する
- Medium は外部入力や認証・決済に関わる場合のみ Issue 化する
- Low は月次でまとめて確認する
- Issue には
securityとcode-scanningラベルを付ける - 修正後は
status:awaiting-scanにして、スキャン結果を確認してから閉じる
この程度のシンプルなルールでも、「誰かが気づいたら直す」状態からは脱却できます。
大規模組織の場合
大規模組織では、リポジトリやチームが多いため、中央管理と分散対応のバランスが重要です。
たとえば、AppSec チームが no:tracking のアラートを横断的に確認し、重要なものだけ各チームのリポジトリまたは中央のセキュリティ管理リポジトリに Issue 化します。その後、Engineering manager が各チームの Project に取り込み、通常のスプリント計画で扱います。
大規模組織では、次のような項目を標準化すると管理しやすくなります。
- severity と business priority の定義
- Critical / High の対応期限
- 例外承認のルール
- Issue テンプレート
- ラベル命名規則
- 修正後の確認手順
- 月次または四半期ごとの未対応アラートレビュー
グローバルチームでは、タイムゾーンや担当組織が分かれるため、Issue 本文に判断の根拠を残すことが特に重要です。口頭やチャットでの説明に依存すると、引き継ぎ時にリスク判断が失われます。
GitHub Issues 連携を導入する前のチェックリスト
導入前に、次の項目を確認しておくと運用が安定します。
| 確認項目 | チェック内容 |
|---|---|
| code scanning の有効化 | 対象リポジトリで code scanning が有効か |
| 権限 | アラートと Issue をリンクする担当者に write access があるか |
| GitHub Issues | リンク先リポジトリで Issues が有効か |
| Issue テンプレート | AppSec remediation 用のテンプレートがあるか |
| ラベル | severity、status、security 系ラベルが定義済みか |
| Project | セキュリティ修正を入れるボードまたはビューがあるか |
| 完了条件 | アラート解消確認後に Issue を閉じるルールがあるか |
| レビュー頻度 | no:tracking を確認する頻度が決まっているか |
GitHub の案内では、この機能は github.com 上で code scanning が有効なリポジトリ、および GitHub Enterprise Cloud with data residency で利用できる public preview とされています。public preview の機能は変更される可能性があるため、本番運用に組み込む場合は、運用手順を固定しすぎず、GitHub の更新に合わせて見直せる状態にしておくのが安全です。(The GitHub Blog)
まず実施すべき導入ステップ
最初から全リポジトリに広げる必要はありません。むしろ、重要なサービスを1つ選び、2〜4週間のパイロットで運用の詰まりを確認する方が現実的です。
おすすめの導入順は次の通りです。
| 順番 | 作業 | ゴール |
|---|---|---|
| 1 | 重要リポジトリを1〜3個選ぶ | 影響の大きい領域で試す |
| 2 | no:tracking のアラートを確認する | Issue 化すべきものを洗い出す |
| 3 | Critical / High を優先して Issue 化する | 開発バックログに載せる |
| 4 | ラベルと Project field を設定する | 進捗を見える化する |
| 5 | 修正PRと code scanning 結果を確認する | 完了条件を検証する |
| 6 | スプリント終了時に振り返る | 粒度、ラベル、期限設定を改善する |
パイロット時に見るべき指標は、単純な Issue 数ではありません。重要なのは、「未追跡の High 以上アラートが減ったか」「Issue 化されたアラートに担当者が付いたか」「修正後の確認待ちが滞留していないか」です。
AppSec とエンジニアリングをつなぐ運用に変える
GitHub code scanning alerts を GitHub Issues にリンクできるようになったことで、AppSec remediation はセキュリティチームの専用リストから、開発チームの標準バックログへ移しやすくなりました。アラートを Issue にリンクし、ラベルや Project fields で優先度を可視化し、修正後に code scanning の結果を確認してから閉じる。この流れを作ることで、セキュリティ修正は「後でやるもの」ではなく、通常の開発計画に組み込まれた作業になります。
まずは、重要リポジトリで no:tracking の code scanning alerts を確認し、Critical / High のアラートから GitHub Issues にリンクしてください。そのうえで、Issue テンプレート、ラベル、完了条件を整えれば、AppSec チームと Engineering manager の間で、修正責任と優先順位を共有しやすくなります。
コメント