はじめに

情報システムの脆弱性は、長年サイバー攻撃の入口として悪用され続けている。2024年の情報セキュリティ白書では、「ランサムウェア感染端末の47.1%が最新の修正パッチを適用していなかった」という統計が示され、基本的な対策の不徹底が被害拡大の要因になっていることが浮き彫りになった。調査対象の87件中46件が未対策のまま運用されており、脆弱な機器に侵入した攻撃者は長期間潜伏して組織全体に影響を及ぼした。さらに、インシデント対応・復旧にかかるコストは高騰している。2024年の調査では、調査や復旧に50万円以上の費用が発生したケースが22.5%、1,000万円以上の負担に至ったケースが7.8%と報告されている。適切なパッチ管理・構成管理を怠ることが、組織の経済的負荷や信頼性の低下につながることが明らかになった。

本記事では、システム脆弱性の種類、脆弱性管理の仕組み、最新の攻撃傾向、そして企業が取り組むべき対策について、情報セキュリティ白書2025から学び取った要点を整理する。脆弱性対策は一回限りの施策ではなく、開発・運用・調達の全ライフサイクルに組み込むべきプロセスである。政府・業界団体・企業の取り組みや法制度の動きも含め、包括的に解説する。

1. 脆弱性とは何か – 分類と危険度

脆弱性とは、情報システムやソフトウェアに存在する設計・実装上の欠陥や設定不備であり、攻撃者に悪用されると不正アクセス・情報漏えい・サービス停止などの被害を引き起こす。2024年時点で、国内脆弱性情報データベース「JVN iPedia」に登録された脆弱性は累計22万3,690件に上る。この膨大な件数は、ソフトウェアの複雑化とともに脆弱性が恒常的に発生していることを示す。

1.1 CWE分類に見る脆弱性の傾向

JVN iPediaは登録された脆弱性を共通弱点タイプ (CWE:Common Weakness Enumeration) に分類している。2024年に報告された脆弱性では、クロスサイトスクリプティング (XSS) が全体の17.5%と最多を占め、続いてSQLインジェクションが7.9%、領域外書き込みが5.1%となっている。クロスサイトスクリプティングは以前から存在する典型的な脆弱性であるが、攻撃者が偽の入力フォームを設置して機密情報を盗み取る手口は依然として有効である。外部サイトへのリダイレクトやメッセージ表示を悪用するフィッシング攻撃の踏み台にもなり得るため、開発段階での入力値検証やコンテキストに応じたエスケープ処理が必須である。

SQLインジェクションは、データベース操作を行うWebアプリケーションの入力値に悪意のあるSQL文が仕込まれ、データの閲覧・改竄・削除が行われる攻撃だ。近年はWebフレームワーク側でプリペアドステートメント機能が整備され、対策が容易になったが、古いバージョンのアプリケーションを使い続ける組織や、カスタムSQLを多用するシステムでは危険が残る。領域外書き込みはC/C++など低レベル言語で作られたソフトウェアに多く、境界チェックの不足が原因で隣接メモリ領域への書き込みが発生し、任意コードの実行やシステムクラッシュを引き起こす。この種の脆弱性は制御系機器や旧来のOSに多く、パッチが出ても更新が難しいという課題がある。

1.2 CVSSによる危険度評価

脆弱性の危険度は一般に「CVSS (Common Vulnerability Scoring System)」で評価され、0〜10の数値で重大度を示す。白書によると、2024年に公開された脆弱性のうち、CVSSスコアが9.0以上の「Critical」および7.0以上9.0未満の「High」に分類されるものの割合は51.0%で前年から減少し、中程度の危険度 (4.0以上7.0未満) の「Medium」が47.1%に増加した。これは、極めて危険な脆弱性は減少傾向にある一方、中程度の脆弱性が多く報告されるようになったことを意味する。Mediumレベルでも攻撃者が連鎖的に悪用する場合には重大な被害につながるため、単純に数値だけで判断せず、システム環境や公開範囲を考慮した評価が必要である。

2. 脆弱性情報の流通 – JVN iPediaと早期警戒パートナーシップ

国内の脆弱性情報の基盤を支えるのが、IPAが運営する「JVN iPedia」と「情報セキュリティ早期警戒パートナーシップ制度」である。JVN iPediaは国内外の脆弱性情報を集約し、開発者やユーザーが確認できる公的データベースである。早期警戒パートナーシップは、ソフトウェア開発者やウェブサイト運営者が脆弱性をIPAに報告し、対処情報が公開される仕組みだ。

2024年にこの制度に報告された脆弱性は632件であり、内訳はソフトウェア製品が296件、ウェブサイトが336件であった。この制度の開始以来、累計でソフトウェア製品の脆弱性5,960件、ウェブサイトの脆弱性13,326件が報告されている。この数字は、国内における脆弱性管理が着実に進んでいることを示す一方、依然としてウェブサイト運営者のセキュリティ意識が不足している部分があることも示唆している。

2.1 2024年の注目脆弱性 – 不適切なファイル公開

2024年のウェブサイト脆弱性で最も多かったのは「不適切なファイル公開」(42.6%)で、過去数年最多だったクロスサイトスクリプティング(32.7%)を上回った。不適切なファイル公開とは、アクセス制限が必要なファイルやディレクトリが誤って公開されている状態を指し、設定ミスやテスト用ファイルの放置、バックアップファイルの公開などが原因となる。攻撃者は検索エンジンや自動スキャンツールを用いて公開されたバックアップや設定ファイルを発見し、そこに保存されている認証情報やソースコードからさらなる侵害へとつなげる。開発テスト用のファイルは運用に移行する際に削除する、アクセス制御を適切に設定する、バックアップファイルをWeb配下に置かないなどの基本が求められる。

2.2 VPN機器や監視装置の脆弱性

VPN装置や第三者のリモート監視システムに存在する脆弱性が攻撃者に狙われる例が増えている。白書では、VPN機器の脆弱性を悪用して内部ネットワークに侵入し、ウェブシェルを設置したり、横移動(ラテラルムーブメント)で内部サーバやデータベースにアクセスしたりする攻撃が報告されている。VPN装置は外部から直接アクセスされるため、脆弱性が公開されると迅速に攻撃対象となり、短時間で大規模な影響を及ぼすリスクがある。また、IoT機器の中でも遠隔監視用のデバイスは、ファームウェア更新やパスワード変更が行われていないケースが多く、乗っ取られてボットネットの一部と化す可能性が高い。攻撃者はこうしたデバイス群を利用してDDoS攻撃のトラフィックを増幅したり、内部ネットワークへの侵入経路としたりする。

3. パッチ管理とセキュリティ更新の課題

脆弱性対策の中心は、ソフトウェアやOS、機器のファームウェアに対して修正パッチを迅速に適用することだ。しかし白書の統計が示す通り、多くの組織が「パッチ適用の遅れ」や「適用済みかどうかの管理不備」に直面している。なぜ修正パッチが適用されないのか。主な要因を整理すると次のとおりである。

  1. 業務への影響を懸念するあまり計画的な適用を躊躇する
    • 生産設備や基幹システムでは、パッチ適用による再起動や停止が稼働に影響を与えることを恐れ、適用を先延ばしにする場合が多い。また稼働中のバージョンとパッチの組み合わせ検証に時間がかかることもある。
  2. 資産管理や脆弱性管理のツール・担当者が不足
    • 脆弱性管理には、各システムのソフトウェアバージョンや適用状況を把握する資産管理が必須だが、小規模な企業では専任担当者がいない場合もある。手作業の更新確認は漏れが発生しやすい。
  3. パッチの情報伝達経路が煩雑である
    • ソフトウェアごとにサポートサイトやメール通知、コミュニティフォーラムなど情報源が異なり、統一された把握が難しい。特にオープンソース製品では、脆弱性情報が開発者コミュニティで分散していることが多い。
  4. ベンダーサポート終了製品の存在
    • 経費節減や長期運用のために、サポートの切れたOSや機器を使い続ける企業が少なくない。ベンダーがパッチを提供しないため、独自の対策が必要となるが現実的には放置されやすい。

これらの課題を克服するには、資産管理の自動化、パッチ適用に伴う影響の事前検証、IT部門とOT部門の協調、経営層の理解と予算配分など、組織的な取り組みが必要となる。さらに、重要インフラ向け機器や医療機器など更新が難しい領域では、仮想パッチや周辺環境でのアクセス制御、脅威インテリジェンスの活用などを組み合わせた多層防御が求められる。

3.1 ゼロデイ脆弱性とパッチの迅速性

ゼロデイ脆弱性とは、開発者が認識していないか、認識しているが修正パッチが提供される前の脆弱性を指す。攻撃者はゼロデイを利用してパッチリリース前に攻撃を仕掛けるため、被害が広がりやすい。過去の例として、2023年の仮想化ソフトウェアにおけるゼロデイ脆弱性では、攻撃者が管理ホストから仮想マシンへ乗り移ることが可能となり、データセンター全体に影響が及んだ。ゼロデイ対策には、不正侵入検知や挙動分析の導入、ベンダーとの情報共有体制の構築、脆弱性情報の収集・優先順位付けが欠かせない。パッチが提供されるまでの間は、周辺でアクセス制限を強化したり、攻撃コードが出回っている場合はサービス停止を検討したりする判断が求められる。

3.2 SBOMとソフトウェアサプライチェーン

サプライチェーン攻撃の増加に伴い、ソフトウェア構成の透明性を確保するSBOM (Software Bill of Materials) の重要性が高まっている。SBOMとは、ソフトウェア製品に含まれる全てのコンポーネントや依存ライブラリの一覧表であり、脆弱性が含まれるライブラリを迅速に特定・更新するための情報基盤となる。白書ではSBOM利用の推進が触れられており、開発者がSBOMを生成し利用者に提供することで、脆弱性が発覚した際に影響範囲を即座に把握できるようになると強調している。国際的にも米国のサイバーセキュリティ・インフラセキュリティ庁 (CISA) がSBOMの標準化を推進しており、今後は調達契約の要件としてSBOMが求められるケースが増えるだろう。日本でも行政システムや重要インフラにおけるSBOM導入が進められている。

4. 脆弱性を狙った最新攻撃 – ケーススタディ

ここでは、2024年〜2025年に報告された具体的な事例を通じて、脆弱性を悪用した攻撃の実態と教訓を紹介する。

4.1 VPN装置への侵入とラテラルムーブメント

ある製造業のグループでは、外部公開していたVPN装置の認証バイパス脆弱性を突かれ、攻撃者が未知のアカウントでログインした。攻撃者はWebシェルを設置し、内部ネットワークの認証情報を窃取するとともに、Active Directoryサーバにアクセスし、管理者権限を取得した。最終的に機密情報が暗号化され、身代金を要求するランサムウェア攻撃へと発展した。この事例では、多要素認証の導入やVPN装置の脆弱性情報監視、ネットワーク分割の不足が被害拡大の要因となった。VPN機器はインターネットから直接アクセスされるため、OSやファームウェアの更新を即座に適用し、アクセスログ監視や異常検知を行うことが不可欠である。

4.2 オンラインショッピングサイトのファイル公開と情報漏えい

2024年末、大手ECサイトが誤って開発環境のバックアップフォルダを本番環境に置き、顧客データとカード決済情報が大量に流出する事件が発生した。この脆弱性は不適切なファイル公開に該当し、攻撃者が検索エンジンに登録されたバックアップファイルを発見してアクセスした。バックアップには暗号化されていないデータベースダンプが含まれており、顧客ID・パスワードが平文で残されていたことから、二次被害として他サービスへのリスト型攻撃に悪用された。事後の調査では、開発部門が本番環境へのデプロイ手順を誤っていたこと、アクセス権限のレビューが行われていなかったことが明らかになった。ファイル公開の問題は設定ミス・手順不備によって生じるため、デプロイ自動化や権限チェック、コードレビューの強化が求められる。

4.3 脆弱性報奨金制度を悪用した虚偽報告

近年、バグバウンティプログラムが盛んになる一方、虚偽の脆弱性報告で報奨金を得ようとする行為が発生している。ソフトウェア開発会社の報告によると、2024年に虚偽報告が全体の5%に達し、本物の脆弱性調査業務を圧迫したという。攻撃者は既に公表済みの脆弱性やベンダーが自社製品とは無関係と確認済みの脆弱性を報告し、報奨金を得ようと試みた。こうした事案を防ぐためには、報告受付時点で脆弱性情報の重複チェックを自動化する仕組みや、悪質な報告者を排除する運用ルールを整備する必要がある。脆弱性報奨金制度は有用だが、不正利用対策を組み込むことが重要だ。

5. 組織が取り組むべき対策 – ガバナンスとプロセス整備

脆弱性管理は単なる技術的対策ではなく、組織全体のガバナンスとプロセスに根差す。対策を実効的なものにするためのポイントを以下に整理する。

5.1 資産管理とリスク評価

脆弱性対応の第一歩は、保有する資産を把握し、重要度とリスクを評価することである。どのシステムがインターネットに公開されているか、どのソフトウェアが稼働しているか、サポート状況はどうかを一覧化し、脆弱性情報と紐付ける。その上で、リスクの大きい資産から優先的にパッチ適用や設定変更を実施する。資産管理は手作業では追いつかないため、自動収集ツールの導入が望ましい。

5.2 インベントリと構成管理データベース (CMDB)

ITILやNIST SP800-53などのフレームワークでは、構成管理データベース (CMDB) を用いてシステム資産とその関係を管理することが推奨されている。CMDBにはサーバ・アプリ・ネットワーク機器・ライブラリなどの関係性や更新履歴が蓄積され、脆弱性発見時に影響範囲を迅速に特定できる。DevOpsやInfrastructure as Code(IaC)の文化においても、コードで記述された設定ファイルからCMDBへの同期を行うことで、構成のドリフトを防ぎ、パッチ適用状況を自動検知できる。

5.3 パッチ管理プロセスの標準化

企業におけるパッチ管理は、(1)脆弱性情報の収集、(2)影響評価と優先度付け、(3)検証環境でのテスト、(4)本番適用、(5)適用状況の確認および文書化、といった一連のステップを踏む必要がある。これらのプロセスを明文化し、責任者や承認フローを定めることが欠かせない。特に、OT環境や医療機器など停止が許されないシステムでは、適用できない場合の代替策(仮想パッチの導入や周辺機器での防御)を事前に決めておく。パッチ適用後は監視システムで異常がないか確認し、元に戻すためのバックアウト手順を用意するなど、リスク低減策も盛り込む。

5.4 教育と組織内周知

脆弱性管理をIT部門だけの課題とせず、経営層から現場まで認識を共有することが重要だ。開発者には安全なコーディング指針(セキュアコーディング)や脆弱性検査ツールの利用を教育し、運用担当者にはパッチ適用の重要性や新たな脆弱性情報を知らせる仕組みを整備する。また、ユーザー部門もOSやアプリの自動更新を有効にすることや、不審なメール・Webサイトを開かないことなど、基本的なセキュリティ意識を持つことが求められる。経営層には、パッチ遅延が重大な損失や法的責任につながることを示し、予算や人員を確保してもらう必要がある。

5.5 外部サービスとクラウド利用のセキュリティ責任

クラウドサービスの普及により、企業はインフラの一部をサービス事業者に依存する。クラウド上の脆弱性に対する責任分界点を明確に理解することが重要だ。Infrastructure as a Service (IaaS) では、顧客がOSやアプリケーションの更新を担当し、Platform as a Service (PaaS) ではランタイム環境のパッチはサービス事業者が行うが、デプロイしたコードの脆弱性はユーザーの責任となる。Software as a Service (SaaS) では多くの部分を事業者が管理するが、ユーザー設定の誤りが攻撃につながることがある。クラウド環境では共通の基盤を共有するため、一つの脆弱性が多数のテナントに影響を及ぼす。契約時にセキュリティ要求事項やサービスレベルを確認し、脆弱性報告に関する責任範囲を明確にしておくことが不可欠である。

6. 政府・業界の取り組みと法制度の動向

脆弱性対策を促進するため、政府や業界団体も様々な取り組みを進めている。ここでは主要な制度と動向をまとめる。

6.1 ソフトウェア製品の安全基準と認証

政府は、情報システムの調達においてセキュリティ要件を強化しつつある。例えば、情報システム調達におけるセキュリティ要求事項は「整備を含めた開発プロセスの標準化」「SBOMの提供」「脆弱性報告への迅速な対応」などを盛り込んでいる。IoT機器では、技適マークに加え、サイバーセキュリティ基準への適合を示す認証制度が検討されている。これにより、市場に提供される製品が一定水準のセキュリティを満たすことが期待される。

6.2 クラウドサービスに関する法制化

クラウドサービス事業者に対しても、情報漏えい時の報告義務や安全管理体制の整備を義務付ける法改正が検討されている。利用者が自社のデータを託す際、クラウド事業者のセキュリティレベルを確認できる仕組みとして第三者認証制度が注目されている。また、データセンターのロケーションや管轄法がサービス利用に与える影響を理解し、個人情報保護法やサイバーセキュリティ対策の遵守が重要となる。

6.3 情報共有と官民連携

日本国内では、J-CSIP(サイバー情報共有イニシアティブ)やサイバー関連のシェアリングアンドアナリシスセンター(ISAC)が設立され、企業や政府機関がインシデント情報や脆弱性情報を共有している。白書は情報共有の重要性を強調し、同じ攻撃手法が別の業界にも応用される前に共有・分析を行うことで、効果的な対応が可能になるとしている。また、国際的にもFIRST(Forum of Incident Response and Security Teams)などへの参加が推奨されている。

7. まとめと今後の展望

システム脆弱性とパッチ管理は、サイバー攻撃の第一線に位置する課題であり、適切な対応が出来るかどうかで組織の安全性が大きく左右される。白書からは、脆弱性情報が大量に蓄積される一方で、多くの企業がパッチ適用や構成管理に課題を抱えている現状が見えてきた。パッチを適用していない端末が全体の約半数を占めるという統計は、基本的な対策の遅れがいかに深刻かを示している。また、復旧コストが高額になる現実は、経営層に対して脆弱性管理の重要性を訴える強力な材料となる。

これからの脆弱性対策は、単にパッチを当てるだけでなく、SBOMを基盤としたソフトウェアサプライチェーン管理や、自動化された資産管理、リスクベースの優先順位付け、標準化されたプロセスに基づくガバナンスが不可欠となる。さらに、クラウドやIoTなど新しい技術領域では、責任共有モデルの理解とサービス事業者との信頼関係の構築が重要である。

最後に、ユーザー一人ひとりがセキュリティ意識を持ち、ソフトウェア更新やアクセス権限の管理を怠らないことが、組織全体の強靭性につながる。社会全体で脆弱性情報を共有し、攻撃手法の進化に対応していく姿勢が求められている。