[ITmedia エンタープライズ] 件数の多い脆弱性から直すのは正解か ネットワーク診断の指摘、半数超は「パッチ管理」

脆弱（ぜいじゃく）性診断で複数の問題が見つかったとき、検出件数が多いものから対処すればよいとは限らない。頻出する指摘の背景に共通の管理上の問題がある一方、検出が1件だけでも優先して対応すべき重大な脆弱性もある。ブロードバンドセキュリティ（以下、BBSec）が2026年上半期に実施した脆弱性診断の社内集計データを基に、Webアプリケーションとネットワークで多く検出された問題を確認し、対策の優先順位を考える。

　今回使用するデータは、BBSecが2026年1～6月に実施した脆弱性診断について、本連載のためにまとめた社内集計データだ。以下に示す比率は、検出された指摘事項全体に占めるカテゴリー別の構成比であり、診断対象企業やシステムの何％で問題が存在したかを示す「発生率」ではない。なお、構成比は四捨五入しているため、合計が100％にならない場合がある。

　Webアプリケーション診断の指摘事項を5カテゴリーに分けると、「システム情報・ポリシーに関する問題」が37.1％で最多だった。次いで「認証に関する問題」が22.1％、「セッション管理に関する問題」が15.1％、「重要情報の取り扱いに関する問題」が14.5％、「入出力制御に関する問題」が11.1％だ。

図1　Webアプリケーション診断における指摘事項のカテゴリー構成（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

脆弱なバージョンの利用が突出

　システム情報・ポリシーでは、「脆弱なバージョンのOS・アプリケーションの使用」が突出して多く、推奨されない情報の出力、ディレクトリリスティング、クリックジャッキングなども確認された。この結果から、Webアプリケーションの安全性を確保するには、アプリケーション自体の実装だけでなく、OSやミドルウェア、関連するソフトウェアの管理も重要だと分かる。

　安全に実装したアプリケーションでも、OS、Webサーバ、JavaScriptライブラリなどの更新が止まれば、既知の脆弱性が残る。エラーメッセージやレスポンスヘッダに不要な情報を出力すれば、製品や構成を推測する材料を攻撃者へ与えかねない。開発部門と運用部門が、資産、構成、パッチの管理情報を共有する必要がある。

XSS対策では出力先に応じた処理が必要

　入出力制御の問題では、クロスサイトスクリプティング（XSS）が最も多く、HTMLタグインジェクション、ファイルアップロードに関する問題が続いた。

図2　Webアプリケーション診断で検出された入出力制御の主な問題（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

　XSSは、信頼できないデータが適切に処理されないままページへ出力され、利用者のブラウザ上でスクリプトなどが実行される脆弱性だ。対策では、入力された文字を一律に削除するのではなく、データの出力先に応じた適切な処理が重要となる。HTML本文、属性値、URL、JavaScriptなど、出力先の文脈に合ったエンコーディングを行う必要がある。利用者にHTMLの入力を許可する要件がある場合は、許可する要素や属性を限定したHTMLサニタイズを使う。エンコーディングとサニタイズは目的が異なり、どちらか一方を全ての出力へ機械的に適用すればよいわけではない。

　ファイルアップロード機能では、許可する拡張子を業務上必要なものに限定するとともに、Content-Typeの情報だけで判断せず、ファイルの実体も検証する必要がある。ただし、形式やシグネチャの確認だけで安全性を保証することはできない。ファイル名の再生成、容量制限、保存先の分離、実行権限の制限、認証・認可、必要に応じたマルウェア検査などを組み合わせる。

認証とセッション管理では何を確認すべきか

　認証カテゴリーでは、認証時の処理に関する問題が最も多く、パスワード強度、アカウント管理の問題が続いた。ログインの成否だけでなく、失敗時の応答によるアカウント列挙、試行回数の制御、パスワード変更や重要情報変更時の本人確認も検査対象となる。セッション管理では、不適切なセッションタイムアウトが最多で、Cookie設定、ログアウト時などのセッション破棄、セッションIDの取り扱い、クロスサイトリクエストフォージェリ（CSRF）などが確認された。

図3　Webアプリケーション診断で検出されたセッション管理の主な問題（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

　Webアプリケーションのセキュリティ向上に取り組むコミュニティーのOWASP（Open Worldwide Application Security Project）は、一定時間操作がない場合のアイドルタイムアウトに加え、操作の有無にかかわらずセッションを終了する絶対タイムアウトを示している。ログイン成功時や権限レベルの変更時にはセッションIDを更新し、ログアウト時にはサーバ側のセッションを無効化する。Cookieには用途に応じてSecure、HttpOnly、SameSite属性を設定する。

　なお、セッションIDの更新と再認証は、それぞれ目的の異なる対策だ。パスワードや登録メールアドレスの変更、重要な取引、アカウント回復後など、リスクの高い操作や事象では、現在のセッションが有効でも再認証を求める。タイムアウト時間や再認証の条件は、扱う情報の重要度と利用者の業務を踏まえて決める。

「no-cache」では保存を防げない　キャッシュ制御の思い込み

　重要情報の取り扱いでは、キャッシュ制御の不備が突出していた。推奨されない情報の出力、URLにおける重要情報の保持、非暗号化通信による重要情報の送信、パスワードに関する問題も確認されている。

図4　Webアプリケーション診断で検出された重要情報の取り扱いに関する主な問題（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

　機密性の高い情報を含むレスポンスについて、キャッシュへの保存を防ぐ場合は、「Cache-Control: no-store」の指定が基本となる。「no-cache」は保存を禁止する指定ではなく、再利用前の再検証を求める指定だ。ただし、no-storeは指定前に保存された情報を削除するものではなく、利用者による保存やスクリーンショットの取得、仕様に従わないクライアントまで防ぐものでもない。

　URLにセッション情報や個人情報を含めれば、ブラウザ履歴、アクセスログ、Refererなどを通じて意図しない場所へ残る可能性がある。キャッシュ制御だけに依存せず、機微情報をURLへ含めない設計、端末やブラウザの管理、ログへ出力する情報の制御を組み合わせる必要がある。

ネットワーク診断ではパッチ管理の問題が過半数

　ネットワーク診断では、「バージョン・パッチ管理に関する問題」が52.2％と過半数を占めた。「通信の安全性に関する問題」が27.1％、「設定に関する問題」が16.7％、「ネットワークサービスに関する問題」が3.9％だ。

図5　ネットワーク診断における指摘事項のカテゴリー構成（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

「その他」が51.0％　パッチ管理の対象は有名製品だけではない

　バージョン・パッチ管理の指摘を製品群別に見ると、Microsoft系が21.2％、OpenSSHが11.4％、Cisco IOSが4.2％、Apacheが4.1％、Apache Tomcatが3.2％、OpenSSLが2.3％、リモートデスクトップサービスが1.3％、jQueryが1.2％で、その他が51.0％だった。

図6　バージョン・パッチ管理に関する指摘の製品群別構成（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

　「その他」が51.0％を占めており、バージョンやパッチの管理が必要な製品は、特定のベンダーや製品群に限らないことが分かる。この構成比は、各製品の危険度や一般企業での利用率を示すものではない。診断対象の製品構成や分類方法にも左右される。

　資産台帳に機器やソフトウェアが登録されていなければ、新しい脆弱性情報が自社に該当するか、誰が対応するか、パッチ適用済みかを追跡しにくい。資産台帳への登録漏れが直ちに技術的な脆弱性を意味するわけではない。しかし、脆弱性への対応判断が遅れたり、対策の対象から漏れたりする要因となる。製品名とバージョンだけでなく、外部公開の有無、管理責任者、保守期限もひも付けて管理したい。

　パッチの優先順位は、CVSS Base Scoreだけでは決められない。インターネットからの到達可能性、対象資産の重要度、攻撃コードの公開、実際の悪用の確認、緩和策の有無を加味する。米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のKnown Exploited Vulnerabilities（KEV）Catalogのように、実際の悪用が確認された脆弱性の情報を判断へ取り込むことも有効だ。

暗号方式の見直しでは接続への影響も確認する

　通信の安全性では、「推奨されない暗号化方式の受け入れ」が最も多く、推奨されないSSL/TLS通信方式、脆弱な証明書、非暗号化通信による重要情報の送信が続いた。

図7　ネットワーク診断で検出された通信の安全性に関する主な問題（出典：ブロードバンドセキュリティ「2026年上半期 脆弱性診断結果」《自社診断実績を集計》）

　古い端末やシステムとの互換性を維持するために、推奨されないプロトコルや暗号スイートが有効なままになっている場合がある。こうした設定では、接続条件によって安全性の低い暗号方式が使用される可能性がある。

　一方、古い方式を一律に無効化すると、対応していないクライアントや機器が接続できなくなる場合がある。変更前に利用中のクライアントと通信経路を洗い出し、検証環境で接続影響を確認した上で段階的に切り替える必要がある。例外的に古い方式を残す場合は、対象、理由、期限を記録し、ネットワーク分離などの代替策を併用する。証明書の有効期限、信頼チェーン、鍵長、ホスト名の整合性も継続して管理する。設定の判断には、情報処理推進機構（IPA）とCRYPTRECが公開する「TLS暗号設定ガイドライン」を参照できる。

対策の優先順位はどう決めるべきか

　脆弱性診断で検出された問題は、件数の多さだけで対策の優先順位を決めるべきではない。まず優先すべきなのは、実際に悪用される可能性が高く、侵害された場合の影響が大きい問題だ。インターネットから到達できるシステムに存在する既知の脆弱性や、認証回避、任意コード実行、重要情報の取得につながる問題などは、検出件数が少なくても優先的な対応が必要となる。

　次に、対象システムの重要度や、侵害された場合の影響範囲を確認する。同じ脆弱性でも、検証環境と基幹システムでは、事業への影響が異なる。外部からの到達可能性、保有する情報、利用者の権限、他のシステムとの接続状況などを踏まえて判断する必要がある。

　一方、複数のシステムで同じ種類の問題が繰り返し検出される場合は、個別の修正だけでは不十分だ。共通部品や設計標準、開発時の検査、資産・パッチ管理など、開発・運用プロセスに共通する原因がないかを確認することも重要だ。

　今回の集計では、Webアプリケーション診断では「システム情報・ポリシーに関する問題」、ネットワーク診断では「バージョン・パッチ管理に関する問題」が最も多く検出された。ただし、こうした検出傾向は、必ずしも対策の優先順位を示すものではない。

　本連載では、BBSecの2026年上半期の脆弱性診断データを基に、企業システムにおける脆弱性の検出傾向と、その背景にあるリスクを確認してきた。診断結果から見えてくるのは、個々の脆弱性への対処だけでなく、システムの構成や運用、管理体制を継続的に見直すことの重要性だ。脆弱性診断は、問題を発見すること自体が目的ではない。検出された問題のリスクを適切に評価し、優先順位を付けて対処するとともに、再診断による改善状況の確認や、同じ問題を繰り返さないための仕組みづくりにつなげることが求められる。診断結果を一時的な対応で終わらせず、継続的なセキュリティ対策の改善に生かしたい。

著者紹介

株式会社ブロードバンドセキュリティ

セキュリティサービス本部 サービス支援部支援課 課長

フリーランスの脆弱性診断士を経てブロードバンドセキュリティに入社。

2026年10月現在、Webなどを使用したマーケティング、および顧客支援業務に従事。多数のウェビナー登壇や脆弱性診断の報告会を担当し、解説が分かりやすいと顧客から好評。