深刻な脆弱性ほど放置される？GitHubセキュリティアラート4万件のデータが示す実態
公開日
セキュリティ
開発ライフサイクルの早期にセキュリティチェックを組み込む「シフトレフト」や「DevSecOps」は、現代のソフトウェア開発において標準的なアプローチとなっています。GitHub Advanced Security（GHAS）などのツールを導入し、コードスキャンや依存関係のチェックを自動化している開発組織も多いのではないでしょうか。しかし、これらのスキャンツールが「脆弱性を検知すること」と、開発チームが実際にそれを「修正すること」の間には、大きな隔たりが存在します。
本記事では、2026年に発表されたシェブデ大学の研究者らによる論文「Does Severity Drive Remediation? An Empirical Study of GitHub Advanced Security Alert Resolution in Enterprise Software Development」をもとに、実際の開発現場でセキュリティアラートがどのように処理されているかを解説します。本研究は、航空業界の実在するエンタープライズ企業が抱える4万件以上のアラートデータを対象に、アラートの深刻度（Severity）が実際の修正行動にどう影響しているかを定量的に分析したものです。
調査の概要：エンタープライズ企業における4万件超のアラート分析
本研究は、実際のエンタープライズ環境における開発者の行動パターンを明らかにするため、レトロスペクティブ（回顧的）かつ観察的な手法を用いて行われました。
調査の対象となったのは、航空業界に属する1つのグローバル企業です。同社が保有する506のプライベートリポジトリを横断し、2021年12月から2026年4月までの期間に発生したGitHub Advanced Security（GHAS）のアラートが分析されました。
分析の対象となったデータの内訳は以下の通りです。
- 総アラート数：40,215件
- Code scanning（静的アプリケーションセキュリティテスト: SAST）：9,900件（主なツール：CodeQL、Trivy）
- Secret scanning（機密情報の検知）：489件
- Dependabot（ソフトウェア構成分析: SCA）：29,826件
分析にあたっては、未解決のまま残っているアラート（右側打ち切りデータ）によるバイアスを避けるため、カプラン＝マイヤー生存時間分析などの統計的手法が適用されています。
深刻度が高いほど修正に時間がかかる「逆転現象」
セキュリティ管理の一般的なガイドラインでは、「緊急度や深刻度が高い脆弱性から優先的に修正すべきである」とされています。しかし、コードスキャンアラートのデータを分析したところ、この前提を覆す逆転現象が確認されました。
統計的な分析（Kruskal-Wallisテスト）の結果、アラートの深刻度と修正までにかかる日数の間には有意な関連が見られましたが、その方向性は予想とは真逆でした。深刻度が高いアラートほど、修正が完了するまでに長い日数を要していたのです。
表1：深刻度別の修正時間と四分位数
| アラートタイプ | 深刻度 | 解決済みアラート数 | 修正時間中央値（日） | 第1四分位数（Q1日） | 第3四分位数（Q3日） |
|---|---|---|---|---|---|
| Code scanning | Critical | 335 | 98 | 33.0 | 377.0 |
| High | 1,807 | 116 | 38.0 | 574.0 | |
| Medium | 2,226 | 51 | 25.0 | 317.0 | |
| Low | 1,778 | 41 | 30.0 | 41.0 | |
| Dependabot | Critical | 783 | 62 | 13.5 | 171.0 |
| High | 4,461 | 61 | 10.0 | 121.0 | |
| Medium | 3,836 | 62 | 12.0 | 161.0 | |
| Low | 1,294 | 62 | 11.0 | 134.0 |
Code scanningにおいて、もっとも修正が早かったのは「Low」の41日であり、次いで「Medium」の51日でした。これに対し、「Critical」は98日、「High」は116日と、深刻度の低いアラートに比べて2倍以上の時間がかかっています。
この生存時間の差は、未解決のアラートも含めてプロットした生存曲線でも明確に示されています。
図1：深刻度別のコードスキャンアラート未解決確率の推移
図1が示すように、時間が経過しても「Critical」や「High」のアラートは、「Low」や「Medium」に比べて、未解決のまま残る確率が常に高い状態が続いています。
この原因として、論文著者らは 「修正難易度」 の違いを挙げています。低い深刻度のアラート（例：単純な設定不備など）は1行の変更で済むことが多いのに対し、高い深刻度のアラート（例：SQLインジェクションや複雑なデータフローに関わる問題）は、アーキテクチャの変更や複数ファイルにまたがるコードの再設計が必要になるため、修正の着手が先送りされる傾向にあります。
最も危険な「Critical」アラートが却下されやすいパラドックス
さらに深刻な実態として、閉じられたアラート（解決または却下されたもの）の処理内容を分析したところ、もっとも深刻な「Critical」アラートが、修正されることなく「却下」される割合がもっとも高いというパラドックスが確認されました。
ロジスティック回帰分析を用いて、「最終的にアラートが却下されずに、適切に修正される確率」をモデル化した結果が以下の表です。
表2：コードスキャンアラートが修正されるオッズ比
| 変数 | オッズ比（Odds ratio） | 95%信頼区間（下限） | 95%信頼区間（上限） | p値 |
|---|---|---|---|---|
| Intercept（CodeQL / Critical） | 1.307 | 1.040 | 1.644 | 0.0219 |
| Tool: Trivy（vs. CodeQL） | 1.486 | 1.194 | 1.849 | 0.0004 |
| Severity: High（vs. Critical） | 6.572 | 5.009 | 8.624 | < 0.001 |
| Severity: Medium（vs. Critical） | 9.954 | 7.477 | 13.252 | < 0.001 |
| Severity: Low（vs. Critical） | 2.901 | 2.157 | 3.902 | < 0.001 |
※オッズ比が1より高いほど、基準となる「Critical」に比べて修正される確率が高く、却下されにくいことを示します。
この分析から、以下の事実が明らかになりました。
- Mediumアラートは、Criticalに比べて約10倍（オッズ比 9.95）修正されやすい。
- Highアラートは、Criticalに比べて約6.5倍（オッズ比 6.57）修正されやすい。
結果として、もっともリスクの高いはずの「Critical」アラートが、最も却下されやすい（または放置されやすい）という状況に陥っています。
この背景には、開発者がアラートに直面した際の複数の心理的・組織的要因があります。 たとえば、静的解析ツールが「理論上は脆弱だが、自社の本番環境やデプロイ構成においては悪用不可能」なパターンを検知した場合、開発者はその評価に時間を取られた末に「該当なし」として却下します。また、修正の負荷が現在の開発スプリントのキャパシティを超えている場合、形式的にアラート一覧から消去するために、Jiraなどにチケットを別途作成した上でGHAS側のアラートを「却下」するというケースも推測されています。
Dependabotのアラートは「深刻度」を見ていない？
ソフトウェアサプライチェーンセキュリティの要となるDependabotのアラート（29,826件）についても、興味深い傾向が確認されました。
表1に示されている通り、Dependabotでは「Critical」「High」「Medium」「Low」のすべての深刻度において、修正時間の中央値が 「約62日（61〜62日）」 に完全に収束しています。
統計的な有意差自体はサンプル数の大きさ（n = 10,374）により検出されているものの、実質的な差（効果量）はゼロに等しい状態です。これは、開発チームが依存関係の脆弱性アラートに対処する際、個々のアラートの深刻度を見て個別に対応しているのではなく、「スプリントごとの定期アップデート」や「四半期に一度のメンテナンスウィンドウ」などのスケジュールに基づいて、バッチ（一括）処理を行っていることを示しています。
ツール特性による圧倒的な差：CodeQL vs Trivy
本研究におけるもっとも大きな効果量が確認されたのは、コードスキャンに用いられる「ツール」の違いでした。
同じコードスキャンカテゴリに分類されていても、セマンティックなソースコード静的解析を行う「CodeQL」と、コンテナイメージやマニフェストファイルの依存関係をスキャンする「Trivy」では、開発者の対応速度に14倍もの開きがありました。
図2：ツール別の修正時間中央値の差
CodeQLによるアラートの解決時間中央値が571日であるのに対し、Trivyは41日でした。この差が示すのは、ツールの優劣ではなく、求められる「修正行動の性質」の違いです。
- Trivyの修正：多くの場合、設定ファイルやマニフェストファイルのバージョン番号を更新するだけで済み、コード全体のロジックを読み解く必要がありません。
- CodeQLの修正：データの流れ（データフローやインプットの検証経路）を理解し、安全な代替コードを設計し、回帰テストを行う必要があります。これには高度なセキュリティ知識と、多くの開発工数が要求されます。
開発者は、ツールが提示する「深刻度」よりも、その修正に要する「手間（手軽さ）」に基づいて優先順位を決定している実態が浮かび上がります。
現実的なセキュリティアラート運用のポイント
本研究の結果から、開発チームのセキュリティ管理において考慮すべき現実的なポイントが見えてきます。単にセキュリティスキャンツールを導入し、共通の解決期限（SLA）を設定するだけでは、真のセキュリティ向上にはつながらない可能性があります。
1. 「Critical ＝ 最優先で修正される」と思い込まない
運用の現場において、深刻度の高いアラートが大量に放置されていたり、却下されていたりしないかを監査・モニタリングする必要があります。特に、Criticalアラートの却下率が高い場合、ルールのチューニング不足（誤検知の多さ）や、開発者への修正支援（教育や適切な工数確保）が不足しているシグナルです。
2. ツールの性質に合わせた現実的なSLAを設定する
すべての「コードスキャン」を一括りにして「30日以内に修正」といったルールを課すことは避けるべきです。バージョン更新だけで済むTrivyのようなツールと、複雑なソースコード修正を伴うCodeQLのようなツールでは、開発者の負担が根本的に異なります。ツール特性や修正難易度を考慮した、現実的な目標設定が求められます。
3. 依存関係（Dependabot）のアラートには「バッチ処理」を推奨する
Dependabotの深刻度に基づいた個別の優先順位付けは、実務上機能していない可能性が高いです。個々の開発者にトリアージを委ねるのではなく、週次やスプリント単位での自動依存関係アップデート（一括処理）の仕組みを整え、定期的なメンテナンスプロセスとして組み込む方が効果的です。
4. 優先順位付けに「修正複雑さ」を取り入れる
単に脆弱性の潜在的影響（CVSSスコアなど）だけで優先度を決めるのではなく、「どれくらい簡単に直せるか」というアクションのしやすさも考慮に入れた優先度評価ロジックを検討してください。すぐに直せる低〜中深刻度のものを自動化やクイックフィックスで片付け、真に重要な高深刻度の問題に開発者が集中できる環境を作ることが重要です。
まとめ
自動セキュリティスキャンツールは、開発プロセスをセキュアにするための強力な武器です。しかし、本研究が示したように、「検知されたアラートの深刻度」と「実際の開発現場での修正スピード」には、期待とは逆の相関が存在します。
開発者は、アラートの深刻度よりも「修正にかかる手軽さ」を優先して行動する傾向があります。セキュリティ担当者やマネージャーは、この開発者の現実的な行動パターンを理解した上で、アラート疲れを防ぎ、真に重要なCriticalアラートに開発者が向き合えるような運用体制を設計していく必要があります。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：