漏えいの原因として公表された「使っていたソフトウェアの脆弱性」
9月末から10月初めにかけて、国内で個人情報漏えいの公表が相次ぎました。
多くは「不正アクセス」より先の手口がまだ公表されていません。一方で、原因が明示されたものには似た言葉が並びます。
- 10月5日公表の infoQ の件 では、サイトで使っていたソフトウェアの脆弱性を悪用されたとしています
- 9月30日に最終報告が出た VOISING の件 では、BI ツールの既知の脆弱性を、修正プログラムの適用前に突かれたとしています
この記事では個別の事案を評価しません。各社の調査は続いていて、どの脆弱性だったのかも公表されていないからです。取り出したいのは共通項だけです。
使っているソフトウェアの脆弱性が、直されないまま入口になった。
開発組織に置き換えると、これは Snyk などの画面に溜まったまま、手が付いていない脆弱性の話です。Snyk は9月24日のブログで、こうした溜まった脆弱性(ブログの言葉ではバックログ)はもう技術的負債ではなく攻撃対象領域だ、と書いています。今回はこのブログを軸に、それを減らす側の話をします。
ここ数本は AI を組み込んだアプリやエージェントの話でしたが、今回は AI 以前からある溜まった脆弱性を、AI でどう減らすかの話です。
リスク受容は、これまでは合理的な割り切りだった
どのセキュリティプログラムにも、誰も手を付ける予定のない検出結果の山があります。多くのチームはこれを、利息の低い技術的負債として抱えてきました。
重大度のしきい値を決め、それを超えたものだけ直し、残りは受け入れる。受け入れた分を支えているのは、攻撃者がこのサービスのこの Medium を見つける前に、周りのコードのほうが先に変わるだろうという見込みです。
開発者の数がセキュリティ担当より圧倒的に多い以上、これは合理的な割り切りで、リスク受容の台帳や「対応見送り」の扱いは、それを回すための道具です。
コードの量、書き手、攻撃者の3つが変わった
| 前提 | 何が変わったか |
|---|---|
| コードの量 | 開発者1人あたりのコード行数は218%増え、そのコードの62%に不具合か脆弱性がある。Snyk の製品データでは、2026年6月時点で修正1件に対して新しい脆弱性が約6件入っている |
| 作者に聞けること | 書いたのがエージェントだと、なぜその依存関係やパターンを選んだのか聞く相手がいない。以前なら2分の会話で閉じた指摘が、未対応の一覧に積まれる |
| 攻撃者の手間 | 広い攻撃対象領域を歩き回り、弱いシグナルを全部記録し、人なら時間を割かない組み合わせまで試すことが、自動化で容易になった |
数字そのものより向きが大事です。流入が流出の6倍なら、誰も決めていないのに、受け入れた残りは毎スプリント増えていきます。しきい値も SLA も人員計画も、今とは違う流入量を前提に決めたものです。
そしてリスク受容の台帳は、ほとんどが受け入れた日から見直されていません。古い相場で値付けされたままです。
重大度の低い指摘も、つなげば重大な攻撃経路になる
重大度は検出結果を1件ずつ採点します。攻撃は検出結果を組み合わせます。
ブログが挙げている例は3つの指摘です。どれも単体ではトリアージの線より下で、受け入れられたまま二度と見直されない種類のものです。
- 内部のオブジェクト ID が漏れる IDOR
- 推測した ID が有効かどうかを教えてしまう、詳細すぎるエラー応答
- 既知のデシリアライズの問題を抱えた、古いシリアライズライブラリ
つなげると、認証済みの経路からのリモートコード実行(RCE)になります。
これが、溜まった脆弱性を攻撃対象領域に変える仕組みです。未対応の一覧は、攻撃者が組み立てられる部品の在庫表になっています。 重大度のモデルが採点しないのは、その組み立てのほうです。
ブログの提案は、台帳を「攻撃者が使える材料の一覧」として読み直すことです。同じサービスにある指摘、同じ信頼境界をまたぐ指摘、同じデータに触れる指摘。重大度で並べた画面では、そうしたかたまりは見えません。
並べ替えでは減らない、減らすのに要る3つの条件
未対応の脆弱性が増えると、まず優先順位付けを良くしようとします。スコアを精密にし、到達可能性や悪用可能性で並べ、上から片付ける。
ブログの指摘はこうです。順位付けを良くしても、同じ件数の一覧が並べ替わるだけ。 流入が流出を上回っている限り、件数はゼロに近づきません。
到達可能性や悪用可能性が役に立たないわけではありません。並べ替えではなく、「この修正は実在する経路を塞ぐか」「ビルドを壊さずに出せるか」「何から片付けるか」の判断に使うものです。
そのうえでブログは、件数が減り始める条件を3つ挙げています。3つが同時に成り立つ必要があります。
- コードを書いた瞬間に流入を絞る(Snyk の Secure at Inception)
- 指摘ごとに人の判断を挟まなくても片付く(Snyk の自動修正 PRと Breakability)
- diff を全部読まなくても、修正が正しいと信頼できる
3つの中に「見つける」は入っていません。見つける量はもう足りていて、足りないのは減らす側だからです。
3つの条件のうち、AI に修正を任せるときにいちばん効いてくるのは3つ目です。次の節では、VulnBench の結果と Snyk の設計原則から、ここを掘り下げます。
Snyk が見つけて確かめ、AI が直す
では、AI に任せればいいのか。半分はそのとおりで、半分は違います。
Snyk は2026年5月、Anthropic の Claude を自社のプラットフォームに統合しました。Snyk のプラットフォームの中で、Claude が検出・優先順位付け・修正を支える形です。その発表で、Anthropic の副 CISO である Jason Clinton 氏はこう述べています。
AIセキュリティにおいて、検出がボトルネックだったことはありません
続けて、精度の高い検出結果を、ソフトウェアを作るワークフローの中で具体的な対応につなげることが鍵だ、という趣旨を語っています。
鍵になるのは「精度の高い」の部分です。AI のレビューだけでは、同じコードでも毎回同じ結果が返るとは限りません。Snyk の VulnBench は、10個の JavaScript プロジェクトに、同じ AI のセキュリティレビューを5回ずつかけて、結果を比べました。
- 決定論的な Snyk Code の結果と一致した指摘は、84.8%が5回とも出た
- 一致しなかった指摘は、ほぼ半分(49.7%)が5回中1回しか出なかった
ただし VulnBench 自身が断っているとおり、これは Snyk Code との一致度であって、正解率ではありません。一致しなかった指摘も誤検知とは限らず、確認すべき証拠です。結論は、AI のレビューと SAST は見落とす場所が違う、というものです。
つまり、AI を使うなら確かめる仕組みが要ります。確かめる対象は2つあります。
- AI が出した指摘: Snyk Code と一致しない指摘が本当に悪用できるかは、Continuous Offensive Security(COS) が確かめます。AI でアプリケーションの設計意図を推論して実際に攻撃を試し、悪用できるかどうかを検証済みの証拠として返します。Snyk Code などの結果を文脈に、スキャンでは届かない設計やビジネスロジックの欠陥、前に見た指摘の連鎖に的を絞ります
- AI が書いた修正: 3つ目の条件「修正の正しさを信頼できる」にあたります。直すのも確かめるのも同じ AI に任せれば、ここは満たせません
だから Snyk は、書く側と確かめる側を同じモデルにしないという原則で設計しています(プレスリリース)。毎回同じ結果を返す解析エンジンと、10年以上かけて積み上げてきたアプリケーションとセキュリティの文脈で見つけて確かめ、その間の修正に AI の速さを使う。OSS の修正では、Snyk の独立した検証層を通すと、フロンティアモデル単体の修正よりマージ率が94%高いとしています(同上)。
この分担を現場で組んでいたのが Labelbox です。
事例: Labelbox は高重大度の SAST の指摘を2〜3週間で解消した
AI 向けのデータを提供する Labelbox(従業員200名、サンフランシスコ)の2025年の事例です。
何が詰まっていたか
セキュリティ/DevSecOps エンジニアの Aaron Bacchi さんが抱えていたのは、優先度の低い SAST の検出結果を検証する時間でした。悪用できないとすぐ分かる問題をエンジニアに渡せば、信頼を失う。だから渡す前の確認に時間がかかり、未対応の指摘が減らなかった。
どう進めたか
普段使っていた Cursor に Snyk Studio(Snyk の MCP サーバー)をつなぎ、未対応の指摘に向けました。流れは「特定 → 悪用可能性の検証 → エージェントモードで修正 → Snyk で再スキャン → テストとデプロイ」です。再スキャンで直っていなければ、別の修正を試させます。見つけるのと確かめるのは Snyk、直すのは Cursor という分担です。
結果
- 未解決だった高重大度の SAST の問題を、2〜3週間で解消
- ある金曜日だけで、緩和策で解決できる問題を12件特定。エンジニアとの何週間ものやり取りが必要だったかもしれない作業でした
- 本人の見立てでは、従来のやり方なら1年かかっていた可能性がある
本人は、未対応の指摘を「ゼロにできるという自信を、初めて持てました」と振り返っています。
3つの条件に当てはめると
エージェントが1件ずつ修正案を出し(片付ける)、再スキャンとテストで解消を確かめ(正しさ)、空いた時間を Secure at Inception に向けています(防ぐ)。注目したいのは悪用可能性の評価の使い方で、順位付けではなく「エンジニアに渡すか、自分で閉じるか」の判断に使っています。「並べ替えでは減らない」の節で見た、到達可能性などの使い方そのものです。
このときは1人のエンジニアが指示を出して回していました。Snyk はこの流れを Remediation Agent として製品に組み込みつつあります(プレビュー段階)。詳しくは前回の記事に書きました。
手を付ける前に、4つの数字を出す
ブログは、何かを変える前に4つの数字を出すことを勧めています。たいていのチームは1週間で出せて、どんな議論より早く話の前提が変わる、とのことです。
| 数字 | 見方 |
|---|---|
| 直近90日の、実際の流入とクローズ | 「トリアージした件数」ではなく「実際に解消した件数」で数える |
| リスク受容・対応見送りの件数と、それぞれを最後に見直した日 | AI コーディングツールを導入した日より前なら、古い相場で値付けされたまま |
| マージされたコードのうち、人が書いたものの割合 | 流入のうち、書いた本人に説明を求められる分がどれだけ残っているか |
| セキュリティ修正のマージ率 | 前四半期に作られた修正 PR のうち、何件がマージされて出荷されたか |
驚かれやすいのは4つ目です。修正は作られても、マージされないことが多い。本当のボトルネックは昔からここだったのに、注目はずっと検出に向いていた、とブログは指摘しています。Clinton 氏の「検出がボトルネックだったことはありません」と同じ話です。
Snyk の自動修正 PR を使っているなら、作られた PR とマージされた PR の数から出せます。検出をいくら増やしても、この率が動かなければ未対応の一覧が長くなるだけです。
この率を動かす手がかりの1つが、修正で壊れるかどうかです。Snyk の実験では、Breakability で壊れにくいと判定された更新は、そうでない更新の4倍の割合でマージされました。
まとめ
- 溜まった脆弱性は「悪用されないだろう」という見込みで受け入れられてきた。その前提は、コードの量・作者不在・攻撃の自動化で同時に崩れた
- 低い重大度の指摘もつなげると高くなる。優先順位を付け直しても、件数は減らない
- 減らすには、流入を絞る・人の判断を挟まず片付ける・修正を信頼できる、の3つが同時に要る
- AI のレビューは毎回同じ結果を返さない。AI が出した指摘は COS で、AI が書いた修正は Snyk の再スキャンで確かめる
- Snyk が見つけて確かめ、AI が直す分担で、Labelbox は未対応だった高重大度の SAST の指摘を2〜3週間で片付けた
リスク受容した台帳を、今の相場で値付けし直すところから始めてみてください。