「なんか〇〇ライブラリで脆弱性あるみたいなんだけど。。。」から始める脆弱性対応 / First Steps in Vulnerability Response

2026/04/30 に開催された関ジャバで投影した資料です。
当日から一部変えている部分はありますが、大体一緒です。
気になる点や問題点あればご連絡ください。

Transcript

1. 「なんか〇〇ライブラリで 脆弱性あるみたいなんだけど。。。」 から始める脆弱性対応 2026-04-30 関ジャバ'26 4月 BABY JOB株式会社 浅野 正貴 (@mackey0225)
2. 脆弱性対応について 自己紹介 名前：浅野　正貴 所属：BABY JOB株式会社 最近はシステムより組織のことが多め X: @mackey0225 人類が一番脆弱な存在だと思っています
3. 脆弱性対応について おしながき • そもそも「脆弱性」とは？ • 自分のとこでは、こうやっている ◦ 対応の流れ（検知・リスク管理） ▪ 情報の集め方・見つけ方 ▪ CVE、CVSS スコアについて　など • 取り組みを通して意識していること • まだできていないこと（現状の課題）
4. そもそも「脆弱性」とは？
5. 脆弱性対応について そもそも「脆弱性」とは？ 一般的な意味として、 • 場所・物・アイデアなどに対して、攻撃や批判を容易に受けやすく なっている性質 • 人に対して、容易に危害を加えられたり、心身を傷つけられたりしう る状態 転じて、 OS、ソフトウェア、ハードウェアなどのコンピュータシステムにおける 「セキュリティ上の欠陥」や「弱点」 を指す。
6. 脆弱性対応について 脆弱性の例 • SQL インジェクション対策（プレースホルダの利用など）の漏 れによる情報漏洩 • SSRF の脆弱性を突かれ、クラウドリソースのクレデンシャル が奪取された • CSRF トークンの検証を行っておらず、Cookie ベースのセッ ション管理のみに依存していたため、CSRF 攻撃が発生した • 脆弱性のある OSS ライブラリを放置した結果、攻撃を受け DoS 状態に陥った
7. 脆弱性対応について 脆弱性の例 • SQL インジェクション対策（プレースホルダの利用など）の漏 れによる情報漏洩 • SSRF の脆弱性を突かれ、クラウドリソースのクレデンシャル が奪取された • CSRF トークンの検証を行っておらず、Cookie ベースのセッ ション管理のみに依存していたため、CSRF 攻撃が発生した • 脆弱性のある OSS ライブラリを放置した結果、攻撃を受け DoS 状態に陥った 今日の話はここに関連した話
8. 脆弱性対応について 余談：安全なウェブサイトの作り方 AI 全盛時代でも教養として学んでおきたい https://www.ipa.go.jp/security/vuln/websecurity/about.html
9. 脆弱性対応について 何かを利用している限り責任を伴う • OSS を使わずにシステムを作るのは現代では至難の業 ◦ OSS は原則「無保証」「自己責任」 • 商用ライセンスならお金で万事解決！...とも言えない ◦ ベンダーとの SLA 次第 ◦ 何かしら調整事項は発生する • 不具合や脆弱性への対応について能動的な行動が必要 • With great power comes great responsibility.
10. 自分とこでは、こうやっている
11. 脆弱性対応について 脆弱性への対応の流れ 情報収集 リスク対応 リスク分析 リスク評価 📡 🛠 🚥 🔬
12. 脆弱性対応について 先の流れはリスクマネジメントのガイドライン（JIS Q 31000:2019）のプロセスの手順を参考としている 参考：JIS Q 31000:2019 リスクマネジメントプロセ ス https://kikakurui.com/q/Q31000-2019-01.html
13. 脆弱性対応について 脆弱性への対応の流れ 情報収集 リスク対応 リスク分析 リスク評価 📡 🛠 🚥 🔬
14. 脆弱性対応について 情報収集 • 受動的 ◦ JVN iPedia を RSS フィードで Slack に流す ◦ GitHub Dependabot のアラートで見る • 能動的 ◦ SNS のタイムラインで盛り上がっているやつを確認 ◦ セキュリティに強いアカウントやブログをフォロー
15. 脆弱性対応について JVN iPedia を RSS フィードで Slack に流す • JVN とは ◦ Japan Vulnerability Notes の略 ◦ 日本におけるソフトウェアなどの脆弱性関連情報や対策情報を提 供しているポータルサイト ◦ JPCERT/CC と IPA で共同運営 ◦ https://jvn.jp/index.html • JVN iPedia とは ◦ 脆弱性対策情報のデータベースのこと ◦ RSS フィードがあるので、Slack に垂れ流せる ◦ https://jvndb.jvn.jp/
16. 脆弱性対応について GitHub Dependabot のアラートで見る • Dependabot で利用しているライブラリに関するマルウェ アと脆弱性に関するアラートを出してくれる • コードベースにあるパッケージ管理ファイルやDocker ファイルを参照して教えてくれる
17. 脆弱性対応について SNS のタイムラインで盛り上がっているやつを確 認 • よくやるやつ • バズるにはバズるなりの理由がある • （仕事中についったーをやる理由を自己正当化している）
18. 脆弱性対応について セキュリティに強いアカウントやブログをフォロー • これもよくやるやつ • アカウント ◦ （個人のアカウントとかは当日の投影のみにしまし た。なんとなくの配慮のため。ごめん） • ブログ ◦ セキュリティ系の会社のテックブログとか
19. 脆弱性対応について 脆弱性への対応の流れ 情報収集 リスク対応 リスク分析 リスク評価 📡 🛠 🚥 🔬
20. 脆弱性対応について リスク分析 • 対象の脆弱性の内容を確認 ◦ CVE レポートの内容確認 ◦ CVSS スコアの確認と判断 ◦ PoC の有無 • 対象のライブラリやソフトウェアの利用状況確認 ◦ どのバージョンを使用しているか ◦ どの環境で利用しているか ◦ どのような用途で使用しているか
21. 脆弱性対応について CVE とは • Common Vulnerabilities and Exposures の略 • https://www.cve.org/ • 各システムやアプリケーションの脆弱性に対して MITRE 社が採番している識別子(CVE-ID)やその活動全体を指す ◦ アメリカ政府の支援で活動 • 公開されている脆弱性を特定、定義し、カタログ化 • 各研究機関やベンダーとの連携を行いながら運営 ◦ 日本では JPCERT/CC が中心になっている
22. 脆弱性対応について 参考：CVE の組織図 https://www.cve.org/ProgramOrganization/Structure
23. 脆弱性対応について 参考：JPCERT/CC • Japan Computer Emergency Response Team Coordination Center の略 • https://www.jpcert.or.jp/ • インシデント等の報告の受け付け、対応の支援、発生状況 の把握、手口の分析、再発防止のための対策の検討や助言 • 国内・国外の CSIRT や SOC の橋渡し・窓口的な存在
24. 脆弱性対応について 余談：CVE パートナーの例 日本においては 15 団体がパートナー(CNA)となっている。 https://www.cve.org/PartnerInformation/ListofPartners
25. 脆弱性対応について 余談：CVE パートナーの例 日本においては 15 団体がパートナー(CNA)となっている。 https://www.cve.org/PartnerInformation/ListofPartners
26. 脆弱性対応について CVE の発足の経緯 • 1999年1月に MITRE 社のDavid E. Mann氏とSteven M. Christey氏によって発表したホワイトペーパーがきっかけ ◦ 『Towards a Common Enumeration of Vulnerabilities』 • その後、19名のメンバーを委員会として発足し、321件の CVE レコードを作成、1999年9月に正式に公開された
27. 脆弱性対応について CVE 以前の課題 昔はベンダーや研究機関がそれぞれ独自のデータベースを持 ち、同じ脆弱性に対して異なる名称を付けていた。 • 異なるツールの結果を比較・統合することが困難、手作業 による確認が必要 • どのツールがどの程度の脆弱性を網羅しているかを客観的 に評価できない
28. 脆弱性対応について CVE レコードの概要 • CVE ID：フォーマット（CVE-<西暦>-連番） • CNA：CVE IDを採番した機関 • Description：脆弱性の内容 • CWE：脆弱性の種類（後述） • CVSS：脆弱性のスコア（後述） • Product Status：影響の受けるバージョンなどが記載
29. 脆弱性対応について 余談：各機関で説明の粒度が違う 同じ脆弱性を異なる機関が独自にまとめている。 例：Log4J（CVE-2021-44228） • CVE：https://www.cve.org/CVERecord?id=CVE-2021-44228 • NIST：https://nvd.nist.gov/vuln/detail/CVE-2021-44228 • JVN：https://jvndb.jvn.jp/ja/contents/2021/JVNDB-2021-0 05429.html （個人的には、NIST のページで確認することが多い）
30. 脆弱性対応について CWE とは • Common Weakness Enumeration の略 • 一般的な脆弱性タイプをまとめたリスト ◦ 現時点で 944 種類がリストアップされている • MITRE が中心になって策定されている • 現在のバージョンは 4.19.1 • https://cwe.mitre.org/index.html
31. 脆弱性対応について CVSS スコアとは • Common Vulnerability Scoring System の略 • 脆弱性の深刻度を 0.0〜10.0 のスコアで定量的に評価する国 際的な業界標準 • 2005年にアメリカのNIAC(National Infrastructure Advisory Council)が考案・作成 • その後、管理をFIRST(Forum of Incident Response and Security Teams)に移管 • 現在 v4.0 が最新 • https://www.first.org/cvss/
32. 脆弱性対応について CVSS スコアの仕組み • 大きくは４つのグループの評価項目がある ◦ Base Metrics（基本） ◦ Threat Metrics（脅威） ◦ Environmental Metrics（環境） ◦ Supplemental Metrics（補助） • スコアの算出には、どのグループの組み合わせを使ったかも併せて表記す る ◦ Base を基本として、Base のみであれば、CVSS-B とする ◦ さらに Threat と Environmental の組み合わせで、CVSS-BE、 CVSS-BT、CVSS-BTE を定義する • （自分はもっぱら、Base しか見かけないな）
33. 脆弱性対応について CVSS スコアの仕組み（Base Metrics の評価基 準） • Exploitability Metrics：攻撃がどれくらい容易に行えるかを評価 ◦ Attack Vector : どこから攻撃可能か（ネットワーク、隣接ネットワー ク、ローカル、物理） ◦ Attack Complexity : 攻撃を成功させるために、攻撃者が制御できない 要因を回避する難易度（低、高） ◦ Attack Requirements : 攻撃を実行するために必要な、システム側の特 定の条件（なし、あり） ◦ Privileges Required : 攻撃に必要な権限（なし、低、高） ◦ User Interaction : 攻撃成功にユーザーの操作が必要か（なし、パッシ ブ、アクティブ）
34. 脆弱性対応について CVSS スコアの仕組み（Base Metrics の評価基 準） • Vulnerable System Impact：脆弱性が存在するシステムそのものへの影響 を評価 ◦ Confidentiality : 情報漏えいの影響度（なし、低、高） ◦ Integrity : 情報改ざんの影響度（なし、低、高） ◦ Availability : システム停止などの影響度（なし、低、高） • Subsequent System Impact：脆弱なシステムを踏み台にして別のシステム に影響を及ぼす場合の影響度を評価 ◦ Confidentiality : （なし、低、高） ◦ Integrity : （なし、低、高） ◦ Availability : （なし、低、高）
35. 脆弱性対応について CVSS スコアの仕組み https://www.first.org/cvss/v4.0/specification-document
36. 脆弱性対応について 具体的なスコアの例（CVE-2026-7426） https://www.cve.org/CVERecord?id=CVE-2026-7426
37. 脆弱性対応について 具体的なスコアの例（CVE-2026-7426） https://www.cve.org/CVERecord?id=CVE-2026-7426 この Vector String をコピーする 「CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N」
38. 脆弱性対応について 具体的なスコアの例（CVE-2026-7426） コピーした Vector String を以下の URL の末尾につけてアクセスする。 https://www.first.org/cvss/calculator/4.0# 今回の場合、 https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:P/P R:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N にアクセスする。
39. 脆弱性対応について 具体的なスコアの例（CVE-2026-7426） https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/S I:N/SA:N
40. 脆弱性対応について 具体的なスコアの例（CVE-2026-7426） https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/S I:N/SA:N 要は、二郎やスタバと同じ
41. 脆弱性対応について PoC やスキャナーの有無 • 規模の大きな脆弱性だと、PoC コードやスキャナーも公開 されていることがある ◦ 大体はパッチが公開されてから、CVEレコードと併せ て公開される • 脆弱性の仕組みの把握や自分の環境への影響有無を確認す ることが出来るので、目を通すのが吉
42. 脆弱性対応について 参考：スキャナーの例（Terrapin Attack） https://terrapin-attack.com/
43. 脆弱性対応について 参考：スキャナーの例（Terrapin Attack） https://github.com/RUB-NDS/Terrapin-Scanner
44. 脆弱性対応について 対象のライブラリやソフトウェアの利用状況確認 自組織の状況確認も並行して必要 • どのバージョンを使用しているか ◦ 明示的に指定しているかどうか、依存関係の有無など • どの環境で利用しているか ◦ クラウドインフラ、開発メンバーの端末など ◦ どのようにインストール適用しているかも併せて確認 • どのような用途で使用しているか ◦ ライブラリのすべての機能を使っているわけではない
45. 脆弱性対応について ウチでの利用状況確認 • ある程度影響度合いが大きい場合、開発組織全体で強制力 を働かせて確認する • 場合によって、コーポレートITメンバーにも協力要請 • 少なくとも、対象のライブラリの利用の有無、バージョン だけはリスク評価以前に行うことが多い
46. 脆弱性対応について 脆弱性への対応の流れ 情報収集 リスク対応 リスク分析 リスク評価 📡 🛠 🚥 🔬
47. 脆弱性対応について • すぐパッチ適用できるなら、分析など考えずに実施する ◦ 事前検証が必要な場合や本番環境への影響がある場合は計画して対応する • 対応優先度を高いと判断する条件 ◦ 攻撃に関して容易に実現できる場合 ◦ いんたーねっとで盛り上がっている場合 ▪ 一種のバイアス（バンドワゴン効果、同調圧力）は意識しながら判断 • 対応優先度を低いと判断する条件 ◦ 脆弱性があっても別の仕組みで防げている場合（AWS の機能でブロックなど） ◦ ライブラリは影響のあるバージョンだけど、対象の機能を使っていない場合 ◦ パッチ適用が現時点でまだ公開されていない場合 集めた情報を整理し、対応について判断する
48. 脆弱性対応について 脆弱性への対応の流れ 情報収集 リスク対応 リスク分析 リスク評価 📡 🛠 🚥 🔬
49. 脆弱性対応について リスク評価に応じて、対応を進める • 優先度が高いものは「リスク回避を早く実施」 ◦ 各プロダクトのエンジニアに対応を委ねるが、納期も 含めてプロダクトバックログアイテムに突っ込む • 優先度が低いものは「期限を決めてリスク回避」もしくは 「リスク受容しながらも手空きでリスク回避」 ◦ 一ヶ月以内にやると決める　など ◦ 様子見・塩漬けも場合によってはあり
50. 取り組みを通して意識していること
51. 脆弱性対応について • 判断は主体的かつ協調的に進める • インシデントではなく、リスクとして捉える 取り組みを通して意識していること
52. 脆弱性対応について • チームや組織によるが、脆弱性に対しては主体的に取り組 まないとおざなりになりがち • 強制力や強権を振りかざしたとしても、プロダクトにはプ ロダクトの進め方や論理があるので、一定の協調性も必要 • ケース・バイ・ケースになる部分が多いので、考え方が偏 らないように対話をすることを心がける 判断は主体的かつ協調的に進める
53. 脆弱性対応について • 脆弱性があること自体はインシデントではない • あくまでも、発生確率や考えうる被害を持ってしてリスク と捉える • 対応に際しては、必死になりすぎない、自分を追い込まな いようにする インシデントではなく、リスクとして捉える
54. まだできていないこと（現状の課題）
55. 脆弱性対応について 現時点でこれからのこと • SBOM の作成・管理 • クラウドベンダーのサービスの利活用 ◦ AWS Systems Manager Patch Manager など • 計画的なライブラリの更新ルール ◦ マイナー・パッチは積極的に実施する？ ◦ メジャーは予め決めておく？
56. まとめ
57. 脆弱性対応について まとめ • 脆弱性の情報は与えられるのではなく、掴みにいく • CVE の情報を中心に一次情報も確認し、場合によっては世 間の反応も拾っておく • 対応を進めるうえでは、あくまでも自組織・自環境でのリ スクを評価する • 対応進める際には、インシデントではなくリスクと捉え、 ケース・バイ・ケースの判断をおこなう
58. ありがとうございました