脆弱性のバックログはもはや技術的負債ではなく、攻撃対象領域です

どのセキュリティプログラムにも、数千件、あるいは数十万件の検出結果が積み上がったキューがあります。誰も対応しきれておらず、対応できるとも思っていません。多くのチームはこれを技術的負債として扱います。意図的に抱えるコストであり、余裕ができたときに返済し、利子率が低い限り許容できるものです。

この会計が長く成り立っていたのは、キューにあるもののほとんどは誰にも発見も悪用もされない、という1つの前提に基づいていたからです。エンジニアリング上の判断としては妥当だったこの前提が、今やこのモデルの最も脆弱な部分になっています。

バックログは賭けだった

両方の機能が存在して以来、開発者の数はセキュリティ担当者を上回ってきました。この制約下では、トリアージが正しく、率直に言えば唯一の選択肢でした。検出結果に優先順位を付け、重大度のしきい値を設定し、基準を超えたものに取り組み、それ以外は受け入れるのです。

それ以外を受け入れることは、悪用される確率への賭けでした。つまり、特定のサービスにあるこの特定の中程度の重大度の問題を、周囲のコードが変わってしまう前に攻撃者が見つけることはない、という賭けです。検出結果が実在することは理解されており、手を付けられないままになることに賭けていたのです。

現在もプログラムは、この賭けのための仕組みを運用しています。リスクレジスター、SLAの階層、「修正しない」「リスク受容」のステータス、例外や免除のワークフロー、そしてトリアージの対象にすらならない重大度の下限です。これらはすべて、組織が合理的な妥協を選び、それを大規模に運用するための仕組みを必要とした結果として存在しています。

3つの前提が同時に変わった

賭けの成否は、賭けた時点のオッズに左右されます。そして、そのオッズの3つが変化しました。

1. コードの到着が、どのレビューサイクルよりも速い

開発者1人あたりのコード行数は218%増加し、その62%が壊れているか安全でない状態です。2026年6月時点で、Snyk自身の製品データによると、修正される脆弱性1件に対して、新たに約6件の脆弱性が生み出されています。エージェント型開発によって、この比率はさらに広がり続けています。

数値そのものより方向性が重要です。流入が流出の6倍になると、誰も増やそうと決めていないのに、受け入れた残りがスプリントごとに増えていくからです。プログラムのすべてのしきい値、SLA、人員計画は異なる流入量を前提に設計されており、流入量が変わったときに見直されていません。

2. コードが、尋ねるべき作成者なしに届く

「作成者に尋ねる」はコードレビューで最も古くから使われてきた手段ですが、作成者がエージェントの場合、それに相当する手段はありません。誰もその依存関係を選び、そのパターンについて考え、変更の目的を説明できるわけではないからです。

今やレビュアーは、自分が書いておらず、質問しても答えを得られないコードを承認しています。かつて変更とともに伝わっていた理由付けは、変更そのものから再構築しなければなりません。以前なら2分間の会話で解決できた検出結果までキューに入り、コード量とは無関係の理由で流入がさらに増えています。

3. 攻撃者側が自動化された

これまでの悪用確率の賭けは、人間の速度で行う偵察を前提としていました。広い攻撃対象領域の列挙には攻撃者の実時間がかかり、返ってくるのはほとんどノイズだったのです。自動化によって、この計算が変わりました。広い攻撃対象領域を調べ、あらゆる弱いシグナルをカタログ化し、どのアナリストも丸一日かけて試そうとは思わなかった組み合わせをテストすることが、今では低コストでできます。

結果は具体的であり、対応も具体的でなければなりません。レジスター内のすべての項目は古いオッズに基づいて評価されており、その多くは受け入れた日以来、再検討されていません。つまり、この四半期に範囲を定めて計画できる作業として、レジスターを再評価する必要があります。

重大度の低い検出結果が、高重大度の攻撃経路を形成する

重大度は検出結果を単独で評価しますが、攻撃は検出結果を組み合わせます。

トリアージの基準を十分下回る、3つの項目を考えてみましょう。内部オブジェクトIDを漏えいさせる安全でない直接オブジェクト参照、推測したIDが有効かどうかを確認できる詳細なエラーレスポンス、そして既知のデシリアライゼーション問題を抱えた古いシリアライゼーションライブラリです。個別に見れば、どれもプログラムが受け入れ、その後見直すことのない典型的な検出結果です。しかし、連鎖すると、認証済みのリモートコード実行経路になります。

この仕組みが、バックログを攻撃対象領域へと変えます。キューは、攻撃者が組み立てられるコンポーネントの在庫として機能します。そして、その組み立ての部分は、重大度モデルでは決してスコアリングされません。

実務上の対応は、攻撃者が利用できるものの説明としてレジスターを読み直すことです。受け入れた検出結果のうち、同じサービスに存在するもの、同じ信頼境界を共有するもの、同じデータに触れるものを確認してください。そこにリスクが潜んでいます。重大度順に並べるだけのビューでは、こうした集まりは見えません。

優先順位付けはキューの順番を変えるだけで、短くはしない

増え続けるバックログへの直感的な対応は、より適切なランキングです。より精密にスコアリングし、到達可能性で重み付けし、悪用可能性で並べ替え、リストの上位から、より確信を持って取り組みます。

より良いランキングによって、同じ長さのキューの順番は改善されます。流入が流出を上回ると、ランキングはどの検出結果が永久に未対応のまま残るかを決めるだけです。つまり、優先順位付けは受け入れたリスクを管理するための手段になります。その手段を改善しても、プログラムが離れるべき状態の管理方法が改善されるだけです。

到達可能性、悪用可能性、修正結果の履歴が役立つ場面は別にあります。それらを修正の正確性と解消の順序に向けてください。そこでは、実際に件数を減らす問いに答えられます。この修正で本当の攻撃経路に対処できるか、ビルドを壊さずにリリースできるか、どれを先に解消すべきか。ゼロに到達できるかどうかは処理速度で決まり、ランキングはその速度を変えません。

バックログを攻撃対象領域として扱うために必要なこと

何かを変える前に、4つの数字を明らかにしましょう。多くのチームは1週間で算出できます。どんな議論よりも速く、会話の前提を変える数字です。

1. 実際の流入数と実際の解消数 過去90日間について、トリアージした検出結果ではなく、実際に解決した検出結果を数えます。

2. リスク受容および「修正しない」とされた項目の数と、それぞれが最後に再検討された日付です。組織がAIコーディングツールを導入する前の日付であれば、その項目は、すでに変わったオッズに基づいて評価されたことになります。

3. 人間の作成者がいるマージ済みコードの割合です。これは、流入したコードのうち、作成者本人に説明を求められるものがどれだけあるかを示します。

4. セキュリティ修正のマージ率です。前四半期に起票された修正のうち、いくつがリリースされたでしょうか。

4つ目の数字は、たいてい人を驚かせます。何年も実際の制約だったのに、関心は検出に向けられたままだったからです。修正は生成されてもマージされません。そのため、その率を改善せずに検出結果だけを増やすプログラムは、より長いキューを生み出すだけです。

バックログが減少するには、3つの条件が同時に満たされる必要があります。コードが作成される時点で予防によって流入を減らすこと、すべての検出結果について人間の判断を必要とせずに解消を進められること、そしてすべての差分を誰かが読むことなく修正の正確性を信頼できることです。この3つを整えれば、チームはリスクを実際に減らし、流入を上回るペースで解消を進められます。レジスターを開いて以来初めて、レジスターが縮小し始めるのです。

その時点で、取り組むべき仕事は変わります。作業の中心がキューの中から、プログラムそのものへ移るからです。