脆弱性とは

脆弱性とは

脆弱性はソフトウェアやWebアプリケーションにある、セキュリティ上の問題箇所です。IPA（独立行政法人情報処理推進機構）は、不正アクセスやウイルスで攻撃されると、本来の機能や性能を損なう原因になり得る箇所と説明しています。たとえば、ログインしていない外部の人が、サーバーに任意の操作をさせられる不具合や、ウェブサイトの運用の不備で、本来は閲覧できない情報を誰にでも閲覧できる状態にしてしまう設定も、IPAは含めています。放置すると悪用の条件が成立したときに、情報の漏えいや業務の停止に発展するおそれがあります。

身近なたとえでは鍵のかからない窓が脆弱性、そこからの侵入が攻撃、窃取された物が被害です。脆弱性は弱点で、攻撃や被害そのものではありません。ゼロデイ攻撃はそれまで未知だった脆弱性を悪用する攻撃で、脆弱性そのものとは区別します。セキュリティホールはほぼ同義の呼び名で、総務省の解説でも警察庁の解説でも併記されます。IPAの届出など、制度上の用語は脆弱性です。脆弱性を探索する作業は脆弱性診断といい、脆弱性そのものとは別の作業です。

被害になる条件

脆弱性があることと、被害が発生することは別です。攻撃の成否は一般に次のような条件に左右されます。

• 攻撃者がその箇所へ通信できる
• 問題のある機能や設定が実際に有効である
• 認証など攻撃前の関門を通過できる
• 攻撃の手法が実際に利用できる

条件は固定されません。公開範囲の拡大や攻撃コードの公開といった変化で、成立することがあります。

CVSSの点数

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0から10の点数で表現する共通の指標です。バージョンは複数あり、IPAの概説はv2を解説しています。v2はネットワークから攻撃できるか、攻撃用のコードが利用できるかといった条件を別の項目で評価します。後続のバージョンのうち、v4.0でも攻撃元区分や攻撃コードの成熟度にあたる項目があることが、FIRSTの利用者ガイドで確認できます。

影響が発生しない例

たとえば、利用しているライブラリに脆弱性が見つかっても、自社のシステムが問題の機能を利用していなければ、影響が発生しない場合があります。問題の機能を利用しない実装は、深刻度が0になる例として、CVSS v4.0の利用者ガイドにあります。利用していないという判断は、間接的に依存するライブラリで誤りになることがあります。確認できるまでは影響があると想定します。

到達できる条件の例

反対に、VPN（Virtual Private Network）機器は、社外から社内のネットワークに接続するための機器で、多くの場合、インターネットから到達できる位置に配置されます。ランサムウェアの侵入はVPN機器などの外部に露出した箇所から次のような点を悪用する手口が多くを占めています。

• 未修正の脆弱性
• 漏えいした認証情報や簡易なパスワード
• 設定不備

脆弱性の修正だけでは不十分です。認証情報の管理や設定の見直しも必要です。

放置したときの影響

脆弱性の情報が公開されると、攻撃者にも把握されることがあります。公知になった脆弱性のリスクは、通常高まるとされています。

CVE（Common Vulnerabilities and Exposures）は、公開された脆弱性を識別する共通の番号です。

公開から発覚までの例

2025年にReactというライブラリで、認証なしで外部からコードを実行できる脆弱性が発見されました。CVE-2025-55182として、現地時間の12月3日に公開されています。JPCERTコーディネーションセンターの報告にある、被害組織を明らかにしていない事案でのサーバーの経過は次のとおりです。時刻は日本時間です。

• 12月5日: 他人のサーバーで暗号資産を採掘させるプログラム（コインマイナー）の設置。公開の2日後
• 12月6日: あとから自由に出入りするための裏口（バックドア）などの設置
• 12月7日: サイトの改ざんを確認した利用者の連絡で発覚

JPCERT/CCは一台のサーバーに複数の攻撃者が侵入していたと報告しています。

被害の種類

放置したときの被害の種類は情報漏えい、情報改ざん、業務停止などです。顧客情報の漏えいは関係先への連絡や報告の要否の判断に、改ざんは信用の毀損に、業務停止は受注や出荷の停止に発展することがあります。侵入の拠点にされるとランサムウェアのような別の攻撃に発展することもあります。

対処の優先順位

脆弱性は次々に公開され、全件を同じ速度で修正するのは現実的ではありません。資産や脆弱性、パッチの数が多く、自動化なしではパッチ適用に追い付けないとされています。パッチは脆弱性を修正する更新プログラムで、優先順位を設定して作業を配分します。

点数の解釈に必要な観点

公表されているCVSSの点数は、多くが基本値で、脆弱性そのものの深刻度を示します。基本値だけでリスクを評価しないよう、FIRST（Forum of Incident Response and Security Teams）の利用者ガイドが明記しています。点数は次の観点を加味して解釈します。

• 悪用がすでに確認されているか
• その機器がインターネットから到達できるか
• 攻撃者が探索から侵入までを手作業なしで自動化できるか
• 悪用された場合の影響が、完全な制御または全情報の漏えいか、一部に限られるか
• 影響対象の業務の重要度

悪用の確認と修正期限の例

悪用の確認にはKEV（Known Exploited Vulnerabilities）カタログを利用できます。このカタログは米国のCISA（Cybersecurity and Infrastructure Security Agency）が公開しています。CISAは連邦機関以外の組織にも、掲載されている脆弱性の修正を優先するよう勧めています。KEVへの掲載は悪用が確認された後で、掲載されていないことは悪用されていないことを意味しません。Reactの事例では公開の2日後にコインマイナーが設置され、KEVへの掲載も同じ12月5日でした。KEVに掲載されていなくても、インターネットに公開された機器では対処を開始します。

CISAは2026年6月に、指令BOD（Binding Operational Directive、拘束力のある運用指令）26-04を発出しました。米国の連邦行政機関（文民）を対象とする義務で、民間の基準ではありませんが、組み合わせの考え方は参考になります。指令は修正期限を、次の4要素の組み合わせで定めています。

• 公開の有無
• KEVへの掲載
• 攻撃の自動化
• 影響の大きさ（乗っ取りの程度）

決定表では期限は3日、14日、60日、次の大規模な更新時の4区分です。CERT/CCが公開する決定表では、3日の区分のうち、KEVに掲載され、影響が完全な場合は、侵害の有無を評価するフォレンジックトリアージまで求めています。KEVに掲載されていなくても、公開されていて自動化でき、完全に操作される脆弱性は3日です。

この考え方を簡略化した、対応の一例は次のとおりです。

• 公開していて、悪用が確認されているか自動化でき、完全に操作される: 緊急。修正か緩和を数日以内に行い、悪用が確認されている場合は侵害の有無も確認する
• 公開している、または悪用が確認されているのどちらかに該当し、緊急ではない: 定期更新に先行して、数週間以内に適用する
• それ以外: 定期更新の周期で適用する

この3区分は指令の決定表を簡略化した例で、決定表の16通りの組み合わせは5つの結果になります。決定表より期限が緩くなる組み合わせもあります。たとえばKEVに掲載され、自動化でき、完全に制御される脆弱性は、非公開でも決定表では3日で、侵害の調査を求めます。指令に対応するCERT/CCの決定表では組み合わせにより、悪用が確認され公開されていて自動化できる場合などに3日、そのほかに14日や60日になる場合があります。日数は米国連邦機関向けの参考値です。自社の周期は資産の数、停止できる時間、担当者の人数によって変化します。

公開もされず、悪用も確認されず、問題の機能も利用していない場合は、優先度を低位に設定して定期更新で処理します。影響が軽微と確認して、追加の対応を実施せずに現状を維持する判断は、NIST（National Institute of Standards and Technology）の整理でいう受容にあたります。

パッチ適用と更新の運用コスト

適用は一度で完結せず、継続して費用がかかります。NISTはパッチ適用を事業を進めるための通常の費用と位置づけています。

• 資産の把握: どの機器にどの製品のどのバージョンが導入されているかの一覧を作成し、維持する。自社で開発したシステムが利用するライブラリなど、間接的に利用する製品も含める
• 情報の入手: 製品の提供元からの通知や、国内外の公的な注意喚起を確認する担当と、連絡先を決定する。自社が該当するかどうかは提供元の情報や技術担当者への確認で判定する
• 事前の検証: 一部の機器へ先に適用して、業務への影響を確認する。検証用の環境を維持する費用もかかる
• 停止の調整: 再起動や計画停止の枠を確保する。資産ごとに、停止できる時間と優先する業務を業務側に確認して決定する
• 適用後の確認と記録: 適用の結果を確認し、記録する
• 適用できない資産の代替策: 提供元の更新が終了した製品や停止できない設備は、隔離など別の対策を実施する
• 侵害後の対応: 悪用されていた場合は、調査、認証情報の再発行、再構築に費用がかかる

先送りの影響

定期更新は再起動などで業務を中断するため先送りされやすい傾向があります。先送りが累積すると攻撃の対象となる機会が増加します。さらに、後続の更新が前の更新に依存する場合は、緊急の適用時に未適用の更新を先に適用する必要が生じて、作業が重く長くなります。

緩和と責任の分担

修正がまだ公開されていない場合は、問題の機能の停止、公開範囲の限定、ネットワークの分離といった緩和で修正までの時間を確保します。緩和は修正の代わりにならず、公開後は速やかに修正へ移行します。対応は受容、低減、移転、回避の4種類に整理されます。パッチ適用は低減にあたり、更新を提供元が行うSaaS（Software as a Service）への切り替えは移転にあたります。移転しても、アカウント管理や設定などの責任が利用者側に残ることがあります。これはこの記事の経験則で、出典はありません。

クラウドでも担当は分担されます。AWSの責任共有モデルでは、仮想サーバーのOSとアプリケーションのパッチ適用は利用者の責任です。

よくある誤解

脆弱性がある機器はすでに侵害されている

脆弱性は弱点で、侵害とは別のものです。一方、悪用が確認されている脆弱性は、修正前に侵入されていないかの確認が必要です。

CVSSの点数が低ければ放置してよく高ければすべて緊急

点数は深刻度で、リスクそのものとは別です。公開の有無や悪用の状況によって、優先順位は変動します。

パッチを適用すれば終わり

パッチを適用しても、修正前に侵入されていれば被害は解消されません。悪用が確認された脆弱性では、パッチ適用のほかに侵害の有無の確認が必要です。

社内だけで利用しているシステムは対象外

社内だけで利用しているシステムでも、侵入した攻撃者はネットワーク内部を探索し、より多くのサーバーや端末の侵害を試行します。公開していないことは、決定表のように優先順位を低下させる材料にはなりますが、対処を省略する理由にはなりません。

まず外部に公開している機器とシステムの一覧を作成し、ライブラリなど間接的に利用する製品も含めます。同時に、その一覧に含めた製品の公開情報を確認する担当と連絡先を決定します。