脆弱性とは？
種類やリスク、企業が取るべき対策を解説
企業のIT環境が複雑化する中、脆弱性は不正アクセスや情報漏洩、マルウェア感染、システム停止などにつながる深刻なセキュリティリスクとなっています。脆弱性はOSやソフトウェアの欠陥だけでなく、運用ルールの不備、人の行動、施設への入退室管理や端末の盗難防止といった物理的な管理の不備にも存在します。
サイバー攻撃から組織を守るには、脆弱性を一度確認して終わりにするのではなく、IT資産の把握、情報収集、優先順位付け、対策実施、評価を継続することが重要です。
この記事では、脆弱性の基本的な考え方、主な種類、放置するリスク、企業が取るべき脆弱性管理の流れ、修正プログラムや仮想パッチによる対策を解説します。
脆弱性とは
脆弱性とは、OS、ソフトウェア、ネットワーク機器、運用プロセス、人、施設などに存在する欠陥や弱点で、サイバー攻撃に悪用される可能性があるポイントを指します。
広義には、リスク評価における「資産」「脅威」「脆弱性」の3要素のひとつです。守るべき資産に対して、どのような脅威があり、どの脆弱性が悪用される可能性があるかを記録・管理することで、リスクの大きさを評価できます。
狭義には、OSやソフトウェアの欠陥を指すことが多く、こうした脆弱性はCVE（Common Vulnerabilities and Exposures）という共通脆弱性識別子によって一元的に管理されます。
■リスクを評価する3要素
攻撃者は脆弱性を悪用して、不正アクセス、情報窃取、マルウェア感染などを行います。そのため、脆弱性管理はサイバー攻撃対策の根幹となる取り組みです。守るべき資産、脆弱性、脅威を組み合わせて評価し、優先順位を付けた上で対策を講じることが基本です。
脆弱性の主な種類
脆弱性は、OSやソフトウェアの欠陥に限定されるものではありません。企業のセキュリティ対策では、技術、プロセス、人、物の4つの観点から脆弱性を整理し、運用ルール、従業員教育、物理的な管理も含めて確認する必要があります。
■脆弱性の4カテゴリ
技術的脆弱性
技術的脆弱性は、OS、ソフトウェア、ネットワーク機器、ファームウェアなどに存在する欠陥です。代表例として、バッファオーバーフロー、認証回避、SQLインジェクション、クロスサイトスクリプティングなどがあります。攻撃者はこれらの脆弱性を悪用し、権限昇格、情報窃取、不正操作などを行います。
技術的脆弱性は、修正プログラムが公開される前に悪用される「ゼロデイ脆弱性」と、修正プログラム公開後に悪用される「Nデイ脆弱性」に大別されます。
■ゼロデイ脆弱性とNデイ脆弱性
ゼロデイ脆弱性では、正式な修正プログラムが提供されるまで、仮想パッチや回避策によるリスク低減が必要です。一方、Nデイ脆弱性では、公開された情報をもとに攻撃コードが作成される可能性があるため、すみやかな修正プログラムの適用が求められます。
ゼロデイ攻撃とは？
プロセスの脆弱性
プロセスの脆弱性とは、組織的な管理プロセスの不備から生じる欠陥です。適切なプロセスが設定されていない、あるいは設定されていても守られていない状態が該当します。
<プロセスの不備から生じる欠陥の例>
・顧客情報を格納するフォルダへのアクセス権が、管理不備により全社員に開放されている
・設定変更の検証・承認が機能しておらず、外部公開すべきでないサーバが公開されたままになっている
・送金の承認ルールが未整備で、担当者1人の判断で外部送金できる状態になっている
アクセス権限の定期的な見直し、設定変更時の承認フロー、重要手続きの二重確認など、運用面の統制を整備することが重要です。
人の脆弱性
人の脆弱性とは、心理や感情、行動などの弱さや甘さ、不注意など、従業員をはじめとする人間の心理における欠陥を指します。「知らないアドレスから送信されたメールのリンクを不用意にクリックしてしまった」「SNSで所属企業の情報を投稿してしまった」など、人の不安感や焦り、弱み、セキュリティ意識の欠如などの人間の心理における欠陥が当たります。
ソーシャルエンジニアリングやフィッシングでは、こうした人の脆弱性が悪用されます。技術的な防御だけですべてを防ぐことはできません。継続的なセキュリティ教育、実践的な訓練、不審な連絡を相談できる報告フローの整備が必要です。
ソーシャルエンジニアリングとは？
物の脆弱性
物の脆弱性とは、建物などの施設やハードウェアに存在する物理的な欠陥を指します。「建物内への入退室における管理が適切に行われていない」「ワイヤーロックなど機器の盗難防止対策が行われていない」など、物理的に施設内へ侵入して、機器の破壊や情報の盗難などが行われる状態が該当します。
リモートワーク環境では、持ち出し端末の紛失対策や保管ルールも重要です。企業のセキュリティ対策では、IT統制と物理的な統制を組み合わせて管理する必要があります。
脆弱性を放置するリスク
脆弱性管理は、単にシステムを最新状態に保つための作業ではありません。事業継続や信用を守るための重要な取り組みです。放置された脆弱性は攻撃者にとって侵入の入口となり、情報漏洩や業務停止などの被害につながる可能性があります。
不正アクセス
脆弱性が悪用されると、管理画面や社内システムに不正アクセスされる可能性があります。攻撃者に侵入されると、業務情報の閲覧、設定変更、データの改ざん、不正なアカウント作成などにつながります。
特に外部公開されているシステムや認証機能に脆弱性がある場合、攻撃の入口になりやすいため注意が必要です。
情報漏洩
脆弱性を突かれてシステムに侵入されると、顧客情報、従業員情報、取引先情報、営業秘密などが外部に流出するおそれがあります。漏洩した情報は、不正利用され、二次被害に発展するケースも少なくありません。
情報漏洩は、法的対応や損害賠償、企業の信用低下にも直結します。
マルウェア感染
脆弱性は、マルウェアの侵入口として悪用される場合があります。攻撃者が脆弱性を突いて不正なプログラムを実行すると、端末やサーバがマルウェアに感染し、情報窃取や遠隔操作、感染拡大につながります。
ランサムウェアに発展した場合は、データの暗号化や業務停止、身代金要求など、事業継続に大きな影響を及ぼすケースもあるため、事前の対策が重要です。
システム停止
脆弱性を悪用した攻撃や不正操作により、Webサービスや業務システムが停止することがあります。ECサイト、予約システム、社内基幹システムなどが停止すれば、売上機会の損失や業務遅延は避けられません。
復旧に時間を要するケースでは、顧客対応や取引先対応の負荷も相当です。システム停止は、技術的な問題にとどまらず、事業継続上のリスクとして捉える必要があります。
取引先やサプライチェーンへの影響
自社の脆弱性が悪用されると、自社だけでなく取引先やグループ会社に被害が広がる可能性があります。例えば、侵害されたアカウントやシステムが踏み台となり、取引先への不正アクセスやマルウェア拡散に利用されるケースです。
サプライチェーン全体でシステムやデータが連携する現在では、1社の脆弱性が複数企業のリスクにつながる可能性があります。そのため、脆弱性管理は自社防衛だけでなく、取引先や顧客を守る取り組みでもあります。
脆弱性が増えている背景
近年、CVEとして登録される脆弱性の件数は増加傾向にあります。NVDは2025年に約42,000件のCVEを分析しており、これは過去最多を45%上回るペースです。背景には、クラウドサービス、SaaS、OSS、外部サービスの利用拡大があります。企業が把握すべきIT資産やソフトウェア構成は複雑化しており、直接利用しているソフトウェアだけを管理していれば十分とはいえません。特にOSSは複数のライブラリに依存するケースが多いため、構成要素まで把握する必要があります。
こうした状況を踏まえ、ソフトウェアの部品構成を管理するSBOM（Software Bill of Materials）の重要性も高まっています。どのソフトウェアが、どのライブラリやコンポーネントに依存しているかを把握できれば、脆弱性情報が公開された際の影響範囲を確認しやすくなるためです。
また、脆弱性情報が公表されてから攻撃に悪用されるまでの時間も短縮傾向にあります。攻撃者は公開された脆弱性情報や修正プログラムを解析し、攻撃コードを作成して悪用します。
トレンドマイクロの調査によると、2024年の日本企業のパッチ適用平均日数（MTTP）は27.5日で、欧州の23.5日に次いで主要地域の中で2番目に早い水準でした。一方で、アジア・中東・アフリカ地域の平均は32.9日となっており、地域間での格差が依然として存在します。
脆弱性管理の基本的な流れ
脆弱性対応は、修正プログラムを一度適用して完了するものではありません。新しい脆弱性は継続的に発見されるため、企業は管理の流れを整え、定期的に運用することが不可欠です。脆弱性管理の自動化・効率化は対応工数の削減に直結するため、手動対応からツール活用へ移行すれば、セキュリティチームのリソースをより高度な対策へ集中させることができます。
脆弱性管理は、以下の5ステップで整理できます。
■脆弱性管理の基本的な流れ
1. システムインベントリの作成
最初のステップは、組織で使用しているIT資産を棚卸し、システムインベントリを作成することです。対象には、ハードウェア、OS、ミドルウェア、アプリケーション、クラウドサービス、外部サービスなどが含まれます。利用者、利用開始日、コンピュータ名、OS、ソフトウェアバージョンなどを記録します。
資産が把握できていない場合、脆弱性情報が公開されても自社への影響を判断できません。クラウドや外部サービスを含む全資産を網羅し、定期的な棚卸しによって最新性を保つことが重要です。
2. 脆弱性情報の収集
次に、脆弱性情報ポータルや各ベンダのセキュリティアドバイザリを定期的に確認します。代表的な情報源には、JVN、JVN iPedia、NVD、JPCERT/CCの注意喚起などがあります。
■脆弱性情報のソース
| 名前 | 概要 |
|---|---|
| JVN（Japan Vulnerability Notes） | JPCERTコーディネーションセンターと独立行政法人情報処理推進機構（IPA）が共同で運営する、日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供する脆弱性対策情報ポータルサイト |
| JVN iPedia（脆弱性対策情報データベース） | IPAが運営する、国内外問わず日々公開される脆弱性対策情報のデータベース |
| Common Vulnerabilities and Exposures | 米国MITRE社が管理運営を行っている、一般に公表されている脆弱性情報を掲載している脆弱性情報データベース |
| 独立行政法人 情報処理推進機構 （IPA） | 放置すると危険性が高いセキュリティ上の問題と対策情報を掲載するWebサイト |
| JPCERT/CC | 深刻かつ影響範囲の広い脆弱性などに関する情報を告知するWebサイト |
| Zero Day Initiative（ゼロデイイニシアティブ） | トレンドマイクロが運営する脆弱性発見コミュニティ。発見された脆弱性のアドバイザリを掲載するWebサイト |
| トレンドマイクロ | マルウェア、スパム、不正URL、脆弱性とすべての脅威情報を集積したデータベース。 |
実際に悪用されている脆弱性を把握するには、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）のKEVカタログ（Known Exploited Vulnerabilities Catalog）も有効です。手作業だけでは見落としが発生しやすいため、脆弱性スキャナや脅威インテリジェンスを組み合わせた情報収集が求められます。
3. 脆弱性対応の優先順位付け
■脆弱性対応の優先順位
すべての脆弱性に同じ速度で対応することは現実的ではありません。そのため、対応の優先順位付けが重要です。CVSS（Common Vulnerability Scoring System）は脆弱性の深刻度を0.0～10.0で評価する代表的な指標ですが、CVSSが高い脆弱性だけを優先すればよいわけではありません。
実際に悪用されているか、外部公開システムに影響するか、重要な業務システムに関係するか、悪用される可能性が高いかなどを総合的に判断することが必要です。KEVカタログに登録されている脆弱性や、インターネット公開システムに影響する脆弱性は、優先度を高く設定します。EPSS（Exploit Prediction Scoring System）は、悪用可能性を予測する補助指標として活用できます。
CVSS(Common Vulnerability Scoring System)とは
4. 脆弱性対応の実施
脆弱性対応の基本は、開発元が提供する修正プログラムの適用です。これは、脆弱性そのものを解消できる根本策であり、修正プログラムが公開されている場合はすみやかな適用が原則です。ただし、本番環境への影響を避けるため、必要に応じてテスト環境での事前確認を行います。
企業では、本番環境への影響確認、メンテナンス時間の確保、ベンダ調整、古いシステムとの互換性など、さまざまな事情ですぐに修正プログラムを適用できないケースがあります。ゼロデイ脆弱性のように修正プログラム自体が未提供の状況も同様です。
こうした場合は、以下の暫定対応によって悪用されるリスクを低減します。
<すぐに修正プログラムを適用できない場合の暫定対応>
・ベンダが案内する回避策の実施、設定変更、該当機能の一時停止
・仮想パッチ（IPS）による脆弱性を狙う通信の検知・遮断
・緊急性が高い場合はネットワーク隔離や外部公開の一時停止
中でも仮想パッチは、IPS（Intrusion Prevention System）などのセキュリティ製品が脆弱性を狙う通信を検知・遮断することで、修正プログラム適用までの「保護の空白期間」を埋める手段として有効です。
■パッチ適用までのタイムラインと仮想パッチの役割
ただし、仮想パッチは脆弱性そのものを修正するわけではありません。あくまで一時的なリスク低減策として位置づけ、適用期限を明確に設定した上で、最終的には修正プログラムの適用やシステム更新につなげることが重要です。
5. 脆弱性対応の評価
脆弱性対応の評価では、実施した対策によって脆弱性が解消されているか、残存リスクがないかを確認します。脆弱性スキャナなどを用いて検証し、適用範囲、適用速度、残存脆弱性の数などをKPIとしてモニタリングします。
併せて、対応に時間がかかった原因や、未対応の脆弱性が残った理由を確認し、プロセスの改善点を洗い出すことも重要です。脆弱性管理は一度の対応で完了するものではないため、継続的にPDCAを回し、管理精度と対応速度を高めていく必要があります。結果として、パッチ適用までの期間短縮にもつながります。
深刻度の高いソフトウェア脆弱性が発生したら
前述の5ステップは、脆弱性を継続的に管理するための平時の基本フローです。これに対し、ゼロデイ脆弱性の公開や悪用が確認された脆弱性への緊急注意喚起など、対応の緊急度が突出して高い局面では、通常のサイクルを待たず即座に動く必要があります。
こうした緊急時には、「観察（Observe）」「方向付け（Orient）」「判断（Decide）」「行動（Action）」のOODA（ウーダ）ループを活用し、対応方針を迅速に固めることが重要です。
攻撃の可能性を低減する一時的な代替策の検討
脆弱性の根本的な原因を排除するためには、すぐに修正プログラムを適用することが理想的です。しかし、メンテナンス時間が決められていたり、事前に検証環境でのテストが必要だったりと、すぐに修正プログラムを適用することが困難なケースが多々あります。また、ベンダからの修正プログラムのリリース前に公開されるゼロデイ脆弱性といったケースも見過ごせません。
そのような場合には、修正プログラム以外の対策によって、できるかぎり迅速に脆弱性が悪用される可能性を軽減する必要があります。具体的には、該当ソフトウェアにおける設定変更など開発元が案内している回避策の実施、仮想パッチ（IPS）などのセキュリティ製品による脆弱性を悪用した攻撃のブロックや検知についても併せて情報収集や実現可否を確認しておけば、迅速な脆弱性対応の実現につなげることができます。
修正プログラム適用後の状況の観察
修正プログラムを適用すれば脆弱性を排除することはできますが、引き続きOODAループに沿った状況の観察が重要です。なぜなら、脆弱性のなかには、修正プログラムが不完全であったり、関連した新たな脆弱性が短期間の間に発見されたりするケースがあるためです。2021年に発生した「Log4Shell」においては、開発元により該当の脆弱性の対策が施されたと案内された最初の「Apache Log4j」の新バージョンがリリース後、修正内容の見直しや新たな脆弱性の対応のために、短期間のうちにいくつものバージョンがリリースされました。
脆弱性管理で参考にしたい指針
脆弱性管理の体制を整備する際は、公的機関や業界団体が公開するガイドラインも参考になります。NIST SP 800-40、ISO/IEC 27001、IPAの脆弱性関連資料、業種固有のガイドラインなどを組み合わせ、自社の業種や規模に合った管理レベルを設定することが重要です。
■脆弱性管理の参考にできるガイドライン
| ガイドライン | 発行元 | 概要 |
|---|---|---|
| NIST SP 800-40r4 | 米国国立標準技術研究所（NIST） | パッチ管理の計画・実施に関する指針。プロセスの体系化と優先順位付けの考え方を提供 |
| NIST Cybersecurity Framework（CSF）2.0 | 米国国立標準技術研究所（NIST） | 特定・防御・検知・対応・復旧の5機能で構成される包括的なセキュリティ管理フレームワーク |
| ISO/IEC 27001 | 国際標準化機構（ISO）/ 国際電気標準会議（IEC） | 情報セキュリティマネジメントシステム（ISMS）の国際規格。脆弱性管理を含む情報資産全体の管理体制を規定 |
| CIS Controls v8.1 | 米国インターネットセキュリティセンター（CIS） | 優先順位付けされた18のセキュリティコントロール。脆弱性スキャンやパッチ管理の実務手順を具体的に示す |
| サイバーセキュリティ経営ガイドライン Ver3.0 | 経済産業省・IPA | 経営者が取り組むべきサイバーセキュリティ対策を整理。脆弱性管理を含む10の重要項目を提示 |
| 安全基準等策定指針（第5版） | 国家サイバー統括室（NCO） | 重要インフラ分野における情報セキュリティ対策の基準策定を指針化。分野横断の基礎的な管理水準を示す |
| 情報セキュリティ早期警戒パートナーシップガイドライン | 独立行政法人情報処理推進機構（IPA） | 脆弱性の届出・調整・公表プロセスを定めた国内標準。JVNの運用ルールの基盤となる指針 |
| CISA KEV（Known Exploited Vulnerabilities）Catalog | 米国サイバーセキュリティ・インフラセキュリティ庁（CISA） | 実際に悪用が確認されているCVEの一覧。脆弱性対応の優先順位付けに直接活用できる |
例えば、金融業界ではFISC安全対策基準、医療業界では医療情報システムの安全管理に関するガイドラインなど、業界ごとの基準を踏まえた対応が求められます。自社に適用される法令、業界基準、取引先要件を確認した上で、脆弱性管理の手順や責任範囲を明確にすることが必要です。
■業種別ガイドライン
| 業種 | ガイドライン | 発行元 |
|---|---|---|
| 金融業界 | 金融機関等コンピュータシステムの安全対策基準・解説書（第14版） | 公益財団法人金融情報システムセンター（FISC） |
| 医療業界 | 医療情報システムの安全管理に関するガイドライン 第6.0版 | 厚生労働省 |
TrendAI Vision One™ で脆弱性管理を高度化する
脆弱性管理では、資産の可視化、脆弱性の検出、優先順位付け、対策実施を継続的に回すことが必要です。複数の単機能ツールを個別に運用する従来型のアプローチでは、データが分断され、リスクの全体像を把握しにくくなる場合があります。
TrendAI Vision One™ は、サイバーリスクエクスポージャ管理、セキュリティ運用、多層的な保護を一元化するエンタープライズサイバーセキュリティプラットフォームです。エンドポイント、クラウド、ネットワーク、メール、ID、データなど、企業のIT環境全体にわたるリスクや脅威を可視化し、対策の優先順位付けを支援します。
また、Cyber Risk Exposure Management（CREM）により、アタックサーフェスや脆弱性の状況を継続的に把握できます。悪用される可能性や事業への影響を踏まえて、対応すべきリスクを整理できる点も特徴です。脆弱性管理の高度化を検討している場合は、TrendAI Vision One™ とCREMの活用をご検討ください。
TrendAI Vision One™
Cyber Risk Exposure Management（CREM）
よくあるご質問（FAQ）
CVEとCVSSの違いは何ですか？
CVEは、脆弱性を一意に識別するための番号です。どの脆弱性を指しているのかを特定する役割があります。一方、CVSSは、脆弱性の深刻度を0.0～10.0で評価するスコアリングシステムです。
つまり、CVEは「何の脆弱性か」を示し、CVSSは「どれだけ深刻か」を示す指標です。実務では、CVE番号で脆弱性を特定し、CVSSスコアで初期的な深刻度を確認します。その上で、実際に悪用されているか、外部公開システムに影響するか、重要な業務システムに関係するかなどを踏まえて対応の優先順位を決めます。
修正プログラムをすぐに適用できない場合はどうすればよいですか？
修正プログラムをすぐに適用できない場合は、暫定対応によって攻撃を受ける可能性を下げる必要があります。具体的には、仮想パッチによる攻撃の検知・遮断、ベンダが案内する回避策や設定変更、該当機能の一時停止、対象システムのネットワーク隔離、外部公開の停止などが挙げられます。
ただし、これらは脆弱性そのものを解消する対策ではありません。暫定対応を行う場合でも、いつまでに修正プログラムを適用するのかを定め、長期間放置しないことが重要です。
中小企業でも脆弱性管理は必要ですか？
中小企業でも脆弱性管理は必要です。攻撃者は企業規模にかかわらず、悪用できる脆弱性がある組織を標的にします。むしろ、セキュリティ対策が手薄な組織は攻撃対象になりやすいと考えられます。
自社リソースが限られる場合は、IT資産管理ツール、脆弱性スキャナ、MDRなどの外部サービスを活用する方法もあります。まずは資産インベントリの作成と、JVNやCISA KEVなどの定期確認から始めるのが現実的です。無理のない範囲で継続できる運用を設計することが、脆弱性管理を定着させる上で重要です。
脆弱性についての関連情報
脆弱性管理のガイドライン「NIST SP 800-40」を紐解く
日々発見される脆弱性に対応するため、法人組織が参考にすべき脆弱性管理のガイドラインの１つ「NIST SP 800-40」を解説します。
今後のランサムウェア攻撃で備えるべき「第三のリスクシナリオ」とは？
「暗号化による業務停止」だけでなく「暴露による情報漏えい」までも一般的になりつつあるランサムウェア攻撃。世界26ヵ国でこの脅威の被害を調査した結果、第三のリスクシナリオとして「レピュテーション」のリスクが見えてきました。