脆弱性とこれからの話 2026 summer - 2026のCVE津波を乗り越えるには

2026.8.31 update
2026.8.29 塩尻にてリリース

Transcript

1. APPLICATION SECURITY 脆弱性とこれからの話 - 2026のCVE津波を乗り越えるには 岡田 良太郎 アスタリスク・リサーチ 代表取締役 / OWASP Japan Chapter Leader 2026年8月 1 / 26
2. ご挨拶 岡田良太郎でございます。- 現場で、堅牢化を手伝っております 2006年から、企業の防御の実装とアドバイザリに。研究と現場の両方から。 — アスタリスク・リサーチ rsrch.jp — OWASP Japan チャプターリーダー ／Hardening Project 実行委員・オーガナイザ — 兵庫県警察 サイバーセキュリティ対策アドバイザ — 沖縄型産業中核人材育成事業 実行委員（内閣府 沖縄総合事務局） お名刺交換 お願いします — CISA・MBA 今日は、未解決の問題をお話しします。 完ぺきなセキュリティが無理なら ｜ 沖縄2026 2
3. COMPLIANCE 2026夏、やってくるコンプライアンス側の期限と、製品ベンダーがすべ きこと 2026年9月11日 2027年 1〜3月頃 EU CRA の報告義務開始 SCS 評価制度（★3・★4） 欧州向けに製品を出す製造業者と OSS スチュワードが対象。 サプライチェーンの対策水準を共通の物差しで示す制度。 悪用されている脆弱性を 24 時間以内に第一報、 ★3 は全社が最低限実装すべき技術・組織の対策、 72 時間以内に続報、そして最終報告。 ★4 は取引先管理やインシデント対応まで含む。 単一報告プラットフォーム経由で提出する。 取引先から水準を提示される側になりうる。 報告義務は、書類仕事が増えるという話ではありません — 24 時間で何を言えるかは、資産と経路をその時点で把握しているかで決まる — どの部品がどの製品に入っていて、どこに配布したかを平時から引けること ＝ 制度が要求しているのは報告書の形式ではなく、その手前の状態 報告期限は、平時の棚卸しの締切でもある。 出典: ENISA 単一報告プラットフォーム FAQ（2026-07-17 更新）／ EU CRA (Reg. 2024/2847) ／ 経済産業省 SCS 評価制度 27 / 30
4. AGENDA 2026 夏のアジェンダ — 未解決の 4 つ 01 脆弱性情報が、爆発的に急増している — CVE 情報の爆発／バグバウンティが AI に支配された 02 CVE 脆弱性情報 活用の危機 — 名前のぶれ（purl を使う）／CVSS と実際の悪用のずれ／CVSS の付かない深刻な脆弱性 03 アップデートが無いか、不備のある脆弱性情報がある — メンテナが追いつかない／AI で直すと増える問題 1 欠陥コード・2 悪意ある issue や PR 04 じゃあ、どうする？ 2 / 26
5. 01 THE EXPLOSION 脆弱性情報が、爆発的に急増している 見つける側も攻撃側も自動化した。まず、量から。 3 / 26
6. VOLUME Critical と High が 8 か月で、2025 年の通年を 41% 超えた Critical High Medium・Low・未付与 1〜8 月で、前年の通年を +41% 28,120 17,695 19,876 10,486 2023 2024 2025 2026 ここらへん、きみたち見てないよね 28,848 39,925 48,154 54,971 Critical と High だけに絞っても、2026 は 28,120 件。 出典: CVE Program 公式 cvelistV5 全件（2026-08-24 取得）を自前集計。2023–2025 は通年、2026 は 1/1–8/23 ／ 右の内訳は EPSS（FIRST）と CISA KEV 4 / 26
7. WHAT REMAINS 絞り込むと、何が残るのか 公開された CVE 54,971 2026年1月1日〜8月23日 深刻度が付いている 52,150 CNA・ADP が CVSS を付与 Critical または High 28,120 公開数の 51.2% EPSS 0.10 以上 30 日以内に悪用が観測される確率が 1 割以上 実際に悪用が確認 CISA KEV 収載（VulnCheck 686 件） 289 125 実際に悪用された 125 件のうち 14 件は、Critical でも High でもない。 出典: CVE Program cvelistV5（2026 は 1/1–8/23 の公開・深刻度）／ EPSS（FIRST）／ CISA KEV。いずれも 2026-08 の自前集計 5 / 26
8. BEYOND NVD 脆弱性情報は、NVD だけから来る時代ではない 目的の違う情報源を、束ねて読む。 1 採番して、点数を付ける CNA・NVD・CISA-ADP CVE 番号と深刻度。 2 悪用されているかを判定する CISA KEV・VulnCheck KEV・EPSS 実測 2 つ＋予測 1 つ。 3 パッケージ単位で勧告する OSV.dev・GitHub・Go・PyPA purl でたばねられ、40 以上のエコシステムが対象 4 CVE 番号が付かないものも載せる OSS-Fuzz・悪意あるパッケージ npm だけで 21.9 万件。 NVD/CVE 番号を待つ運用では、最後まで見えないものがある。 出典: OSV.dev データソース一覧（2026-08-27）／ CISA KEV・VulnCheck・EPSS（FIRST）／ OSV スキーマは OpenSSF 6 / 26
9. WHO REPORTS NOW AI時代、脆弱性報告の質はどうなのか curl は HackerOne でセキュリティ報告を受けていました（公開バグバウンティ）。 報告が届く間隔（1 週間＝168 時間を 100%） AI 以前 そのうち、本当に脆弱性だった割合 168 時間・週 1 件 15.5% 15% 2025 年 48 時間・2 日に 1 件 2026 年 18 時間・1 日に 1 件以上 間隔が詰まるほど、受け手は手を止められません。 5% 2024 年 2025 年 2026 年 AI 以前 スロップ期 AI 以前を超えた 「ほぼすべての報告が、程度の差はあれ AI を使っている」— 質が落ちたのではなく、書き手が替わった それでもたかだか15%だなんてポンコツ具合も人間に近い、これが2026年 出典: Daniel Stenberg（curl）「High-Quality Chaos」2026-04-22 ／「What the bliss taught us」2026-08-03 7 / 26
10. SECTION 01 — RECAP ここまで（爆発）の要点 1 量が爆発した Critical+High が 8 か月で前年の通年を +41%。母数は 3 年で 3 倍 2 絞っても、漏れる C+H だけで 28,120 件。悪用の 1 割強は、その網の外 3 情報源が増えた NVD だけじゃない。OSV・VulnCheck・CISA KEV・EPSS 4 報告の主役が替わった 高頻度。質は AI 以前に戻り、書き手が AI になった 見つかる量は増えた。次は、その情報をどう「使う」か。 8 / 26
11. 02 THE CRISIS 脆弱性情報 活用の危機 増えた情報が、そのままでは使えない。 9 / 26
12. WHAT WAS EXPLOITED CISA KEV で悪用が確認された 1 割強は、Critical・High ではない CISA KEV 全 1,685 件の深刻度内訳 深刻度だけでは切れない 34.7% 52.8% Critical 585 High 890 Medium 203 12.0 % 悪用の 12%（210 件）は Critical でも High でもない Low 7 その Critical+High も、2026 の 8 か月 で 28,120 件 KEV に追加された年で切ると 多すぎるのに、絞れば漏れる。 2025 年 計 245 件中 Critical+High 209 件（85%）／ 外 36 件（15%） 2026 年 計 201 件中 Critical+High 178 件（89%）／ 外 23 件（11%） 出典: CISA KEV 全 1,685 件（NVD API 2.0 hasKev、2026-08-28 取得）を自前集計。深刻度は CNA 付与を優先し、無ければ NVD。年は KEV へ追加された日で切った。VulnCheck KEV はさらに広い 10 / 26
13. NESTED, BUT LEAKY 世の中のソフトウェアから、悪用まで — 外は入れ子、内は漏れる 世の中のソフトウェア 脆弱性が潜在するソフトウェア CVE 番号すら付いていないものを含む CVE Critical・High PoC VulnCheck KEV 悪用シグナル（PoC・VulnCheck・EPSS・KEV）は、入れ子の部分集合ではない。 CISA KEV 125 件のうち 14 件は、Critical・High の外にはみ出す。 外側は入れ子で絞れる。だが悪用は、その枠から漏れる。 出典: 外側の層は概念図（実数は各スライド）／ CISA KEV の 14 件が Critical・High の外なのは本章の自前集計 11 / 26
14. WHY, AND WHAT INSTEAD Log4Shell 1 件に CPE が 396 件。log4j 自身は 7 件だった CPE — 登録されたパッケージ名 purl — 置かれている”場所"で指定 — 名前が製品の外側にある。 — 辞書に登録する工程が要らない 手元の資産名と対応づける「名寄せ」が要る — 採用時に記録すれば、名寄せが起きない — 綴りが揺れると当たらない！ だから辞書は 1 冊、中央が一手に引き受ける pkg:maven/…/log4j-core@2.14.1 — GHSA・OSV・Snyk・Trivy は purl 系 — 商用・組込みは座標が無く、CPE が残る 情報が足りないのではない。照合できないのだ。突合の軸を、先に決める。 CPE は 2007 年に MITRE が定めた命名規約。purl は 2017 年に提唱されたパッケージ座標の記法 12 / 26
15. ONE CVE, 396 NAMES Log4Shell 1 件が、396 の製品名にばらけた cloud insights ontap tools webex meetings server unified sip proxy firepower 4140 cloudcenter firepower 4120 prime service catalog comos NetApp firepower 1140 rhythmyx ucs central synchro 4d firepower 4115 snapcenter log4j network assurance engine capital firepower 1010 nexus dashboard cx cloud agent crosswork data gateway firepower 1120 firepower 4125 ucs director finesse smart phy firepower 2120 automated subsea tuning firepower 4112 firepower 2140 sd-wan vmanage synchro Siemens firepower 4150 dna center xcode fxos broadworks dna spaces unity connection firepower 4145 emergency responder cloud connect firepower 4110 cyber vision Cisco Intel cloudcenter suite identity services engine datacenter manager nexus insights firepower 2130 firepower 1150 dna spaces connector firepower 2110 cloudcenter suite admin fog director brocade san navigator paging server iot operations dashboard unified computing system ucs central software debian linux fedora system studio mobility services engine firepower 9300 wan automation engine virtual topology system 「log4j を直した」で終わらない。組み込んだ製品ごとに、名前も対応も分かれる。 出典: NVD CVE API 2.0（CVE-2021-44228 の CPE 適用性、2026-08-29 取得）。cpeMatch 396 件・ユニーク製品 166・ベンダー 12 社。log4j 本体は 7 件 14 / 26
16. 03 THE FIX GAP アップデートが無いか、不備のある脆弱性情報がある メンテナが追いつかない。AI で直すと、別の問題が増える。 15 / 26
17. FINDING FAST, FIXING SLOW 1 件あたりは速く直せるのに、片づく総数は 46% 減った HackerOne が、自社プラットフォームの数字を公表しました。 2026 年 3 月までの 12 か月で、どう動いたか 提出された脆弱性 +76%(指摘増) 重いものから落ちている Critical の修正は 73% 速くなった 修正までの平均時間 −80%(高速化) 1 か月に片づいた件数 −46%(解決率減） 未解決のバックログ まだ直っていない 21 倍(積み残し増) なのに解決率は 83% 超 → 40% 未満へ 雑な報告のせいとはいえない 有効な報告の割合は、ほぼ一定 手が回る分だけ選んで直している ボトルネックは、見つけるから、直して片づけることに移った。 出典: HackerOne 公式ブログ「Finding Fast, Fixing Slow: The Rising Exposure Debt」（2026-05-06）。数字はすべてプラットフォーム全体・2026 年 3 月までの 12 か月 16 / 26
18. THE FIX GAP 報告が受理されても、7 件に 1 件は直った版が存在しない 14.9% 7 件に 1 件は、直った版が無い OSS パッケージの勧告 47,420 件のうち 7,042 件。 報告を受け取ったのは、部品を配っている側です。 エコシステム別「直った版が無い割合」（目盛りは 30% まで） crates.io 26.0% npm 22.0% Maven 16.1% Packagist 13.3% Go 12.7% PyPI 12.1% 見つけて報告しても、直った版が無ければ、使う側は動けない。 出典: OSV.dev の全ダンプ（2026-08-27 取得）を自前集計。母集団は withdrawn を除く勧告。悪意あるパッケージ（MAL-）は構造上すべて修正なしになるため別枠にした 17 / 26
19. AND THE FIX AI によるパッチ有効率は 26% 実在する脆弱性 6 件に、2 つの推論モデルでパッチを 6,080 回書かせた実験より AI が生成したパッチ 6,080 件の判定（合計 100%） 完全に直り、挙動も変わらなかった 26.0% 直ったが、アプリの挙動が変わった 20.1% 直っていない／新しい脆弱性を作った 53.9% 使えたのは 26% だけ。半分以上は、直らないか新しい穴を作る。 出典: 1Password Off-By-1 Labs 調査（Black Hat USA 2026）。実在する 6 件の CVE に対する AI 生成パッチ 6,080 件を検証 18 / 26
20. THE DEV ENVIRONMENT 「AI エージェントなど開発補助の仕組みが、 プロンプトインジェクションの入口になっている」 AI に任せる仕組みが、そのまま攻撃の入口です。 issue に偽のエラーを書く 復旧処理だと誤認する CI の権限で環境変数を読む 同じ issue に書き戻す 「説明の読み取りに失敗しました 本物のエラーだと解釈し、 GITHUB_TOKEN などが エージェント自身の更新機能で 。実行するコマンドを説明として 承認を求めずに実行してしまう プロセスの環境に載っている 本文に書き込む。攻撃者は読む もう一度お試しください」と偽装 し、続けてコマンドを置く インジェクションは防ぎきれない前提で、権限設計の側で断つ — エージェントに CI のシークレット・書き込み権限を渡さない — 外部から書ける文字列を、確認なしに実行させない（サンプル設定のまま配らない） — 読ませても、CI のシークレットに手が届かなければ被害は止まる 出典: GMO Flatt Security（RyotaK 氏）claude-code-action の調査（2026-06 公開）／ Black Hat USA 2026 の発表とベンダー勧告（CVE-2026-54316・CVE-2026-12537 ほか） 19 / 26
21. 04 SO WHAT じゃあ、どうする？ 明日から変えられるところに、絞る。 20 / 26
22. WHAT GETS EXPLOITED AIツール使えばいい？ついに悪用シナリオもでたよ AI 基盤で実際に出た脆弱性（2026） AI侵害手順が ATT&CK に載った — C0062 Langflow — 重要 API が無認証 AI エージェントが戦術作業の 8〜9 割を実行（人間は ChromaDB — 認証前のコード実行 SGLang — 検証なしの pickle.load 承認だけ） 使われた弱点は従来型 — 設定ファイルの認証情報・公 開アプリの SSRF Streamlit — 未認証 SSRF … ＝手順の各ステップは、在来のハードニングで断てる ＝プロンプトインジェクションではない。 認証不備・RCE・デシリアライズ＝従来型の欠陥 資格情報をファイルに置かない／外向き入力を検証／速度 異常を監視 NEW: 手元の新しいLLMモデルなどAIツールが、新たな「侵害ツール」にされる 出典: 各 CVE は cvelistV5／OSV.dev（2026）／ MITRE ATT&CK Campaign C0062・Anthropic 公式レポート（2025-11） 21 / 26
23. WHAT TO HOLD 明日から変えられる、その 1 1 修正の優先順位を、決定する仕組みを持つ — CVSS の単独閾値をやめる（全 CVE の中央値は 7.10。7 以上で切ると半分が残る） — PoC の有無で切らない。攻撃されたものの 55% は PoC の記録が無い — 手作業（継続性と網羅性）やAIまるなげ（確率論的ツール）では追いつかない。 — SCAは、リスク情報源としてCVE、EPSS、KEV、メンテナのレピュテーションなどの広いイン テリジェンスを得る 「重大かどうか」だけでは、順番は決まらない。 22 / 26
24. WHAT TO HOLD 明日から変えられる、その 2 2 実際に使っている部品に、直った版があるかを見る — 7 件に 1 件は、直った版そのものが存在しない — SBOM があっても、更新先が無ければ計画は立たない — SCAは自社コードの分析ができるものを使う。パッケージリストでは届かない。 — 自社の側をベースに考える：横断的に使っているか・到達できるか・悪用されているかを 重ね、優先順位を決めたり、ハイリスクを排除する仕組みを持つ 直せる版があるか。そこまで見て、はじめて計画になる。 23 / 26
25. WHAT TO HOLD 明日から変えられる、その 3 3 直す力そのものに、投資する — 技術投資は組織面での投資で裏づけられるべき。 SCAやASPMなど各種情報やインテリジェンス可視化は買えるし人件費コスト削減にはなるが、 自社固有の知識は外から買えない — 開発・運用エンジニアの知見を上げる。パッチを選び承認する決定論強化 (AI判断は確率論)。 （回帰・挙動・根本原因・解決手法 をおさえる / 訓練にも投じないと落ちる） — プロセス、ポリシーを少なくとも年1回で調整し、品質確保プロセスの調整を試みる。 各種診断（脆弱性診断、グレイボックステストなど）を、自社の発見力調整に活かす。 AIで楽になる話ではない。見分けて直す力が要る。SCAだけでなく組織の欠陥もアップデートすべき(SAMM) 24 / 26
26. KEY TAKEAWAY 今日の要点 — 発見よりも受け入れ側にアジェンダが移った 見つける側も攻撃側も AI で速くなった。量は爆発している — 有効な情報源も物差しも増えた CVE だけでは足りない。重要度だけで絞れば漏れる——重ねて順番を決める — ソフトウェアを適切に、迅速に修正する力が足りない 7 件に 1 件は直った版が無い。AI のパッチは 26% しか使えない — 投資先は「直す力」だろう 優先順位・直った版の確認・直す力。ここは自社、人にしかできない 自分のシステムは、自分で守りきる。 25 / 26
27. 脆弱性発見数は増えた。 受け入れて検証し、修正する側は、追いついていない。 AIに全振りできる話ではない。 いまこそ判断力に投資しよう。 岡田 良太郎 riotaro@rsrch.jp · アスタリスク・リサーチ 出典：CVE Program cvelistV5／CISA KEV／VulnCheck／EPSS (FIRST)／MITRE ATT&CK v19.2／ENISA Threat Landscape 2025／OWASP AISVS 1.0・AIMA・Top 10:2025・Top 10 for Agentic Applications・MCP Top 10・Agentic Skills Top 10／Black Hat USA 2026／DARPA AIxCC ほか 26 / 26
28. SNSか、函館 で！ – Hardening 2026 Agentic Collapse 函館 2026/10/6 – 8 – OWASP / サプライチェーンセキュリティ – セキュリティテスト（DAST・IAST・SBOM） – Hardening Project — ディフェンダー養成 – 登壇・寄稿の声かけも大歓迎 linkedin.com/in/riotaro/ ／ AirCampus（BBT 受講生向け） BBT Output Gym ／ 2026.08 ／ 岡田良太郎 p.39