脆弱性対応の進め方|情報収集から影響範囲の確認・優先順位・暫定対応・記録までの6ステップ

脆弱性対応の進め方を6ステップで解説した図解。情報収集、影響範囲の確認、優先順位の判断、暫定対応、恒久対応、確認と記録の流れを示し、CVSS・KEV・EPSSなどを使った判断方法も紹介。

この記事の結論

脆弱性対応は、情報を集め、自社への影響を確かめ、優先順位を決めて、暫定対応と恒久対応を行い、結果を記録する6つのステップで進めます。

  • 情報はJVN・開発元・KEVなど信頼できる情報源から集める
  • 優先順位はCVSSに、公開範囲と悪用の状況を加えて決める
  • 修正版をすぐに入れられないときは、回避策で時間をかせぐ

📖 読了時間:約11分

脆弱性対応とは、ソフトウェアや機器の脆弱性の情報を集め、自社への影響を確かめ、優先順位を決めて修正するまでの一連の作業のことです。一般的には、情報収集、影響範囲の確認、優先順位の判断、暫定対応、恒久対応、確認と記録の6つのステップで進めます。

IPAの「情報セキュリティ10大脅威 2026」(組織編)では、「システムの脆弱性を悪用した攻撃」が4位に挙げられています。毎日のように新しい脆弱性が公表される中で、すべてに同じ速さで対応することはできません。限られた時間で、影響の大きいものから確実に対応する進め方が求められます。

以下では、6つのステップの内容、信頼できる情報源、優先順位のつけ方、暫定対応と恒久対応の違い、体制づくりのコツ、経験の伝え方の順に解説します。

こんな悩みはありませんか

  • 脆弱性の情報が多すぎて、何から手をつければよいか分からない
  • CVSSのスコアが高い順に対応すればよいのか迷う
  • 修正版をすぐに適用できないとき、どうすればよいか知りたい
  • 担当者が少なく、対応の進め方を仕組みにしたい

この記事で分かること

  • 対応の6つのステップ
  • 信頼できる脆弱性の情報源
  • CVSS・KEV・EPSSを使った優先順位のつけ方
  • 暫定対応と恒久対応の違い
  • 対応を仕組みにするコツと、経験の伝え方

この記事を読めば、脆弱性が公表されたときに、どの順番で何をすればよいかが分かります。まずは無料でスキルログに登録し、これまでに対応した脆弱性やセキュリティの仕事を案件ごとに記録しておきましょう。

脆弱性対応の6つのステップ

情報収集から記録まで、6つのステップを順に進めます。

ステップ やること 主な成果
1. 情報を集める 信頼できる情報源で、新しい脆弱性の公表を知る 対応候補の一覧
2. 影響範囲を確かめる 自社で使う製品とバージョンが該当するかを調べる 影響のある環境の一覧
3. 優先順位を決める 深刻度、公開範囲、悪用の状況、業務の重要度で判断する 対応の順番と期限
4. 暫定対応をする 修正版を入れるまでの間、回避策や緩和策で守る 一時的な防御
5. 恒久対応をする 修正版への更新を、確認したうえで適用する 脆弱性の解消
6. 確認と記録をする 適用の確認、攻撃の形跡の確認、対応の記録を残す 対応の記録と次への改善

ステップ1:信頼できる情報源から情報を集める

日本語ならJVNとJPCERT/CC、製品ごとの情報は開発元、悪用の状況はKEVで確かめます。

情報源 分かること
JVN(JPCERT/CCとIPAが共同運営) 日本で使われる製品の脆弱性、影響を受けるバージョン、対策や回避策
JPCERT/CCの注意喚起 特に注意が必要な脆弱性や攻撃の情報
製品の開発元のセキュリティ情報 修正版、影響を受けるバージョン、回避策の正確な情報
米国CISAのKEV 実際の攻撃で悪用が確認された脆弱性の一覧
米国のNVD CVE番号ごとの詳しい情報と深刻度のスコア

SNSやニュースだけで判断しない

SNSやニュースは早く情報が届く一方で、影響を受けるバージョンや回避策が不正確なこともあります。最終的には、開発元とJVNなどの公的な情報源で確かめましょう。脆弱性の番号の仕組みはCVEとは?CVE番号の読み方とCVSS・CWEとの違いで解説しています。

ステップ2:自社への影響範囲を確かめる

自社で使っている製品とバージョンを把握しておくことが、素早い対応の前提です。

脆弱性の情報に書かれた製品とバージョンが、自社で使われているかを調べます。サーバーやネットワーク機器だけでなく、アプリケーションに組み込んだライブラリも対象です。

  • 使っている製品・機器・サービスと、そのバージョンの一覧(資産の台帳)を作っておく
  • アプリケーションに含まれる部品は、SBOM(ソフトウェアの部品構成表)で把握する
  • インターネットに公開している環境かどうかも、あわせて記録しておく

部品の把握のしかたはSBOMとは?意味・メリット・作り方で詳しく解説しています。

ステップ3:脆弱性対応の優先順位を決める

CVSSの深刻度に、公開範囲、悪用の状況、業務の重要度を加えて判断します。

CVSSの仕様を管理するFIRSTは、「CVSSは深刻度を測るもので、それだけでリスクを評価すべきではない」と説明しています。スコアだけでなく、次の情報を組み合わせて判断しましょう。

判断の材料 確かめること
深刻度(CVSS) スコアと、攻撃の条件や影響の大きさ(ベクトル文字列)
悪用の状況(KEV) 米国CISAの「悪用が確認された脆弱性のカタログ」に載っているか
悪用の見込み(EPSS) FIRSTが公表する、今後30日以内に悪用される確率の推定
公開範囲 インターネットから使える環境か、社内だけか
業務の重要度 止まると困るシステムか、重要な情報を扱うか

優先順位の考え方の例

たとえば、KEVに載っていてインターネットに公開している環境で使っているものは最優先、深刻度が高くても社内だけで使っていて悪用の報告がないものは計画的に、というように基準を決めておくと、迷わずに動けます。基準は自社の環境に合わせて決めましょう。深刻度の読み方はCVSSとは?スコアの見方と深刻度の目安で解説しています。

ステップ4・5:暫定対応と恒久対応

修正版をすぐに入れられないときは、回避策で時間をかせぎ、確認したうえで修正版を適用します。

暫定対応 恒久対応
目的 修正版を入れるまでの間、攻撃を受けにくくする 脆弱性そのものをなくす
主な方法 問題の機能を止める、設定を変える、アクセスを制限する 修正版への更新、設定の恒久的な変更
注意点 一時的な手段であり、修正版の適用を忘れない 動作の確認をしてから本番に適用する

回避策はあくまで一時的な手段

米国CISAも、回避策や緩和策は一時的な手段であり、修正版がある場合はそれを優先すべきだとしています。回避策を入れたら、修正版を適用する期限もあわせて決めておきましょう。

修正版が出ていない場合

修正版が公開される前に悪用されている脆弱性もあります。そうした場合の備えはゼロデイ攻撃とは?ゼロデイ脆弱性との関係と対策で解説しています。

こうして判断し、対応してきた経験は、運用やセキュリティの経歴として評価されます。スキルログに案件として記録しておくと、件数や対応までの日数を後から振り返れます。

ステップ6:確認と記録を残す

適用できたか、攻撃の形跡がないかを確かめ、対応の記録を残して次に生かします。

  • 修正版の適用や設定の変更が、すべての対象に反映されたかを確かめる
  • 公表前後のログを確かめ、攻撃を受けた形跡がないかを調べる
  • 対応した脆弱性、判断の理由、対応日、残った課題を記録する
  • 対応に時間がかかった理由を振り返り、手順や体制を見直す

脆弱性対応を仕組みにするコツ

担当者が一人でも回るように、情報の集め方、判断の基準、手順を決めておきます。

  • 情報収集を自動にする:JVNや開発元の情報の通知を受け取り、毎日見る時間を決める
  • 判断の基準を文書にする:どの条件なら何日以内に対応するかを決めておく
  • 手順書を作る:よく使う製品の更新の手順と、元に戻す手順を残しておく
  • 関係者を決めておく:判断する人、作業する人、利用者に知らせる人を決める

少人数で社内のITを担っている場合は、こうした仕組みづくりが負担を減らす近道です。実際の対応の流れの例としてPHPの脆弱性「php2shell」の影響範囲と対応手順も参考にしてください。

脆弱性対応の経験をスキルログで残す理由

脆弱性への対応は、問題が起きなかったことが成果になるため、記録しておかないと経歴として説明しにくい仕事です。ExcelやWordで書き足していくと、対象の製品や件数、対応までの日数が抜けやすくなります。スキルログで記録すると、次の点で楽になります。

  • 項目がそろう:案件ごとに期間・役割・プロジェクト規模・チーム規模・業種・担当工程・成果を同じ項目で入力するので、書き漏れがなく、案件どうしを比べやすい
  • 体裁を整える手間がない:入力した内容はPDF出力で体裁の整ったスキルシートになり、新しい案件を足したらそのまま出し直せる
  • 伸びたスキルが見える:スキルごとにS・A・Bなどの自己評価と経験年数を並べて確認でき、次に伸ばすところが分かる

登録した経歴をもとに、運用やセキュリティの経験で狙える求人や案件、年収や単価の目安を転職・案件相談で一緒に確かめることもできます。

まとめ

6つのステップを仕組みにしておくと、脆弱性が公表されたときに迷わず動けます。

脆弱性対応は、情報収集、影響範囲の確認、優先順位の判断、暫定対応、恒久対応、確認と記録の6つのステップで進めます。情報はJVNや開発元などの信頼できる情報源で確かめ、優先順位はCVSSに、公開範囲、悪用の状況、業務の重要度を加えて決めましょう。

修正版をすぐに入れられないときは回避策で時間をかせぎ、修正版の適用まで確実に進めます。判断の基準や手順を文書にしておくと、担当者が少なくても対応を続けられます。

よくある質問

脆弱性への対応について、よく寄せられる質問をまとめました。

脆弱性が公表されたら、何日以内に対応すべきですか?

一律の決まりはなく、自社で基準を決めるのが一般的です。悪用が確認されていて、インターネットに公開している環境なら、できるだけ早く対応しましょう。

CVSSのスコアが高い順に対応すればよいですか?

スコアだけで決めるのはおすすめしません。悪用の状況、公開範囲、業務の重要度を加えて判断することが大切です。

修正版を適用すると、システムが動かなくなることはありますか?

あります。そのため、検証環境で動作を確かめてから本番に適用し、元に戻す手順も用意しておきましょう。

脆弱性の情報を効率よく集める方法はありますか?

使っている製品の開発元のセキュリティ情報と、JVNなどの通知を受け取る設定にしておくと、見落としを減らせます。

脆弱性対応の経験は、転職で評価されますか?

評価されます。判断の基準を作った経験や、対応までの日数を短くした経験は、運用やセキュリティの仕事で強みになります。

ここまでの内容を踏まえて、まずはスキルログに無料で登録し、これまでに対応した脆弱性の仕事を1件、判断の基準と対応までの日数まで入力してみましょう。セキュリティや運用の経験を生かした仕事を探したい場合は、転職・案件相談で一緒に確かめられます。

スキルログ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です