レバテック開発部の松浪です。
エンジニアの皆さん、日々の脆弱性への対応お疲れ様です。
え？脆弱性の対応してないって？
以前、「システムをメンテナンスしてますか？」というタイトルでZenn記事を書きました。
そこでライブラリのバージョンアップを怠ってはいけない理由の1つとして、
セキュリティ上の脆弱性を突かれて攻撃される
というのを挙げました。
脆弱性は個人情報の漏洩やサービス停止に陥るきっかけとなる非常に危険な存在ですが、一方で脆弱性があってもシステムは正常に動作するので、放置されがちな存在でもあるなぁと感じています。
この記事では、脆弱性とは何かを理解して、どのように数多ある脆弱性を管理すればよいのか考えてみます。
この記事で扱う脆弱性の定義
はじめに、この記事で扱う脆弱性を定義しておきます。
脆弱性（Vulnerability）
CVE番号が割り振られたライブラリ・フレームワーク・OS内のセキュリティ上の欠陥を指します。
CVE番号とは？
CVE番号は脆弱性を一意に識別するための識別子です。米国の非営利団体であるMITRE（マイター）が管理・採番しています。
トランプ政権での政策により資金提供が止まって存続が危ぶまれましたが、今も運営が続けられています。よかった...
CVE番号が割り当てられたということは、世界中に脆弱性の情報が共有され、その存在が公に認められて、悪用される可能性があることを意味します。
脆弱性の件数
NISTの脆弱性データベースを見ると、脆弱性の数は年々増加傾向にあります。
2024年では約4万件もの脆弱性が発見されていたことがわかります。
脆弱性の危険性
IPAの情報セキュリティ10大脅威 2025を見ると、システムの脆弱性を突いた攻撃が第3位となっており高い順位に位置しています。
2024年に実際に発生したセキュリティ事故やサイバー攻撃をもとにランキングが作成されているので、それだけ脆弱性が脅威になり得ることが伺えますね。
脆弱性の深刻度を示す指標
CVSS
脆弱性の深刻度を示す指標として代表的なのはCVSSです。
CVSS(Common Vulnerability Scoring System)は、脆弱性の深刻度を定量的に評価する指標であり、0.0～10.0 の範囲で示されます。
CVSSでは次の3つの基準で脆弱性を評価します。
- 基本評価基準(Base Score Metrics)
- 脆弱性そのものの特性を評価する基準
- 時間の経過や利用環境の違いによって変化しない
- 現状評価基準(Temporal Score Metrics)
- 脆弱性の現在の深刻度を評価する基準
- 脆弱性への対応状況に応じ、時間が経過すると変化する
- 環境評価基準(Environmental Score Metrics)
- システムを利用するユーザの利用環境も含め、最終的な脆弱性の深刻度を評価する基準
- ユーザの利用環境によって変化する
CVSSのスコアは当てになる？
公表されたCVSSのスコアが高いからといって、めちゃくちゃ危険な脆弱性か...と言うと、実はそうでもなかったりします。
正確には、自社のシステムにとって「本当に深刻な脆弱性」かどうかは、公表されているCVSSのスコアではわからないためです。
例として、Next.jsで見つかった認証をバイパスしてしまう脆弱性CVE-2025-29927のスコアを見てみます。
2025/06時点で、Base Scoreは「9.1 CRITICAL」となっています。
認証をバイパスされてしまう、と聞いただけでも非常に危険に思えますね。
では「9.1 CRITICAL」の部分をクリックして、CVSSの評価結果を見てみると...
現状評価基準と環境評価基準はどちらも未評価(Not Defined)になっています。
つまり、公表されているスコアでは組織において本当に危険かどうかが判断できないわけです。
EPSS
EPSS(Exploit Prediction Scoring System)も脆弱性の深刻度を定量的に評価する指標で、30日以内に脆弱性が悪用される確率を0%から100%の範囲で算出します。
スコアを確認したい場合は、こちらからダウンロードできます。
EPSSのスコアは当てになる？
正直、何とも言えません。。
と言うのも、スコアの算出には機械学習が利用されており、その算出過程は完全にブラックボックスなためです。
また、「30日以内に脆弱性が悪用される確率」は日次で計算されている関係で、スコアは日によって変動します。今日はスコアが高くても明日はスコアが下がっているかもしれません。
KEV
KEV(Known Exploited Vulnerabilities)は、CISA(アメリカ合衆国サイバーセキュリテ
ィ・社会基盤安全保障庁)が公開している実際に悪用が確認された脆弱性のリストです。
こちらからダウンロードできます。
KEVは「悪用されたことがある」という事実を重視しており、煩わしいスコアの計算はありません。
実際に悪用されている＝深刻度が高い、と判断できます。
KEVは当てになる？
こちらも正直、何とも言えません。。
実際に悪用された脆弱性の内、一部しか掲載されていないという指摘があるらしく、網羅性が十分とは言えないようです。
また、仕組み上、KEVに掲載されるまでにはタイムラグが必ず発生します。
試しにNext.jsで見つかった脆弱性CVE-2025-29927を検索してみると、CVSSとEPSSでは深刻度が非常に高い評価となっていますが、 KEVには掲載されておらず実際には悪用されていない、と判断できます。
SSVC
SSVC(Stakeholder-Specific Vulnerability Categorization)は脆弱性の深刻度を評価する手法で、脆弱性を3つのステークホルダーの視点から、4つの決定木の分岐条件で深刻度を評価して、4つの対応方針に分類します。
- ステークホルダー
- デプロイヤー: 脆弱性の対応としてパッチ適用を実施する組織、ライブラリの利用者
- サプライヤー: 製品開発ベンダとしてパッチを提供する組織、ライブラリの提供者
- コーディネーター: 脆弱性情報を統制する組織、脆弱性の管理者
- 決定木の分岐条件
- Exploitation: 現時点での脆弱性の悪用状況
- Exposure: 公開範囲(外部からアクセス可能かどうか)
- Automatable: 攻撃者にとっての攻撃の有用性
- Human Impact: 安全性や業務遂行への影響
- 対応方針
- defer: 対応不要
- scheduled: 定期メンテナンス時に対応
- out-of-cycle: できるだけ早く対応
- immediate: 通常業務を止めてでも迅速に対応
SSVCの実施を支援してくれるツールが公開されているので、脆弱性を評価する際は利用してみましょう。
SSVCのスコアは当てになる？
SSVCは脆弱性を自身で評価して対応方針を決めるため、そのまま意思決定に直結します。
ただ、脆弱性を評価するには、ある程度のセキュリティの知識や自社のシステム環境の理解が必要なため、結果は評価者のスキルに左右されます。
LEV
LEV(Likely Exploited Vulnerabilities)は、2025/05にNISTが提唱した新たな指標で、「実際に攻撃される可能性が高い」脆弱性を過去のデータに基づいて深刻度を評価します。
EPSSとKEVの欠点を補完して、より精度の高い評価ができると期待されています。
LEVのスコアの算出式はこちらに記載があります。簡易版と詳細版の2つあります。
簡易版
詳細版
はい。よくわからないですね。
LEVのスコアは当てになる？
2025/06時点で、NISTはまだ精度検証の段階であり実運用されていません。
しかし、より現実的な評価指標となると期待されています。
結局どのスコアを信頼すればよいの？
個人的にはSSVCが良いと思います。
理由としては、脆弱性が本当に深刻かどうかは開発しているシステムの環境により異なるためです。
例えば、CVSSでは深刻とされている脆弱性CVE-2025-29927も、そもそも認証認可の機能を持たない静的なサイトであれば深刻度は下がります。
IPAでもSSVCもしくは3つの基準すべてを考慮したCVSSのスコアが望ましいと書かれています。
脆弱性の管理
ここで言う脆弱性の管理は、CVE番号が付与された脆弱性を検知して、評価して、対処する、という一連の活動を指します。
脆弱性の検知
新しい脆弱性が公表されても検知できなければ対処できません。
人の目で見張るのは難しいのでツールを活用すべきです。
世の中には有償無償の様々な脆弱性管理ツールがあるので、会社と相談の上でツールを活用しましょう。
弊社では、GitHubのDependabotAlertやNewRelicのSecurityRXなどを活用しています。
SecurityRXの活用事例
NewRelicのSecurityRXを使えば稼働中のどのシステムに対して、どの脆弱性が潜在しているかダッシュボード上で確認することができます。
追加の費用がかかりますが、OSに含まれる脆弱性も検知できます。
Slackで通知するように設定しておけば、新たな脆弱性が公表された際、かなり早い段階で脆弱性の存在を把握できます。
脆弱性の評価
脆弱性を検知したら、自社にとって本当に危険かどうか判断して対処を決めます。
上記の脆弱性の深刻度の指標で記載した通り、CVSSのスコアをただ鵜呑みにせず、SSVCなどを活用して自社のシステムにとって深刻かどうか評価するのが良いと思います。
SSVCをやってみる
例として、ツールを利用して、脆弱性CVE-2025-29927の深刻度を評価してみます。
立場はデプロイヤー（開発者）、システムではクレジットカードなどの決済情報は扱っていないものとします。
- Exploitation
- KEVのリストにはなく悪用された実績がないが、再現方法は見つかっているため poc
- Exposure
- フロントエンドであり、公開しているサイトため open
- Automatable
- 攻撃を自動化しやすいため yes
- Human Impact
- 直接の物理的・経済的な被害はないので状況的安全への影響は none
- 一時的にシステムを止めることはあっても事業は継続できると思われるので crippled
結果は「scheduled: 定期メンテナンス時に対応」となりました。
脆弱性が見つかる度にSSVCやってる余裕なんてないよ...という開発組織もあるかと思うので、何を脆弱性の深刻度の指標とするか組織全体であらかじめ決めておくとよいです。
脆弱性の対処
評価して対応するタイミングを定めたら、後は対応するのみです。
パッチが適用されたライブラリやOSにバージョンアップデートしましょう。
安全にアップデートするには、やはり自動化されたテストが重要です。（コードの静的解析、単体テスト、E2Eテストなど。）
メジャーバージョンアップであれば互換性が無くなる可能性もあるし、大規模なシステムやレガシーなシステムで動作テストや回帰テストを手動で行うにはコストがかかります。
なのでみなさん、面倒くさがらずテストを書きましょう。
まとめ
ここまで脆弱性とは何で、どのように危険性を評価して、どのように検知・対処するのか記載してみました。
どんなに注意深くコードを実装しても、どれだけ生成AIを活用しても、利用するライブラリやフレームワークに新たな脆弱性が報告されることは避けられません。
システムに脆弱性があるということは、そのシステムには個人情報の漏洩やシステム停止といったリスクが大なり小なり潜んでいるということであり、リスクが顕在化する前に対処しなければなりません。
対処するには脆弱性を検知して、評価して、優先度を決めて対処を推進する「脆弱性管理」のサイクルが必要です。
エンジニアは単に機能開発を追求するだけでなく、脆弱性を適切に管理してより安全で信頼性の高いシステム開発を心がけたいですね。
Discussion