脆弱性管理とは？発見・評価・修正・検証の4ステップと中小企業での実践ガイド

「うちの会社、脆弱性管理って結局何をすればいいんだろう…」
「パッチを当てているだけじゃダメなの？」

情シス担当者なら一度は感じる疑問ではないでしょうか。実は「パッチを当てること」は脆弱性管理の4分の1にすぎません。残り3つのステップを理解していないと、同じ穴を繰り返し突かれてしまいます。

この記事では、脆弱性管理の全体像を「発見→評価→修正→検証」の4ステップで整理し、リソースが限られた中小企業の情シス担当者が実際に回せる仕組みを解説します。

脆弱性管理とは？なぜ今この対策が欠かせないのか

脆弱性管理（Vulnerability Management）とは、自組織のシステムに存在する脆弱性（セキュリティ上の欠陥）を継続的に発見・評価・修正し、リスクを許容できるレベルまで低減し続けるプロセスです。

一時的な作業ではなく「継続的なサイクル」であることが最大の特徴です。新しいOSや製品がリリースされるたびに新たな脆弱性が見つかり、攻撃者はそれを即座に悪用しようとします。

「うちは中小企業だから狙われない」という油断が一番危険です。攻撃者は企業規模ではなく「脆弱性の有無」で標的を選びます。脆弱性管理は大企業だけのものではなく、1人情シス体制でも段階的に回せる仕組みです。

攻撃者は脆弱性をどう探すのか

攻撃者が脆弱性を悪用するまでの流れを知ることで、なぜ素早い対応が必要かが実感できます。

・Step1 情報収集: Shodan（インターネット接続機器を検索するエンジン）や公開されているCVEデータベースを使い、既知の脆弱なバージョンを動かすサーバーを自動的にリストアップします。
・Step2 スキャン: リストアップしたIPアドレスに自動スキャンツールを走らせ、実際に脆弱性が残っているかを確認します。
・Step3 悪用（Exploit）: CVSSスコアの高い脆弱性には公開されたエクスプロイトコードが存在することも多く、技術力の低い攻撃者でも実行できます。
・Step4 侵害→横移動: 一台でも侵害できれば、内部ネットワークへの横移動（ラテラルムーブメント）で被害を広げます。

防御側はStep3の前に修正を完了させることが目標です。パッチが公開されてから15日以内に悪用コードが出回ることを考えると、「なんとなく後回し」が致命傷になります。

脆弱性管理の4ステップ

1. 発見 — 「まず何があるかを把握する」

管理できないものは守れません。まずIT資産を棚卸しし、スキャンツールで脆弱性を検出します。

資産管理から始める理由
スキャン前に「社内にどのOSが何台、どのミドルウェアが動いているか」を把握しておかないと、スキャン漏れが生じます。Spreadsheetでも構いません。IPアドレス・OS・バージョン・担当者を一覧化するだけで、次のステップが確実に進みます。

代表的なスキャンツール
・OpenVAS（無料）: LinuxサーバーやWindowsに対応した本格的なネットワーク脆弱性スキャナ。コミュニティ版のGVM（Greenbone Vulnerability Management）として利用可能
・Nessus Essentials（無料枠あり）: 最大16ホストまで無料でスキャン可能。UIがわかりやすく初めての担当者にも扱いやすい
・Trivy（コンテナ・OSS向け）: コンテナイメージやOSパッケージの脆弱性をCIに組み込めるオープンソースツール

スキャンは少なくとも月1回、外部公開サーバーには週1回を目標にしてください。

2. 評価 — 「どれから直すかを決める」

すべての脆弱性を同時に修正することは現実的ではありません。CVSSスコア（共通脆弱性評価システム）を使って優先度を判定します。

ただしCVSSスコアはあくまで出発点です。以下も加味すると優先度がより現場に合ったものになります。

・外部公開の有無: インターネットから直接到達できるサーバーの脆弱性は、優先度を一段階引き上げる
・実証コード（PoC）の存在: 公開されたエクスプロイトコードがある場合は即時対応が原則
・CISAのKEVカタログ: 米国土安全保障省が悪用確認済みの脆弱性を公開している。自社製品が含まれていたら最優先で対処
・業務への影響: パッチ適用による停止が許容できるかもリスク判断の一つ

3. 修正 — 「実際に対処する」

修正には大きく3つの手段があります。

・パッチ適用（最優先）: ベンダーが提供する公式パッチの適用。最も確実な対策であり、原則これを優先する
・設定変更（ワークアラウンド）: パッチが未リリース、または即時適用できない場合の暫定措置。問題のある機能を無効化したりアクセス制限を加えたりする
・リスク受容: 影響が極めて小さく、修正コストが不釣り合いに大きい場合は「残留リスクとして記録・監視する」という選択もある。記録なしの放置とは本質的に異なる

パッチ適用前には必ずテスト環境で検証する習慣をつけてください。本番環境へのサービス断が発生する可能性があるためです。

LinuxサーバーのOSパッケージを一括確認する手順

# インストール済みパッケージの中でアップデート可能なものを確認（CentOS/RHEL系）
yum check-update --security

# Ubuntu/Debian系の場合
apt list --upgradable 2>/dev/null | grep -i security

# セキュリティアップデートのみを適用（CentOS/RHEL系）
yum update --security -y

Linuxサーバーのセキュリティ設定全般については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

4. 検証 — 「本当に直ったか確認する」

パッチを当てた後は、再スキャンで修正が有効であることを確認します。これを省略すると「当てたつもりが適用されていなかった」「別の設定が上書きした」というケースを見逃してしまいます。

# パッチ適用後にOpenVASのCLIで再スキャンを実行する例
# （GVMコマンドラインクライアントを使用）
gvm-cli --gmp-username admin --gmp-password [PASS] tls   --xml ""

# 再スキャン結果で同じCVE番号が検出されなければ修正成功
# 修正日時・担当者・CVE番号を台帳に記録する

修正確認後は「いつ・誰が・何を修正したか」を台帳に記録します。次回スキャン時の比較ベースになり、監査対応にも活用できます。

中小企業でも今日からできること

専任のセキュリティエンジニアがいない環境でも、以下の3つから始められます。

① OSの自動更新を有効にする
WindowsはWindows Update、LinuxはUnattended Upgradesを設定する。これだけで既知の重大脆弱性のほとんどをカバーできます。

② CISAのKEVカタログを月1回確認する
https://www.cisa.gov/known-exploited-vulnerabilities-catalog にアクセスし、自社が利用しているソフトウェアが含まれていないか確認します。無料で利用でき、悪用が確認されている脆弱性だけを確認できるため、優先順位の判断が容易です。

③ IT資産台帳を作る
スプレッドシートで構いません。IPアドレス・OS・バージョン・担当者をまとめるだけで、次のスキャンステップへ進む基盤ができます。

次のステップとして、OpenVASを検証機にインストールし、月1回のスキャンを試してみましょう。実際に回すと、自社のリスク状況が一目でわかります。定期的な脆弱性スキャンと点検サイクルについては中小企業の定期セキュリティ点検チェックリストも合わせて参考にしてください。

よくある誤解と注意点

【誤解1】パッチを全部当てれば脆弱性管理は完了

パッチで対処できるのは「把握している既知の脆弱性」に限られます。資産台帳にないシステムの脆弱性、サードパーティ製ライブラリの脆弱性、設定ミス（Security Misconfiguration）はパッチでは対処できません。資産管理と継続スキャンがあってはじめてパッチが意味を持ちます。

【誤解2】CVSSスコアが低いから後回しでいい

スコアの低い脆弱性でも、攻撃チェーンの一部として組み合わされると深刻な侵害につながるケースがあります。外部公開サーバーにある低スコアの脆弱性が、内部システムとの組み合わせで使われることも実際に起きています。「低スコア＝無害」ではないことを念頭に置いてください。

【注意】スキャン対象は自社環境に限定する

脆弱性スキャンは自社が管理するシステムにのみ実施してください。第三者のシステムに無断でスキャンを行うと、不正アクセス禁止法に触れる可能性があります。詳細は法律の専門家にご確認ください。

本記事のまとめ

脆弱性管理はセキュリティ対策の土台です。完璧なシステムを目指すより、「把握→優先→修正→確認のサイクルを回し続ける」ことを目標にしてください。パッチ適用のサイクル設計についてはパッチ管理の基礎で、脆弱性とリスクの概念整理は脅威・脆弱性・リスクの違いとは？で詳しく解説しています。